Game loader design

Started by
3 comments, last by MrRage 17 years, 1 month ago
I’m in the design stages of my project and I was thinking of a clever way to do updates. I think it would be best to divide up the game engine into a game.dll and launcher.exe. The EXE will first connect to the game server, check for updates, download a new game.dll if required (or other data) and then link to the game.dll once its been downloaded. If there is a luncher.exe update, it will delete its self and spawn a new process of launcher and exit. The entire process would take place over a secure connection and the content would be encrypted with a unique key for every user, to help ensure that the update engine doesn’t turn into a backdoor for attacks. The whole process sounds fine to me, but wanted to get some input from you guys on it.
Advertisement
Hey!

I've wondered about how to do this too.

Why bother with the .exe and the .dll though, you'll have to do a delete anyway if the launcher gets updated, so you may as well keep them in the one exe
Only real advantage here is that the launcher app wouldn’t have to exit to do a routine update. So I think it might be possible to do hot fixes while the game engine is still running, buy having the launcher unload the game DLL and reload it between splash screens or something. But I would have to do some tests to see if that’s possible.
What I'm doing for my project, which isn't currently designed to go online but would be able to easily enough, is to package game data into Lua scripts. For example, a spaceship definition might be added to a list like so:
ships[rama] = {  mass = 10000000;  thrust = 20;  turn = 10;  graphics = 'images/ramapack';" And other bits of data about the ship}

At startup, the game simply loads all the Lua files it sees, and then calls a set of Lua functions which take these lists of game data and instantiate objects based on them. The neat thing about this is that you can load a Lua file whenever you like. If I wanted to add more game data to the game mid-play, I could simply put another file into my data/lua directory and then tell the game engine to load the file; it'd immediately become available for use.

In your case, you can just download the new file, add it to your Lua (or whatever) directory, and then load it. If the new file replaces an old one, then (I believe) loading it will simply overwrite the old logic so long as the load doesn't do any append-style actions.

Note that this mainly works because the vast majority of the game logic is also in Lua; the C++ engine that loads Lua files doesn't do a whole lot else (largely asset management, collision detection, and the like). If you needed to change something in the base engine, then you'd be forced to download, apply a patch, and restart.
Jetblade: an open-source 2D platforming game in the style of Metroid and Castlevania, with procedurally-generated levels
I had lunch with a few developer friends of mine and we talked about my options and the consensus was that such a system that would link dynamically would be cool and have some advantages over a static linked system, but the trade off was a huge amount of development time that wound not necessary offer any enhancements to the end user. So it just made better sense to build the game API as a static lib and just replace the launcher exe each time we have an update.

This topic is closed to new replies.

Advertisement