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.

[This was originally asked on SO but it was suggested that this would be a better forum. Apologies if this breaks any rules but I don't know how to link across sites. If someone can advise me of the appropriate action, I'll take it. Many thanks]

Answer 1

I don't think there really is a way to answer your questions. Personally I think it's too broad a topic to really talk about.

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

Well if you can think like a programmer and have learned to problem solve then great. Maybe you'll have an understanding of what makes a good end-user UI. Database knowledge might be a good foundation for... something... The rest of it (other than probably the web communication layer) you can throw away. Real time game programming is almost totally different than application programming. Maybe there might be a little bit of convergence when you start throwing multiplayer and server communication in the mix, but it's a significantly harder problem than just a local-only game.

Are there patterns and practices specifically for game scenarios?

Yes. But most of them are subjective.

There is a huge gamut of different patterns in making a game. Some related to 3D graphics (and all its various subgenres like lighting, filtering, shaders, etc. etc. etc.). Some for features like streaming in level content. Lots of books on collision paradigms. There's a battle for OO vs. data-driven design. Components vs inheritance hierarchies. People can't even agree on what is the best way to pump updates to entities in a world (fixed rate or passing in per frame deltas, for one part of the argument). People have different opinions about whether or not generic programming is a good thing. There's no way to really answer that question as stated (other than "yes"), it's too broad.

---

I mean, if you have specific questions on how to do certain things, that is what this site is designed for. For example, maybe you want to know about how to sync up client side movement with a server and have it not be choppy. Maybe you want to ask if the client should be authoritative on movement or the server should be.

My advice to new people starting games is just to do it. Nobody can help you make your decisions. You can be spinning your wheels forever trying to do research on the "best way" to do things. But that really isn't important. What's important is building up experience on your own in order to get to the point where when you need to make a decision you can make an informed decision, and to keep an analytical mind open when you're working on things to see what problems and solutions crop up.

For your example, talking about pushing updates to a database. Just do it. Then profile it. If it's slow, think about ways around it. If it isn't fast enough, start thinking about ways to handle it. If you need direction, then come to us for help.

Answer 2

You dont tell us what languages you are used to from your work with websites/CMS/CRM etc. but as being one of these "business people" myself, I also do gameprogramming in my sparetime.

I've found that Unity3D is a great game-engine, if you know how to write Javscript or C#.

Have a look at www.unity3D.com for more info. There is a "almost full" edition for free, which you MAY use for publishing games. And you are allowed to charge money for your games, eventhough you use the free edition, as long as your total income in the company using it isnt earning above $100.000 a year.

Ofcause you might need to team up with some others for 3D objects, sounds, music, leveldesigns, but for a start this is great stuff.

Check out my latest "test" http://3d.d9.dk/pills/?crm

Its a PacMan kinda clone, as I've been educating many people for years on how to make PacMan games, but never actually done one myself as I found it too "simple". Well, dont tell it - show it! :o)

So my answer is: if you want to develop gams for crossplatform (PC/MAC) and perhaps later on move on to smartphones, then Unity3D is surely one of the better choices.

IF I want to move my little game onto lets say iPhone, I could buy the small iPhone licens, which is only $400 + I would need an Apple developer license ($99) + some hardware (Mac Mini perhaps) to run the Unity editor on a Mac (as Apple dont allow programs for their iOS to be compiled on nothing but Mac, but thats another storry) + an iPhone or iPod or iPad, depending on what platform you wanted to target.

The point is, that you can EASILY transfer the game from PC platform to mobile with Unity3D, so thats my goal.

Ohh and btw. I am also an experienced Flash/Actionscript 3.0 developer, but as Flash currently isnt supported on iOS and I kinda liked this real-3D engine for my semi 2.5D games, I think its great that there even is a free edition to train and get used to it first.