Building Game Engine From Scrap
Author
I really need a good tutorial on how to build a game engine right from the start. Can anyone give some information regrading it? Thank You.
See RESOURCES: FOR BEGINNERS at the top of this very screen. There you can find answers to questions like, "How do I make a game?"
A "game engine" could just be a loop where you get input, calculate game physics etc., and draw the screen.
For more information about all this I recommend you purchase "Tricks of the Windows Game Programming Gurus" by Andre LaMothe. It is a good book full of wisdom for newbies.
A "game engine" could just be a loop where you get input, calculate game physics etc., and draw the screen.
For more information about all this I recommend you purchase "Tricks of the Windows Game Programming Gurus" by Andre LaMothe. It is a good book full of wisdom for newbies.
Everyone recommends Tricks of the Windows Programming Gurus but there are several others that are just as good, I''d say look around a bit before u buy.
I''m currently working on a game engine right now for DirectX7. I''m working on the DirectDraw components right now. Currently, I could use the engine to setup the whole thing with only a few lines of codes, for example:
psuedo
Engine->CreateMainWindow(args...)
Engine->SetupDirectDraw(args...)
Engine->LoadBitmaps(args)
Engine->Flip()
etc...
This is all in C++.
Anyway, if you need info, let me know at vbisme@hotmail.com
psuedo
Engine->CreateMainWindow(args...)
Engine->SetupDirectDraw(args...)
Engine->LoadBitmaps(args)
Engine->Flip()
etc...
This is all in C++.
Anyway, if you need info, let me know at vbisme@hotmail.com
break the problem up into layers. At the very base layer you''re going to need services: graphics, input, sound. The way I did it is I made a class for each, the constructor initializes everything and the destructor closes it all up. Then I have one global pointer for each. When I start my program I use new and send in the HWND etc... as parameters and it all works out. I also have this neat parser thing I wrote using inherirance, templates, conversion operators, etc... which makes it very easy to write input operators for different versions of your data format but you don''t need it.
The next layer I have is made up of things that are more specific to my game. I have a TileManager class with a bunch of static methods and a couple std::maps (one for TileImages, the other for Tiles) and some functions. I also have a physics function that takes a vector of Puppets (my class representing the physical part of an object) and deals with collisions. I have a bunch of other stuff too.
You also need a bunch of basic stuff. I have an Angle class and a Vector class, both are pretty simple and have couple operators. I have a Color class which basically wraps a unsigned long int and provides a few functions and some statics (like Color::WHITE) You don''t strictly need all this stuff but it really makes things a lot nicer.
Once you have all that, well then you''re half done.
The next layer I have is made up of things that are more specific to my game. I have a TileManager class with a bunch of static methods and a couple std::maps (one for TileImages, the other for Tiles) and some functions. I also have a physics function that takes a vector of Puppets (my class representing the physical part of an object) and deals with collisions. I have a bunch of other stuff too.
You also need a bunch of basic stuff. I have an Angle class and a Vector class, both are pretty simple and have couple operators. I have a Color class which basically wraps a unsigned long int and provides a few functions and some statics (like Color::WHITE) You don''t strictly need all this stuff but it really makes things a lot nicer.
Once you have all that, well then you''re half done.
quote:Original post by Anonymous Poster
break the problem up into layers. At the very base layer you''re going to need services: graphics, input, sound. The way I did it is I made a class for each, the constructor initializes everything and the destructor closes it all up. Then I have one global pointer for each. When I start my program I use new and send in the HWND etc... as parameters and it all works out.
These should probably be singletons rather than global pointers, depending on how pedantic you want to get.
--
no real need that I can see, I view them sort of like cin and cout. They''re always going to be initialized and there are only three of them. Also since graphics is often followed by a long method call I want the name to be as short as possible. All my other stuff I keep in classes and/or namespaces.
Basically the way to get a big project done is to break it up as much as possible, the layer approach helps in this. Each layer only needs to understand the layer directly below it (and maybe a little other stuff, you don''t want to be too strict). Oh and start small and start over. Starting over never gets you anywhere but I think it helps. You keep all the experience but you lose the bad code. You can always refer to your previous projects if you forget how to do something.
Basically the way to get a big project done is to break it up as much as possible, the layer approach helps in this. Each layer only needs to understand the layer directly below it (and maybe a little other stuff, you don''t want to be too strict). Oh and start small and start over. Starting over never gets you anywhere but I think it helps. You keep all the experience but you lose the bad code. You can always refer to your previous projects if you forget how to do something.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
