How it’s going firefighters!?
We know by experience that one of the most difficult questions that are made at the beginning of a project is "What tools shall we use?". So, we would like to take this chance to tell you about the technology we are using to develop Paper Firefighters.
What tools shall we use?
As the focus of this project is to learn how to develop video games and discover what's under the hood, we are using the 3D graphics engine called OGRE. And, Why OGRE?
In case you don’t know about it, OGRE is an extensive free software library dedicated to the graphic section of video games. Roughly, this means that OGRE’s only job is to draw 3D models on screen and store the scene graph. We have chosen OGRE because we think that this is a great chance to learn how a graphic engine works, and also, interesting things can be made with Ogre as Torchlight.
But we still have to take care of input, sound, network, physics,etc. Who said that developing a game was easy ?
To handle the input we are going to use OIS and XInput libraries. OIS is one of the most used libraries in Ogre projects. Furthermore, it accepts all kind of inputs like keyboard, mouse, joystick, etc. On the other hand, we still have to decide if we are going to really use XInput, which is a Microsoft library focused for the input of XBox controllers.
For sound and music, we are undecided between FMod and OpenAL. Although OpenAL is the most used with Ogre, FMod allows us to work with tracks of differents layers that can be activated and deactivated at runtime. Thanks to this, the music can be adapted according to the game state. However, we have not decided yet which one we will use.
Having an efficient network is mandatory for a game like ours. In this case, the library that we will use is ENet, which abstracts the sockets and implements an UDP communication with different internal comprobations.
Regarding physics, we have the choice to use PhysX or implement our own engine. Due to Paper Firefighters is not going to have much physics (We will only use it only collision detection), implementing our own physics engine will make our job easier in the long run because it will adapt to our needs and not the other way around.
And last, the most probably is that we will use CEGUI to user interface.
On top of all this, we must build and architecture that abstracts from the use of these libraries. Developing a good architecture (scalable, flexible and easy to maintain) is mandatory to avoid having future issues with these libraries. Talking about architectures, even when commercial game engines as Unity or Unreal are used, thinking about it carefully could be really possitive.
With all that we explained above, we have the needed tools to build our game engine which will be able to cover every technique aspect in the developing of our game.
And that is almost the entire structure of our engine. We wish that you have found our article interesting and to say goodbye, we give you an image (with test assets) to show how this, step by step, is starting to work. :D
If you have any question or want to know some details about the project don’t doubt about it and ask us!
Thank you for reading and see you next time!