History: RTS Sample App
Source of version: 3 (current)
Copy to clipboard
!!Introduction This framework should provide a good starting point for a Real Time Strategy (RTS) style application. Major features include: * Uses the [http://www.ogre3d.org/wiki/index.php/Paging_Scene_Manager|PLSM2] SceneManager * Input via [http://www.ogre3d.org/wiki/index.php/Using_SDL_Input|SDL]. (Use the DLL listed at the end of that wiki article) * Uses [http://www.cegui.org.uk/modules/news|CEGUI] for the UI. * Key remapping capabilities, with saving/retrieving from a text file. * [http://www.ogre3d.org/wiki/index.php/Managing_Game_States_with_OGRE|Game State] architecture, with loading and exit screens. * Object selection: area dragging and single object (hold CTRL key to add to selection). * Multiple unit selections: CTRL-0 through CTRL-9 create a selection, and 0 - 9 recall that selection. * Mini-map. * Compass/location indicator. * [http://www.ogre3d.org/wiki/index.php/Quaternion_and_Rotation_Primer#Misc|Dual SceneNode] camera implementation, with pitch restrictions. Discussions regarding this application can be found here: [http://www.ogre3d.org/phpBB2/viewtopic.php?t=14032|RTS style sample app] !!Patches required to Ogre __Addition to the SDL file SDL_keysym.h__ At the end of the first enum declaration (which starts with SDLK_UNKNOWN), add the following definitions: {CODE(wrap="1", colors="c++")} /* Add any other keys here */ SDLK_LMB = 323, // Mouse button 1 SDLK_RMB = 324, // Mouse button 2 SDLK_MMB = 325, // Mouse button 3 SDLK_WHEEL_UP = 326, // Mouse wheel UP SDLK_WHEEL_DN = 327, // Mouse wheel DOWN SDLK_LAST {CODE} (Don't re-add SDLK_LAST. It is listed here just to demonstrate where the addition goes. !!Downloads/History The application was built using Microsoft Visual Studio 7.1. ''10/04/2005'' Initial release. Full application, with Debug and Release versions of DLLs and LIBs: [http://www.greygames.com/Ogre/TestApp_Full_2005-10-20.zip|Full App] (22491k) Source and data only, no DLLs or LIBs: [http://www.greygames.com/Ogre/TestApp_Src_2005-10-20.zip|Src Only] (4078k) ''10/20/2005'' Updated to CEGUI [http://1.0.5|1.0.5] (as of 10/20/05) IMPORTANT: This uses the latest [http://www.cegui.org.uk/modules/news/|CEGUI] from their CVS. It will NOT work with the version shipped with Ogre! (as of 10/20/05) The include files from CEGUI will have to be copied to Ogre\Dependencies\include. Full application, with Debug and Release versions of DLLs and LIBs: [http://www.greygames.com/Ogre/TestApp_Full_2005-10-20.zip|Full App] (21688k) Source and data only. No DLLs or LIBs: [http://www.greygames.com/Ogre/TestApp_Src_2005-10-20.zip|Src Only] (4078k) Minimal update: all source and changed/new data. No DLLs or LIBs: [http://www.greygames.com/Ogre/TestApp_Min_2005-10-20.zip|Update] (356k) ''10/24/2005'' Changed PlayState to use Functors instead of static member functions. Source only: [http://www.greygames.com/Ogre/TestApp_Src_2005-10-24.zip|Src Only] (12k) !!Program Flow and the Game States There are three Game States in this application: # IntroState # PlayState # CreditsState The program starts in main.cpp, which simply creates an instance of a GameManager object, and tells that object to "start" (Ogre initialization), then to switch to the IntroState. !!!IntroState The IntroState first displays the IntroScreen bitmap, then waits for PLSM2 to complete loading. In a full application, this is where the rest of game initialization would occur. !!!PlayState The PlayState is where the meat of the game runs. (mmmm.... meat) New commands should be added in the function InitializeCommandMap, with a corresponding new command handler. !!!CreditsState On entry to the CreditsState, the CreditsScreen bitmap is displayed for a predetermined amount of time (exitable by hitting ESC), then the application is shut down. !!NotificationsOverlay This is a handy way of providing notifications to the user. It is implemented as a FIFO (first-in-first-out) stack, with up to 10 (easily configurable in code) notifications on-screen simultaneously. Each notification will be displayed for 30 seconds (again, easily configurable in code), then go away. Usage is simple: {CODE(wrap="1", colors="c++")} notificationsOverlay->AddNotification(textString, ColourValue(1.0, 1.0, 1.0, 1.0)); {CODE} Sample of notifications display: {img src="img/wiki_up/Client_2005-10-20.jpg" alt="Client_2005-10-20.jpg"} !!Using the UI In order to get the UI to play nicely with the InputHandler, the InputHandler must be notified when a keyboard-enabled component of the UI (such as an editBox) gets or loses focus. For instance, in the KeyConfig dialog, the last line of the show() function informs the InputHandler that the UI has the focus: {CODE(wrap="1", colors="c++")} InputHandler::getInstance()->SetGUIHasFocus(TRUE); {CODE} And in the HandleCancelButton() function, it tells InputHandler it has lost focus: {CODE(wrap="1", colors="c++")} InputHandler::getInstance()->SetGUIHasFocus(FALSE); {CODE} For an editBox that is displayed, but doesn't have focus, an event handler must be added to inform the InputHandler when the user selects that editBox. In the Console dialog, the editBox (which is always displayed) is wired to an event: {CODE(wrap="1", colors="c++")} rootWindow->getChild(EntryBoxID)->subscribeEvent(Editbox::EventMouseClick, Event::Subscriber(&Console::handleMouseClick, this)); {CODE} And in the handleMouseClick() function, the InputHandler is informed in the usual way that the UI has the focus: {CODE(wrap="1", colors="c++")} InputHandler::getInstance()->SetGUIHasFocus(TRUE); {CODE} This allows the InputHandler to decide when to send key commands to the PlayState, so as the user types in an editBox, those keystrokes won't be interpreted as commands.