next »

[Robotacon]

I'm going into the end stage of the game engine part of my game design. The current alpha is loading all resources, images, sfx, scripts and maps over http to make testing easier. In total the current resource footprint is about 500kb.

If I leave it this way for the final release do you guys think people will be upset that the game can't be played offline?

The rational behind keeping the current setup is that I can patch the game serverside and I can extend the world with little effort.

It will make it harder for players to mod the game but I'm opting to either allow loading of resources from foreign hosts or letting players upload resources to my webserver.

I'm happy for any kind of feedback!

/ Tor Robotacon Viktorsson

PS. It's a 2D platformer game with sidescroller elements we're talking about.

[Ant]

Is your game heavily geared towards multiplayer? Most people find the idea of always-online single player games annoying. Can't you make it optional?

[LordJekky]

Assuming that it isn't a multiplayer-only game, where players need to be online anyway, and further assuming that it is actually a desktop app and not a browser app, I would go with loading from the server with local caching.

on first load, the game grabs everything from the server and caches it locally. Next time the game runs it can simply ask the server if there are updates, if not it can continue, if there are it can offer them to the player (forcing the update on people is a bad idea, if i start a game i want to play it, not wait for an update, on a similar note the update check should be asynchronous if possible to avoid the game appearing to take forever to load/start).

