Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1059170 Posts in 43053 Topics- by 34997 Members - Latest Member: macepoodle

October 30, 2014, 08:47:46 PM
TIGSource ForumsDeveloperTechnical (Moderators: Glaiel-Gamer, ThemsAllTook)Is having no offline support frowned upon?
Pages: [1]
Print
Author Topic: Is having no offline support frowned upon?  (Read 1131 times)
Robotacon
Pixelhead
Level 3
******


Story mode


View Profile
« on: March 02, 2013, 12:47:39 AM »

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.
Logged
Ant
Guest
« Reply #1 on: March 02, 2013, 12:52:55 AM »

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?
Logged
LordJekky
Level 0
**


View Profile
« Reply #2 on: March 02, 2013, 01:08:42 AM »

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.
Logged
BorisTheBrave
Level 10
*****


View Profile WWW
« Reply #3 on: March 02, 2013, 01:59:56 AM »

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.
Logged
Xienen
Level 3
***


Greater Good Games


View Profile WWW
« Reply #4 on: March 02, 2013, 06:22:46 AM »

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.
Logged

ThemsAllTook
Moderator
Level 10
******


Alex Diener


View Profile WWW
« Reply #5 on: March 02, 2013, 09:14:47 AM »

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.
Logged
Evan Balster
Level 10
*****


I live in this head.


View Profile WWW Email
« Reply #6 on: March 02, 2013, 09:37:39 AM »

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.
Logged

Creativity births expression.  Curiosity births exploration.
Our work is as soil to these seeds; our art is what grows from them...


Wreath, SoundSelf, Infinite Blank, Cave Story+, <plaid/audio>
ThemsAllTook
Moderator
Level 10
******


Alex Diener


View Profile WWW
« Reply #7 on: March 02, 2013, 11:44:44 AM »

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.
Logged
Robotacon
Pixelhead
Level 3
******


Story mode


View Profile
« Reply #8 on: March 02, 2013, 12:25:22 PM »

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 Wink

/ Tor

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


Engram Architect


View Profile WWW Email
« Reply #9 on: March 03, 2013, 01:25:53 AM »

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.


« Last Edit: March 03, 2013, 01:44:03 AM by VortexCortex » Logged

LordJekky
Level 0
**


View Profile
« Reply #10 on: March 03, 2013, 01:42:53 AM »

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.
Logged
Robotacon
Pixelhead
Level 3
******


Story mode


View Profile
« Reply #11 on: March 03, 2013, 06:04:35 AM »

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.
Logged
makerimages
Level 2
**


Makerimages Studios


View Profile WWW Email
« Reply #12 on: March 03, 2013, 06:22:13 AM »

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
Logged

Makerimages-Its in the pixel
Klaim
Level 10
*****



View Profile WWW
« Reply #13 on: March 03, 2013, 06:27:55 AM »

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.
Logged

http://www.klaimsden.net | Game : NetRush | Digital Story-Telling Technologies : Art Of Sequence
VortexCortex
Level 2
**


Engram Architect


View Profile WWW Email
« Reply #14 on: March 03, 2013, 07:31:38 AM »

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...
Logged

Klaim
Level 10
*****



View Profile WWW
« Reply #15 on: March 03, 2013, 07:55:49 AM »

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.
Logged

http://www.klaimsden.net | Game : NetRush | Digital Story-Telling Technologies : Art Of Sequence
Evan Balster
Level 10
*****


I live in this head.


View Profile WWW Email
« Reply #16 on: March 03, 2013, 09:57:17 AM »

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.  :/
Logged

Creativity births expression.  Curiosity births exploration.
Our work is as soil to these seeds; our art is what grows from them...


Wreath, SoundSelf, Infinite Blank, Cave Story+, <plaid/audio>
Klaim
Level 10
*****



View Profile WWW
« Reply #17 on: March 03, 2013, 12:19:15 PM »

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.

Quote
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. :/
Logged

http://www.klaimsden.net | Game : NetRush | Digital Story-Telling Technologies : Art Of Sequence
Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic