Console Game Engine Structure
Has anyone made a console game engine?
I want to make one by using as many classes as possible keeping the OOP structure but I''m not quite sure about the structure of it when it comes to consoles. Does anyone have any recommendations of how I should go about this?
This will be my step before I head off into the grand world of Win32 programming.
Rob Loach
Current Project: Go Through Object-Oriented Programming in C++ by Robert Lafore
"Do or do not. There is no try."
- Yoda
For anything. It will be generic.
Mainly for a text RPG/Adventure.
Rob Loach
Current Project: Go Through Object-Oriented Programming in C++ by Robert Lafore
"Do or do not. There is no try."
- Yoda
Mainly for a text RPG/Adventure.
Rob Loach
Current Project: Go Through Object-Oriented Programming in C++ by Robert Lafore
"Do or do not. There is no try."
- Yoda
Define what you need to do. Create classes around it. It''s up to you to figure out the details, they will always change.
For example, in writing a strategy-based rts game that would have a *lot* of menus, I made a class called "CMenuController." Whenever I wanted to display a menu and collect input, I could do it on one line by saying something like input = MenuController.ShowMenu("MENU_NUM_PLAYERS"), where ShowMenu would read and seek inside a .dat file until it found the ''MENU_NUM_PLAYERS'', then ask the appropriate question found in the file until valuable input was recorded (also defined in the file), then return that information. This abstracted a lot of the tedious work, which is what every good ''engine'' should do, isn''t it?
For example, in writing a strategy-based rts game that would have a *lot* of menus, I made a class called "CMenuController." Whenever I wanted to display a menu and collect input, I could do it on one line by saying something like input = MenuController.ShowMenu("MENU_NUM_PLAYERS"), where ShowMenu would read and seek inside a .dat file until it found the ''MENU_NUM_PLAYERS'', then ask the appropriate question found in the file until valuable input was recorded (also defined in the file), then return that information. This abstracted a lot of the tedious work, which is what every good ''engine'' should do, isn''t it?
can''t realy comment too much on just console games without more information, but here are some of the broad categories you wont want to forget to think about:
Core Input Method - you will need to think about the complete set of input scenerios you intend to supprt ... for instance, will you have any mouse input? Will you read characters as pressed, and support holding keys down, or simply accept lines of input. What about things like ALT-TAB and CTRL-C?
The answer to these questions will affect your game structure quite a bit, because for one thing, most old style console apps are NOT message based (they just use an int main() and a while loop without creating a windows or message queue) - this might or might not be satisfactory for a modern version.
Output Library - do you want to only think of output in terms of text sent to the console, in lines ... or will you support things like ASCII art, borders, clearing the screen and using the bottom or top lines as a status display (latter zorks had this)
If Text / Adventure Game - then you will need to create a system for command parsing and processing ... and allowing this to be built out of some for of grammer would be nice ...
more to say, but going back to work
Core Input Method - you will need to think about the complete set of input scenerios you intend to supprt ... for instance, will you have any mouse input? Will you read characters as pressed, and support holding keys down, or simply accept lines of input. What about things like ALT-TAB and CTRL-C?
The answer to these questions will affect your game structure quite a bit, because for one thing, most old style console apps are NOT message based (they just use an int main() and a while loop without creating a windows or message queue) - this might or might not be satisfactory for a modern version.
Output Library - do you want to only think of output in terms of text sent to the console, in lines ... or will you support things like ASCII art, borders, clearing the screen and using the bottom or top lines as a status display (latter zorks had this)
If Text / Adventure Game - then you will need to create a system for command parsing and processing ... and allowing this to be built out of some for of grammer would be nice ...
more to say, but going back to work
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement