I'm a big fan of turn-based strategy games like Fire Emblem, and I also really enjoyed Ankama Game's MMORPG Dofus. I want to try to create something similar to those, and it also gives me an opportunity to brush up on my C++ after a particularly long stint of C# in Unity.
The Technology
- SFML 2.3
- Visual Studio 2015
I've been working on this on and off for a little over two weeks, so this first post will detail everything that has been done so far (not a great deal) and subsequent posts will be be about whatever I have added since the previous post.
Application Class
Taken from a previous project, the Application class is an abstract class that contains an SFML Window and an update-render loop. The initialise, update and render functions are pure virtual functions, and the run function calls update and render infinitely until the window is closed. There's also a runOnce function that calls update and render a single time, which is useful when creating applications with multiple windows.
The Game
The game at present looks like this.
There's quite a bit going on here. I'll explain more in the following sections.
The grid is a collection of cells, and when the mouse cursor hovers over a cell, a translucent red circle is drawn over it.
Obstacles
The pink cells are obstacles, and characters cannot move there. They currently don't inhibit a character's movement outside of the cell in question, and a character's visible range still shows them as being a valid movement option.
Character
The characters, when moused-over, will display their movement range. When they are clicked, their movement range will be visible even when the mouse is not over them. Clicking on one of the cells in their range will move them to that cell, unless the cell is an obstacle.
Drawables
Everything that is drawn in the window necessarily inherits from the Drawable class. In previous work, when I wanted to draw something new to the screen, I would modify the render function to include the necessary code to the screen.
In one of my 4th year modules in university, I was tasked with creating a digital version of a board game (I chose Neuroshima Hex 3.0). I noticed, when reading some of the documentation from a previous student's project (their game was Forbidden Desert), that they used a single container for all drawable objects, which inherited from a common interface. Consequently, their render function just iterated through the container, drawing what was there.
They never had to modify their render function when wanting to draw new things, since they just added the new thing into the drawable container. I wanted to try implementing something like that, as I thought it would help to reduce the time taken to add new features.
I have also been considering adding it to my Application class for use in future projects. However, I'm not sure if it will be suitable in all situations, unless I can implement some kind of depth-sorting for easily determining the order in which things should be drawn. At present, if I want something to be drawn on top of something else, I have to make sure it is added to the stack later, which could potentially causes complications (or at least unnecessary overhead and breaking up my code's logical order) in a situation where object a has to be updated before object b, but object b has to be drawn before object a.
Object Pooling
When I first implemented range highlighting, the game logic would check each frame if a character had to display their range, then create, draw and destroy each highlight object. This is really inefficient.
I remembered hearing about a concept called object pooling from somebody giving a presentation at my usiversity's Game Development Society. Rather than creating and destroying a series of objects each frame, range highlights are instead created when they are needed, and instead of being destroyed, they are kept, and just not used if they don't need to be used that frame.
The potential downside of this, however, is that I could end up in a situation where a very mobile character on a very large map creates several hundred highlights, and then when the character is removed from the game those highlights are never used again and just take up memory.
This could be remedied by occasionally removing any unused objects after, for example, 10 seconds. I have an implementation of this in mind, and will probably implement it soon.
This ties in nicely with how rendering is handled, since now I just have a container full of highlight objects, and I pass in the pointers to any objects that need to be drawn.
Final Thoughts
The game so far is very bare-bones, and there is a lot more I would like to add. However, I would prefer these posts to largely focus on what has already been achieved, as I'm worried about scope-creep (something I'm particularly susceptible to) killing my projects.