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
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.
No comments:
Post a Comment