Retro 2d shoot 'em up engine
I''m planning to write a traditional 2d shoot ''em up, e.g. Gradius, Axelay, ... with horizontally scrolling, multi-layered, tile-based graphics.
I''ve made some simple games, I''m above average in C++, but I want to learn to code more structured and cleaner. Now as far as I understand, all graphics stuff is best handled separately by an engine, but I have little insight as to what this engine should do (which functions it should provide) or how an engine fits in the whole of a game (is it a class, how do I use it, ...). I''d like to make it general enough to use it in a top-view RPG later on, but this is of secondary importance.
Could anyone provide some answers? Thanks
Buy, buy, buy...
You''d think this place was festering with ''NSync fans!
The "engine" metaphor isn''t always appropriate. Essentially, an engine is a collection of functions and variables that maintains information on what you want drawn, how to draw it, and what inputs it''s receiving. Sounds a lot like a class, doesn''t it?
Engines are restrictive, though, and it''s hard to repurpose many engines (FPS engines are invariably used for FPS games, though Tribes RPG is a notable exception). I have an "application class" that maintains information on Win32 and DirectX (and hides all the specific code) and utlizes function pointers to allow extensibility. That way a function for a particular game can call another graphics function created specifically for that game, going beyond the inherent capabilities of the engine without modifying its code .
I think this is a very robust design, sort of like having plug-ins, but at compile-time rather than run-time. My class even provides a message pump and a window procedure which the application''s window procedure can fall back on or chain to. Different subsystems of the "application object" can be initialized and manipulated individually, making it possible to use this class for other types of multimedia applications beyond games. Think of it as my own Game-centric MFC.
Hope that helps.
You''d think this place was festering with ''NSync fans!
The "engine" metaphor isn''t always appropriate. Essentially, an engine is a collection of functions and variables that maintains information on what you want drawn, how to draw it, and what inputs it''s receiving. Sounds a lot like a class, doesn''t it?
Engines are restrictive, though, and it''s hard to repurpose many engines (FPS engines are invariably used for FPS games, though Tribes RPG is a notable exception). I have an "application class" that maintains information on Win32 and DirectX (and hides all the specific code) and utlizes function pointers to allow extensibility. That way a function for a particular game can call another graphics function created specifically for that game, going beyond the inherent capabilities of the engine without modifying its code .
I think this is a very robust design, sort of like having plug-ins, but at compile-time rather than run-time. My class even provides a message pump and a window procedure which the application''s window procedure can fall back on or chain to. Different subsystems of the "application object" can be initialized and manipulated individually, making it possible to use this class for other types of multimedia applications beyond games. Think of it as my own Game-centric MFC.
Hope that helps.
Thanks a lot!
So if understand correctly you can choose just how much your engine provides to your game from only drawing to more complex things like physics (but making it very application specific then), and it''s just an abstraction layer for your game mechanics.
So if understand correctly you can choose just how much your engine provides to your game from only drawing to more complex things like physics (but making it very application specific then), and it''s just an abstraction layer for your game mechanics.
By Jove I think you''ve got it!
Yes, think of the engine as simply an abstraction. If you REALLY want to write cleaner code, write a design doc. Make this as detailed as you can get about EVERY aspect of your game. When you are done, making an object model should be easy. You will likely want an application class, perhaps a screen class (to cover the directX stuff), a sprite class, map class...you get the point.
As you look at this, you may realize that some of this code could be reused in other similar games. The more code that''s reusable, the cleaner and better structured your code turned out.
Now for the caveat... Games sometimes take liberties with code structure. Don''t get so carried away with making the perfect object model and reusable classes that your game runs like mud. Speed is your first concern for the engine. Of course, the engine is secondary to gameplay (can''t wait to see the flames for that line), so when you have to compromise, do so in the right places.
Good luck
Richard "Eboz" Ashkettle
Yes, think of the engine as simply an abstraction. If you REALLY want to write cleaner code, write a design doc. Make this as detailed as you can get about EVERY aspect of your game. When you are done, making an object model should be easy. You will likely want an application class, perhaps a screen class (to cover the directX stuff), a sprite class, map class...you get the point.
As you look at this, you may realize that some of this code could be reused in other similar games. The more code that''s reusable, the cleaner and better structured your code turned out.
Now for the caveat... Games sometimes take liberties with code structure. Don''t get so carried away with making the perfect object model and reusable classes that your game runs like mud. Speed is your first concern for the engine. Of course, the engine is secondary to gameplay (can''t wait to see the flames for that line), so when you have to compromise, do so in the right places.
Good luck
Richard "Eboz" Ashkettle
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement