#166598 - hacker013 - Wed Feb 11, 2009 8:43 am
hey everybody,
Can someone explain how I set one up and keep them clean. And if i have one, how to easy extend them. How to debug it, error handling. And how to make a system to easy handling rooms and objects. And how to choose the librarys you gonna use. Just explain it, i think i can make it by myself :)
_________________
Website / Blog
Let the nds be with you.
#166602 - elhobbs - Wed Feb 11, 2009 2:36 pm
there are entire books on this subject. I do not think this can be answered in a forum - certainly not in a few paragraphs. I suggest you either buy a book or download the source code to an open source game engine. I think you will have better luck if you come back with more specific questions. you also may want to try modifying an existing game engine before attempting an entire engine yourself.
#166614 - silent_code - Wed Feb 11, 2009 11:13 pm
Your question sounds like there is a fixed solution to the problem, but you will have to have a few years of engine development behind you to achieve that task. It takes a lot of educated guesses the first time you design the software and you need a few tries to find good solutions to oh so many common design and implementation problems. But it's all worth the knowledge you gain from it.
The only advises I can give you at this stage are:
Define (in written form - not a full TDD though :^D ) exactly what you want to achieve.
Start small, preferably with just a game state manager - don't start with the audio / video rendering! Starting with eyecandy will make you lazy when it comes to the important parts of a game engine! (Sooner or later you will need some output though, but there is much more to a game engine, than just graphics, animation, sound, levels and whatnot, remember that.)
Save the fun parts for later! ;^D
Get the basic data structures done first. Again, don't concentrate on the game's looks in the beginning, better concentrate on software design. Use pen and paper to take notes and visualize your sub-system architectures first and test them in your mind and ask yourself: "Do I really know what is needed to and how to implement this particular feature?"
Read a good book about software design and patterns. Then read a good book about modern engine design. I cannot explicitly recommend you any books per se, though.
Also, a good knowledge of the language is needed. By that I don't mean a good knowledge of the syntax or keywords... a programming language is much more than that. This also applies to libraries.
Use asserts! They are fun! :^D
Basically, always make sure not to let invalid data pass through undetected. The more you ignore this, the more annoying things will get as time passes by.
Listen to experienced developers, but try things yourself as well! Only by trying things out you can understand them and use them properly. You are allowed to be sceptical here, but don't say anything until you can back it up by experimentation. You will learn a lot when people start to criticise you and point out your mistakes to you. Embrace your mistakes, they will be the base for your new strengths.
When things start to get boring, take a bit of time off a project. Don't start too many projects. Come back to a project as soon as you feel enthusiastic about it. Don't let too much time pass by, though.
Cancel projects you are no longer interested in. Make hard cuts, that makes things easier most of the time. Don't be disappointed when you do cancel something - you sure learned a thing or two, so you always win!
Don't announce projects that will never be published! :^D
Again: Size *does* matter and small is good! Think big, but make small steps! :^)
Stay on the path you choose in the beginning and don't hesitate to question yourself and your abilities over and over again - you will gain a lot of knowledge that way!
You're at the beginning of a long road, and I wish you good luck and a lot of fun! :^)
And finally, as elhobbs wrote: Come back later, with specific questions.
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#166621 - sajiimori - Thu Feb 12, 2009 1:12 am
I have a small tip that has large implications:
Resist adding features to existing classes/modules.
When you first write a module, decide what it's for. Imagine a 100% complete version of it. If you can't decide what features a 100% complete version would have, before you write it, then you need to think more about what the module is for.
Only add a feature to an existing module if it's missing from the module -- that is, if the module is not properly doing its job.
If you follow that rule, good code will follow in time. =)
#166625 - elwing - Thu Feb 12, 2009 7:17 am
| sajiimori wrote: |
Resist adding features to existing classes/modules.
When you first write a module, decide what it's for. Imagine a 100% complete version of it. If you can't decide what features a 100% complete version would have, before you write it, then you need to think more about what the module is for. |
a better approach, do a full and correct UML design and you won't face this case :)
#166633 - gauauu - Thu Feb 12, 2009 4:02 pm
| elwing wrote: |
a better approach, do a full and correct UML design and you won't face this case :) |
But then you have to use UML ;-)
#166637 - hacker013 - Thu Feb 12, 2009 4:42 pm
what is UML?
_________________
Website / Blog
Let the nds be with you.
#166640 - nanou - Thu Feb 12, 2009 4:49 pm
| hacker013 wrote: |
| what is UML? |
A waste of time.
Tongue in cheek, but I don't use it. Most people I've heard boast about it are not programmers. I think that says something.
More helpfully: Unified Modeling Language.
_________________
- nanou
#166650 - silent_code - Thu Feb 12, 2009 11:33 pm
I am a programmer and I don't use UML very often (and when I do, it's rarely fully conform to the standard and mostly in my head), but it's quite usefull to design and visualize big and sometimes even rather small software systems. It's a tool, like any other and like anything else, it shouldn't be denied, nor overrated. Use it, if you like it, don't if you don't. (Is that a correct english experssion?) :^D
I find UML good for documenting systems, when they are done (nothing is ever done, though, just "frozen" ;^D ). It can help you to remeber things later on, when you have to change something in older sub-systems.
Btw: You can also reverse the process and generate UML from existing source code. :^D
If you want to try it out, StarUML is a freeware "UML program." It's just a "drawing tool" (ok, it's a little more than that), and therefore won't teach you UML!
UML can be good for comminication in big teams and across companies, when you can't just ask the author of a specific system what the heck he drank before writing that particular piece of code. Uh, that wasn't a good example at all! ;^D
Well, it's also useful to new team members to get an initial overview of the target software architecture.
Also note, that UML knowledge comes in handy when you decide to study computer science some day - they make a big deal out of it. ;^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#166652 - nanou - Fri Feb 13, 2009 12:56 am
Of course there's nothing wrong with diagramming. I do feel that conforming to UML involves unnecessary time and effort most of the time. Although I'd be happier if more open source projects included some kind of diagram set, UML or otherwise.
It sounds like a good teaching tool. It's good to be formal when you're teaching theory. It just seems a lot less important in practice. By the time UML was invented, I'd completed most of my compsci study though (well, the study done in "institutions" anyway.)
_________________
- nanou
#166660 - elwing - Fri Feb 13, 2009 8:06 am
well, there's two distinct approach to UML, the one for the people who don't use it and just see it only as a class diagram, and the complete approach design where the class diagram is only a little part of the whole UML design.... and yes it is REALLY time consuming, but for big project you'll always end gaining time when it comes to add functionalities and resuse part of your project. and a game engine is generaly not one of the tinyest project you could hope :)
#166667 - gauauu - Fri Feb 13, 2009 3:58 pm
<continuing the tangent>
| silent_code wrote: |
| Also note, that UML knowledge comes in handy when you decide to study computer science some day - they make a big deal out of it. ;^) |
Really? I studied CS at UIUC (which is among the best CS programs in the US) and they never said a word about UML.
</continuing the tangent>
#166668 - nanou - Fri Feb 13, 2009 5:02 pm
@gauauu
I've no idea whether we're really getting OT with this. Discussing UML's merits seems reasonably topical for this.
@elwing
I'm more worried that when you get deep into it, your options become very limited. This comes from the claims that it is not suited for use with some paradigms. Of course I don't know first hand, but the arguments sound reasonable.
_________________
- nanou
#166682 - sgeos - Sat Feb 14, 2009 4:55 am
Failures lead to success. If you do a bad job enough times, and you consistently try to improve, you'll get it right eventually.
Listen to advice and then just give it a shot. When you realize what you did wrong, don't do that next time.
#166869 - silent_code - Sat Feb 21, 2009 1:06 pm
@ gaugau: I guess it depends on where and when you studied CS. As you can see, I live in Germany and I studied CS at the TU of Berlin, not long ago. UML was definitely featured, although not very prominently. ;^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.