As well as avoiding issues for the player (what happens if your server is down, what happens if they don't have the time to wait for an update, etc), caching the content locally also saves a ton of bandwidth (even more if updates only updated modified files and not the whole thing).

I apologise if i read incorrectly and you already cache the data locally, but it sounds like you load it all every time.

extra note: if it does have multiplayer, you need to be careful about allowing people on different versions to interact.. simplest way there is probably to block multiplayer unless you have the latest update.

IF the game is multiplayer only, then the part about caching still applies, but you have to use forced updates to keep everyone on the current version. still saves on bandwidth for you.

[BorisTheBrave]

Yes, totally unacceptable to be redownload the same data multiple times, that costs both you and them money.

You should factor your resource loading into bundles that can be downloaded and re-used. This enables caching, also allows you send only diffs for updates (as you'll know what version bundles they have, and what they need). And it encourages modding without trashing the concept of a "pristine" bundle.

[Xienen]

I have to agree that online-only single player games are a horrible thing.  If, however, it is a multiplayer centric game, then it's no big deal, but you definitely want local file caching instead of redownloading it all every time.

[ThemsAllTook]

I'd hate not to be able to play your game if my internet goes out, or I'm on an airplane, or in any number of other situations where I can't be online. Not something that comes up every day, but it's incredibly frustrating when it does. Well worth the developer effort to reduce pain for the player.

[Evan Balster]

I agree with what these guys say -- account for situations where your server goes down or your user doesn't have internet.  Honestly I'd ship *some* version of the resources with the initial download, just so users who aren't connected when they later unzip aren't messed over.

Anyway.

A serious, important warning:  Autoupdaters are dangerous.  Hijacking them is the easiest, most effective way for a blackhat to distribute malware -- in one move they can bypass system security for every user of your app.  Unless you have extremely strong security measures in place (certificate-based encrypted connection between game and server, server administration is extremely secure) you want to make sure no code is being downloaded.  Binary code (EXE, DLL, JAR) is the largest risk, but scripting languages such as Python with access to system functions are also a problem.

If the autoupdater downloads arbitrary filetypes, it could be possible to install a second EXE or other runnable file such as JAR to the game folder which ends up getting executed through the user's confusion or some other means.  Do not overlook these risks.

I make a point of fussing about this stuff on a regular basis because it's important.  Like, really damn important.  Games are capable of a lower ratio of programmer experience to software desirability than anything and are a really easy target for attacks like this.  When they do occur, people are that much less trusting of indie games as a result.  So consider nixing your autoupdating or outsourcing it to a proven, secure platform like Steam, Desura, Adobe Air or the like.  Unlike you (or me!) they know how to do this stuff right.

[ThemsAllTook]

I make a point of fussing about this stuff on a regular basis because it's important.  Like, really damn important.

I totally hadn't thought about that. So, your fussing has at least enlightened one person, in case I write a game with an autoupdater in the future. Definitely an important thing to know about.

[Robotacon]

Thanks for the feedback guys! I think you're all right.

I'm going to take the advice to ship with all core resources bundled and cache any further downloads to minimize the need for an active connection.

The resources are images, wave-files and configuration files (xml) and no executables so I (knock on wood) think I'm safe security-wise. I'll look into the topic further to reduce the risk for exploits because it's easy to make mistakes. I think I'm handling the download buffers correctly but I won't make that my famous last words

/ Tor

ps. When I said I download script files I meant behavior tree definitions in xml format. Not scripts that are interpreted.

[VortexCortex]

Unless you actually try to make it where I can't play offline, I can play offline.

Every browser has offline mode.

These folks in here might not be aware of this.  Your game is already offline capable.  This feature is over a decade old.

Eg: to "cache further downloads" all you have to do is absolutely nothing.  You have to actively set meta tags or HTTP headers to indicated non-cached content.  If you aren't doing this, then you're fine.

Edit:
I agree with the notion of pre-loading everything and storing it in HTML5 local storage; However, "that costs both you and them money" if they only play the first few minutes of the game, and wouldn't otherwise fetch the audio / assets for the later levels, for example.

Consider replacing your XML with JSON.  Then you can easily create an offline version that uses <script> tags to load the JS data.  Ajax / HTMLHTTPRequest does not work on file:// urls.  So just detect if window.location.protocol == 'file:', and use the 'insecure' <script> tag method of loading JSON if it's being run offline.  They can trust the script on their HDDs -- That's where the original game script resides; If loading data offline this way is 'insecure' then so is loading the game itself from the disk drive. o_O

Additionally, a hybrid Ajax w/ JSON and script tags approach would enable users to mod the offline versions and submit them.   I'm aware of the implications of cross site scripting if you use scripts to load content online, however, consider that loading XML from cross domain sources is just as insecure.  Consider I write a Perl script that simply sends an unlimited string of BS XML data...  A user downloads that mod and your game breaks, or worse, has a buffer overflow and I get their rootz.

[LordJekky]

The point about it already being offline capable only applies if it's actually a browser game - that hasn't actually been specified in any post yet, and other things stated would suggest that it's a desktop app.

[Robotacon]

I'm sorry I didn't specify explicitly that the game is a desktop application.

It's possible to watch maps online using xslt to translate the map definitions to html but it's not possible to play the game in a browser and I have no plans for it.

[makerimages]

Id also like offline more, but online gives some advantages- for an exampne you can store each players variables(money,items and so on) online and have camagins an dcompetitions,the winners of which can be awarded ingame shit via serverside

[Klaim]

I agree with what these guys say -- account for situations where your server goes down or your user doesn't have internet.  Honestly I'd ship *some* version of the resources with the initial download, just so users who aren't connected when they later unzip aren't messed over.

Anyway.

A serious, important warning:  Autoupdaters are dangerous.  Hijacking them is the easiest, most effective way for a blackhat to distribute malware -- in one move they can bypass system security for every user of your app.  Unless you have extremely strong security measures in place (certificate-based encrypted connection between game and server, server administration is extremely secure) you want to make sure no code is being downloaded.  Binary code (EXE, DLL, JAR) is the largest risk, but scripting languages such as Python with access to system functions are also a problem.

If the autoupdater downloads arbitrary filetypes, it could be possible to install a second EXE or other runnable file such as JAR to the game folder which ends up getting executed through the user's confusion or some other means.  Do not overlook these risks.

I make a point of fussing about this stuff on a regular basis because it's important.  Like, really damn important.  Games are capable of a lower ratio of programmer experience to software desirability than anything and are a really easy target for attacks like this.  When they do occur, people are that much less trusting of indie games as a result.  So consider nixing your autoupdating or outsourcing it to a proven, secure platform like Steam, Desura, Adobe Air or the like.  Unlike you (or me!) they know how to do this stuff right.

This is both true and depressing me more each time I think about it because the game I'm making relies on updating regularly the game content with binaries.

I think it would be ok to just ask the user to update the software himself, as I plan to provide updates every 3-4 months aproximatively, but it feels less than idea.

As I can't rely on Steam for example, I think I'll be forced to do this for now, as I don't have skills or money to pay someone with skills to make the updater and server very secure.

[VortexCortex]

A serious, important warning:  Autoupdaters are dangerous.  Hijacking them is the easiest.

This is both true and depressing me more each time I think about it because the game I'm making relies on updating regularly the game content with binaries.

Consider implementing a scripting language in your engine.  Eg: drop LUA in, but not LUA w/ JIT (that runs as machine code).  There are other langs available.  Lots of folks make their own with flex/lex and yacc/bison from a BNF grammar.  The point is that the game logic updates could then be all sandboxed as 'op-codes' that your engine supports, not raw hardware access.

Compiling OpenSSL libs for cert verification is cumbersome, but by no means impossible.  Just make yourself the pre-installed root CA.   Easier said than done, but well worth it.

Also, although my prior comment doesn't apply to this specific project, it can still be salvaged re: the topic at hand.  It's still got good info for folks doing web games.   Notably: Even HTML5 games can have offline modes if you plan ahead -- In some ways it's even easier than with custom engines/online protocols, since browsers solved the security and caching issues already...

[Klaim]

A serious, important warning:  Autoupdaters are dangerous.  Hijacking them is the easiest.

This is both true and depressing me more each time I think about it because the game I'm making relies on updating regularly the game content with binaries.

Consider implementing a scripting language in your engine.  Eg: drop LUA in, but not LUA w/ JIT (that runs as machine code).  There are other langs available.  Lots of folks make their own with flex/lex and yacc/bison from a BNF grammar.  The point is that the game logic updates could then be all sandboxed as 'op-codes' that your engine supports, not raw hardware access.

Obviously! But can't work for this specific project. I wouldn't have this problem otherwise.

[Evan Balster]

Klaim:  There are plenty of other platforms aside from Steam that implement automatic updating, and are easier to get onto.  I would urge you to investigate those.

In my eyes the scariest thing about the autoupdater vulnerability is the prospect of being held liable or getting a bad reputation in the wake of a mass-hack.  While it's only hypothetical, it seems like that kind of publicity could tank an indie's career.  :/

[Klaim]

Yeah other platforms are available but my previous research seems to get to this point:

 - the ones the most usable are not cross-platform;
 - most forces you to use a ugly application for updating, while what I need is just a library;
 - there are libraries, but most of them are not finished or not tested enough yet;
 - some platforms provide stores and apt-get which don't match the game's use;

So basically if I want to sell games from my own website, that is, not Steam, not Desura etc., there is not yet a sure way to do it. I'm tempted to use Karazeh as it seem to match my needs but Amireh told me he can't work on it for some time so it's not sure it's production-ready yet.

In my eyes the scariest thing about the autoupdater vulnerability is the prospect of being held liable or getting a bad reputation in the wake of a mass-hack.  While it's only hypothetical, it seems like that kind of publicity could tank an indie's career.  :/

Yeah, legal stuffs can crush you hard. :/