next »

[oahda]

I also did some major work done on build and deploy system -- it has to be cross platform and support the different modes of distribution (humble, itch, steam, mac appstore, ...). Each distribution platform has it's own method for handling updates and deployment, so it's just a matter of plugging into each of the systems. The standalone auto-updating version will still work as normal, though the game will also auto-update through itch and steam. Many details still need to be sorted out.

I've been pondering this sort of stuff lately... If you could be bothered and have the time to write something up about it in more detail, I'd love to read it. c:

Sam is building the OSX launcher next week. It'll work like the windows one. For the linux standalone version we'll just have a shell script which you type from command line, it'll check for updates too.

Why do so many people do it this way? It's generally just a small GUI application, right? Why not write it using a portable library off the bat, so that it works everywhere? :/ People at my job did the same thing and now I have to write a Mac version of their launcher from scratch instead of just writing portable code from the start (tho they sort of had a reason, since they're using Unity and they used a proprietary update tool for that and that came with a Windows launcher but no Mac or Linux ones...).

[eigenbom]

I've been pondering this sort of stuff lately... If you could be bothered and have the time to write something up about it in more detail, I'd love to read it. c:

Remind me when the game is out and I will!

Why do so many people do it this way? It's generally just a small GUI application, right? Why not write it using a portable library off the bat, so that it works everywhere? :/ People at my job did the same thing and now I have to write a Mac version of their launcher from scratch instead of just writing portable code from the start (tho they sort of had a reason, since they're using Unity and they used a proprietary update tool for that and that came with a Windows launcher but no Mac or Linux ones...).

For an application a cross-platform UI toolkit makes a lot of sense, but a small launcher is only a few hundred lines of Windows/Mac code and once written has minimal dependencies. Lines of code shouldn't be the only metric you base a decision on.

[oahda]

I was rather thinking about stuff like manageability... Like when changes need to be made, they need to be made for all versions... And consistency, because it might be more difficult to make the launchers match each other if different libraries are used and so on. :E

Also seems easier to just learn one library, like Qt, and not many, which might have their own weird things going on since they're not generic, and they might written in different languages. And say you don't have a Mac or a Windows machine yourself, you can just give the portable code to a friend who does and have them compile it, for example.

Not trying to tell you what to do—I just find it curious! Not necessarily that you personally are doing it this way, but that it seems to be so common.

[eigenbom]

I was rather thinking about stuff like manageability... Like when changes need to be made, they need to be made for all versions... And consistency, because it might be more difficult to make the launchers match each other if different libraries are used and so on. :E

That depends on the complexity of your launcher. If it's just got a few buttons and a checkbox then there is so little work to update it.

Also seems easier to just learn one library, like Qt ...

I've used Qt for a few different projects, and it's a big dependency to carry around with you. Qt will also increase your game download size by a significant amount. Boost is another library that pains me to carry around.

And say you don't have a Mac or a Windows machine yourself, you can just give the portable code to a friend who does and have them compile it, for example.

This is the ideal of cross-platform libs, but unfortunately is not so straightforward. I also avoid cmake, scons, etc, and just use per-OS project files. I've spent way too much time debugging cmake errors, building and updating dependencies, and so on. I believe in cross-platform libs for things with lots of code (I use SFML for the actual game, for instance), but for small tools the overhead of an extra dependency is sometimes not worth it.

Not trying to tell you what to do—I just find it curious! Not necessarily that you personally are doing it this way, but that it seems to be so common.

Ha that's okay. I'm grumpy and just want to do the minimum work.

[oahda]

I've used Qt for a few different projects, and it's a big dependency to carry around with you. Qt will also increase your game download size by a significant amount. Boost is another library that pains me to carry around.

Yeah, didn't necessarily mean Qt. It was just the first one I could think of. But something like it. There's probably something more lightweight out there that serves similar purposes.

but for small tools the overhead of an extra dependency is sometimes not worth it.

Can't say you're wrong!

But hey, even if the platform-specific code is written manually, I suppose it could all still be wrapped into one project/codebase with some thin abstraction and a couple of #ifdefs either way!

[eigenbom]

Yeah, didn't necessarily mean Qt. It was just the first one I could think of. But something like it. There's probably something more lightweight out there that serves similar purposes.

Yep totally. I haven't looked in a few years but I used FLTK a while back, it was okay. TBH I also could have used SFML+ImGui which would have been a no-dependencies job.

[PsySal]

Hey! Was reading and I had a tiny bit of experience I wanted to share, FWIW:



