Game architecture for someone with a background in LOB Apps

Question

I've got a background that is almost entirely based around business applications - Web services, schedulers, desktop and web front-ends to CRM systems, etc...

Now with almost all of the above projects, the basic principles are the same:

Some sort of data access layer, business logic layer and a UI.

Obviously some scenario require something a little unique but in general it's N-Tier all the way.

I'd like to do some game development as a hobby. I'm not expecting anything impressive as I don't have the resources to dedicate to it, but something to challenge me a bit would be good.

What lessons (if any) should I be taking from my current experience and what do I need to learn again?

I'm assuming that as with all my experience, different types of games will have different architectures but are they all based around the same core principles? For the sake of argument, let's say I'm building a simple MUD (maybe a top-down UI like the older Zelda games) - This seemed like something that I could have my 3-Tier logic for - A server with the BLL and DAL and a client UI - But I'm not quite sure if this is right - certainly using the Entity Framework doesn't seem appropriate as there's an awful lot of overhead in accessing lots of stuff in the Db and I'd imagine performance will be an issue - eg I'm assuming I wouldn't want to constantly use the Db to store player locations if they're changing 20+ times/second...

Are there patterns and practices specifically for game scenarios?

Is it feasible to develop the back-end system before creating a UI (eg plugging a console app in instead to allow me to develop the functionality I'd like before adding the UI). Is this good/bad practice?

In short, I don't know where to start and would appreciate some advice - especially from those with experience.

About the only thing that's set in stone is that I'd like a multi-user game with a central server. Game suggestions welcome.

Answer 1

first, games tend to have real-time simulation

• therefore, games have update loops
• therefore, games tend to business logic operations in the microsecond scale.
• therefore, database-ish solutions aren't the end all and be all of your 'data layer'

(if you don't have simulation (ex: 'scrabble', 'civilization', most facebook games), this isn't true. mud's don't tend to have much simulation, so its not clear which side of the fence your game is on)

thus in practice, of the high simulation games,

small/non persistent multiplayer games (quake, counterstrike, starcraft - games that can be run by a single machine) : solve this by not having a data layer (and if they implement saves, they do so as giant dumps of gamestate)

large multiplayer games (mmos - games that require multiple machines) : use their persistent data store as a write-only pipe (and for recovery), and then put a lot of energy into a scheme for partitioning data in such a way that the simulation (ie business) logic can get at what it needs to with latencies on the order of local memory access.

some numbers for perspective: if a 'server' handles 500 players and your simulation rate is 15hz, then each player gets .13ms of cpu per player per tick. so if you need 'did the fireball hit anything this frame' needs to be <<.13ms, not nearly long enough for a network roundtrip or an sql query. yes, you can game-design away many of these problems - for example 'don't have collision' solves the prev example. But at some point, you stop being a simulation game, heh.

the second big difference is 'graphics'

graphics programming is pretty different than business app programming. though i sometimes think of all programming as 'take data in place A in format X and move to place B in format Y' which applies to both business and graphics programming, graphics programming is many orders of magnitude less forgiving for the most part.

(though as an aside, a quick back of the envelope calc puts google-esque problems in the same bucket:

• games: manage 'gigabytes**' of graphics data at 'millisecond' scales == 10^9 / 10^-3 == 10^12
• google: manage 'petabytes' of data at 'day' scales == 10^15 / 10^3 == 10^12

**: and really, games can't move that much data around, so the 'trick' of graphics programming is jumping through the hoops of 'how do we get gigabytes of graphics data where it needs to be every frame, with the reality of only being to actually move/manipulate megabytes a frame' - load screens being a commmon but unfortunate answer :(

again this is less relevant if you are making a game with low graphics requirements.

thus games tend to be framed in terms of "gameplay/graphics"

rather than "ui/logic/dal". that being said, when i transitioned from web-land to games, my 3-tier view of the world (yeah, we only had 3 tiers back then) i felt brought a lot of insight into our project, and led to the development of a 'data access layer' for game content that's been very successful across multiple projects (solving the game-world problems like getting things off disk, handling development-time versioning, hotloading and so on).

While there will be new things to learn wherever game development takes you, your previous experience will help you along the way.

with respect to your request for advice,

i would suggest focusing on a game with a design that does closely match your experience.

ie if you are extremely competent with databases, webpages and scheduling, make a spreadsheet game: http://www.ogame.org/

if you want a little more game logic and simulation, make a collectible card game: http://apps.facebook.com/warstorm/

if you want a little more complex player interaction, check out mmo-scrabble: http://wordsquared.com/

and if you want to learn graphics, start with a single player game :)

use the techniques and technologies your comfortable with, see where they start to break down, then come back here and post your questions and discoveries.

have fun!