1- On the starter

I had to do a starter for The Real Texas. I used wxWidgets. The earlier version used wx 2.6 which generally worked very well. For the recent Steam release I upgraded to wx 3.0 and there were some really terrible conflicts with SDL2. But I was quite happy with wx 2.6.

However writing three separate launchers is also not a terrible idea-- honestly it might have been less work for me to do this, but only because of the issues I had getting it to play nicely with SDL2. The problem, roughly, was that I had to start SDL2 to get a list of screen resolutions, then shut it down, then start wxWidgets but populated with those screen resolutions, then shut down wxWidgets and re-start SDL2. This was (as far as I can tell) not a problem on the SDL2 side but a genuine problem on the wxWidgets side, causing crashes that were for different causes on all three platforms. I literally had to use three separate solutions for each platform and debugging this was a huge headache. Source-diving into wxWidgets was too scary (I tried.)

I am planning to back-grade it to wx 2.6 since this version never gave me any problems (2.8 might be alright, too.)

For Paradise Never I am not including a starter at all.



2- On the auto-updater

I wrote an auto-updater (integrated with it's own starter) for another game Paradise Perfect Boat Rescue. The thing I was most worried about was-- what happens when my web hosting is hacked? It will be hacked, it's always going to be hacked. So how can I guarantee that I don't infect all my customers/players with malware?

What I did was use RSA to sign the updates. The client that the player downloads has the public key, and refuses to install anything (and gives a warning) that isn't signed properly. This way, even if my website is hacked, the hackers cannot convince my client to auto install anything (I keep the private key in an encrypted container that I only mounted for signing purposes.)

I wrote my own RSA implementation, which was a bad idea from a computer security standpoint but an excellent idea otherwise (as in, it's really fun and interesting to do, and not that much work actually, unless you were to write your own prime number generator for the key generator, which I did not do.)

I didn't read earlier about how your auto updater works, hopefully it's not condescending that I'm pointing it out and I kinda expect you probably already got it sorted (mad respect for your work!) but it's an easy oversight to have so better safe than sorry. And Moommamm will easily have 1,000,000 users I think so worth doing carefully!

[eigenbom]

What I did was use RSA to sign the updates. The client that the player downloads has the public key, and refuses to install anything (and gives a warning) that isn't signed properly. This way, even if my website is hacked, the hackers cannot convince my client to auto install anything (I keep the private key in an encrypted container that I only mounted for signing purposes.)

Ahh, you know what .. I hadn't even thought about this. I thought md5 hashing was enough but it totally makes sense to also RSA sign it with a priv key that isn't stored on the server. So I actually spent the whole of today implementing such a system.

Now my file hash is made by file -> SHA256 -> RSA PKCS #1 1.5 -- (signed by a private key on my build system). The launcher then uses a public key which is embedded in it to decode the hash.

mad respect for your work!

Haha, you too dude

[standardcombo]

Implementing auto-updaters is kinda cool, but why is that needed in case there's a Steam build anyway. Steam handles the update right? Why is it worth the effort to create and maintain a whole different build and deploy system?

[eigenbom]

Implementing auto-updaters is kinda cool, but why is that needed in case there's a Steam build anyway. Steam handles the update right? Why is it worth the effort to create and maintain a whole different build and deploy system?

I used the system for alpha testing and it definitely was worth the effort for that. You're right, Steam auto-updates, as does Itch, but other vendors like Humble don't, and the auto-updater will remain to fill that gap. The good thing is that it requires minimal maintenance.

[eigenbom]

(Last Weeks) Update:

I'm heading down the coast for a few days so this week has a short and early devlog. Sam and I have been working on build systems and launchers and Alex has been updating mesa tiles and cleaning up all the creature sprites.

For the standalone auto-updater I plugged a security hole (now updates are cryptographically signed). I've also been working on integrating the build system with the various vendors, including itch.io and steam. Itch was very easy to incorporate, and if you use the itch launcher then the game will auto-update through that. Here's a shot of itch downloading a test build.



Steam is a little more complicated due to the number of features it has, but I'm slowly working through it. It's kind of cool and feeling very real to see the game stub appear in my Steam library..



On OSX the launcher is up and running. After some deliberation we decided that we won't support a standalone auto-updater on OSX and Linux. Both platforms will still check for updates and notify if there is one, however you'll have to manually download it from humble or itch or wherever you bought it. Under steam, itch launcher, and mac appstore the game will auto-update as normal.

The creature work involves tidying up all the animations, determining new behaviours and animating those, and setting up the colour mappings and sprites for the variations. Such as the Komodo and Dragon below ... they use the same basic sprite but the dragon has a couple more layers and is colour mapped.



Update (This weeks!):
I was planning to write a big post about the build system, but I ended up working all weekend on the game. I guess that's a good thing, right? :smiley:

I'll probably still write up the build system at some point, but today will be another small devlog.

Build System: All platforms and vendors are setup and working properly. I can do a full build from my work computer -- this includes building for steam, itch, and humble, building for linux in a virtual machine, and building for osx by remoting into my mac at home. Then I have a script which deploys them all and sets up a useful tasklist for the manual tasks that would follow (like checking boxes in steam's web interface, uploading changelogs, etc.)

Misc things: The game runs successfully in itch app's 'sandbox mode', which protects the user from malicious software. The game embeds steam's api and exe wrapper, which just makes sure that Steam is running if you're running the steam version of the game. I'll be hooking up some features like Steam cloud and other things in the near future.

Alex has been experimenting with the character select, title screen, and bits and pieces like creature anims and sand tiles. Sam has been finalising the OSX launcher and remaining linux build issues.

Another boring devlog update, but I'll be getting back into content and gameplay programming this week!

Here's the osx standalone launcher in action:

[eigenbom]

Update: 12 days on, now I get today off :slight_smile:

Improved controller support: You can now navigate menus with controller, keyboard or mouse. I'm working on inventory navigation with the controller and then the last thing will be to snap interactions .. e.g., if you're facing a chest and close enough you will just be able to press a controller button to activate it (without having to focus the reticule on it).

Lighting improvements: The lighting system is much improved (for high gfx mode). Amongst many tweaks, torches now feed into the tile-based lighting system. Here's an example:



Colour levels: We added a better colouring system to the game. This will be used to give some extra colour control over full levels or parts of the level. For instance in the forest level the graphics will get bluer and bluer the further down the cave you go. The system works exactly like the Colour Levels dialogue in GIMP (and probably photoshop), which means we can setup levels in that program and then copy them over into the game. Here are some examples, though it will be rare to see such extreme colour mapping:



Among these things we've been working on concepts of the title screens, cursors, veil surface, and we've also been finishing off the osx and linux build system. See you next week, thanks for reading!

[RujiK]

the forest level the graphics will get bluer and bluer the further down the cave you go

This idea. I like this idea.

[nathy after dark]

we've also been finishing off the osx and linux build system.

Would you mind sharing some details about that? I'm also working on cross-platform builds for my game, and I'm pretty stumped on OSX as to how I build an executable that's compatible with older OS versions. Building with CMake and AppleClang on my El Capitan Mac, the executables it makes are only compatible with El Capitan (my OS version). What's more, I'm not really sure what a good minimum OS version for Mac might be.

[eigenbom]

we've also been finishing off the osx and linux build system.

Would you mind sharing some details about that? I'm also working on cross-platform builds for my game, and I'm pretty stumped on OSX as to how I build an executable that's compatible with older OS versions. Building with CMake and AppleClang on my El Capitan Mac, the executables it makes are only compatible with El Capitan (my OS version). What's more, I'm not really sure what a good minimum OS version for Mac might be.

Well there's an option in Xcode where you can set the deploy target. We chose 10.7 as our minimum version (meaning you need at least a 2005 mac to run the game). I googled and found that CMAKE_OSX_DEPLOYMENT_TARGET is the flag you need for cmake.

[oahda]

And if you need to, you can always dig up old versions of SDK's or Xcode on the Apple Developers website.

[bacon]

Just want to chime in to say I'm definitely interested in hearing more about the build process as well!

[eigenbom]

Just want to chime in to say I'm definitely interested in hearing more about the build process as well!

Is there anything in particular?


Update: So I made a game for Ludum Dare called No Mario's Sky, and it went viral and out of control. It's now been downloaded 120,000 times. We got a DMCA from Nintendo. If you google it you'll find a number of articles about it all!

Moonman development is going crazy again, I set a deadline for 2 months to EA release and there's a tonne of stuff to do, so I'm just churning through it all now as fast as I can. Here's a few images of gui and a minimap which will be appear if you have a map item or are special in some way.

[standardcombo]

Oh man I didn't realize No Mario's Sky was yours. Everyone was playing it at my office! Haha

Good show!

[NoLocality]

Getting close to five years of development and that's only what you've logged! 

You definitely have some strengths there buddy.

A premature happy birthday to Moonman!