EXPAND . FIGHT . CONQUER
Project planning often caused me to groan when learning it in school, but this valuable experience during Orbital Obliterators has taught me not to underestimate its importance. – Tom Day, 2015
For those that need reminding or those of whom who have just clicked onto this article, the contents below are relevant to the game “Orbital Obliterators“, and the process taken to make said game.
The original task in hand can be summed up as the following:
‘The goal of this project would be to make a simple Risk-style strategy game in which the player captures nodes (e.g. planets, countries etc.) that build up armies/fleets, which can then be used to capture other nodes.’ – Hull University, 2015
To design and implement a working strategic game in which a player (Human User) pits their wits against an opponent (Human User) to conquer the generated map. The players would achieve this by capturing nodes along the map and by using said nodes, recruit militants to attack and control further nodes as well as interact with the varying difficulty AI entities across the map.
This above Aim will be met by the completion of this list of objectives:
- Create small AI entities to play against the player with variable difficulties, sizes and goals. These AI entities will take the form of ‘mini players’ which can in some cases be allied with and otherwise played against.
- Build a generator that will populate an empty map with an arbitrary amount of nodes and strategic points, positioning the player and the AI objects sensibly to avoid unfair means.
- Create an in game GUI to allow the user to gain full control of their game objects and make wise, informed decisions as well as provide insight into the game mechanics.
- Produce a engine to handle all calculations and data flow during the operation of the game, including the sound, animation, save and load storage, GUI instructions and battle component.
- Design a unique world, set of militants and differing nodes and technology trees to make gameplay more complex and challenging.
The project definition was been quickly adapted and molded to form a basic outline specification which follows the simple points below:
- The game will be set in space, the ‘nodes’ cited above will be planets, all drawn onto a square grid in random places.
- The game will utilize blank squares on the draw grid to represent space, where a player could position and move ships to defend and attack.
- The game will include strategic objects to control to further their goals and boost their statistics.
- The game should include an AI/neutral party which also has nodes and ships to contend against.
- The player would be able to develop the nodes they capture to make them stronger and more advantageous.
- The game should contain statistics which would be used to calculate the player’s success rates.
- The game will use a turn based play style to progress the game forward, each player taking their turn sequentially, with AI entities taking a turn between each player turn.
Before the designing and construction of the project could begin, a design methodology had to be adopted, seeing as the scope of the project is so large, it is important to pick a methodology that accounts for this by including a quick development approach. It is also worthy to note that there is not customer specification to be followed in this project, and thus any methodology honed towards increases in customer interception will not be considered.
Agile Software Development
The diagram below shows a Agile Software Development (Sidky, 2013) approach to this particular project.
The Agile approach incorporates a client side mechanic, but seeing as there is not customer other than the developer, those benefits are ruled out. The ideology behind agile software development is that of creating several functionalities and testing between each one, taking a pause to see if it’s ready to be pushed out, and if not, move to the next phase. This quick approach can hit on hard times when it comes to the first release, as it is almost guaranteed to not hit the mark on any specification, or fall short of public expectations. This places a negative morale onto the client receiving the project, and that loss of faith in the developer can be the downfall of the budget.
However in this project there isn’t a sole reliance on a budget, and as the specification in the aims and objectives a set to change as the project moves on, these issues shouldn’t be a problem.
Rapid Application Development (RAD)
Below is a diagram which shows the Rapid Application Development Model.
The ideology of Rapid Application Development (ISTQB, 2015) is that a program should be got to a ‘just about working’ state as quickly as possible, so the later on objects can be considered quicker, things like the cut over phase i.e. the system handover / installation of the new program to the existing system. Seeing as there is such a large scope for this project, RAD is a worthy candidate as the methodology to adopt, as it encourages the quick development of a basic program, so that the rest of the scope can then be considered on top of this essential building block, without the need for extensive testing in what we already know is only a preliminary program. In comparison to Agile, there is far less focus on the specification, and far more focus on getting things done quickly, that work. But agile has the benefit of a phased approach and each objective in the aims and objectives section could be seen as an iteration in the respect of Agile. It is for this reason of compatibility that Agile will be adopted as the Design Methodology.
The project development will be constantly tested by means of two major methods.
- The developer upon completion of a particular task of functionality will visually test each part of said implementation, and apply immediate fixes to the problems arisen until such time that the function works.
- The developer will include Unit testing to the non-visual elements of the implementation at the end of each major iteration in accordance with the agile scheme (for each objective met). [semi-compatible with SCRUM methodologies]
The table below provides a comprehensive extract containing details of each part of the implementation that was tested. For the most part testing has been carried out as the development has continued with visual checks within the game to ensure that the nodes and objects are behaving as intended, and where they are not, bug lists have been generated and addressed in the next versions.
|Player Object||Tested by inputting false information into the front page and observing the results and whether they get passed through into the player object or caught correctly.|
|Node Object||Tested on the same line as the World Engine.|
|World Generator||Tested on the same line as the World Engine.|
|World generator – Algorithm||Randomness tested by simulating many different generations and looking for unwanted correlations.|
|World Container||Tested against different resolutions to see if the map maintains its shape.|
|Game Engine –Start-up||Tested to see whether a Loaded game from XML and a newly started game of the exact same setting are loaded identically.|
|Game Engine – Tool set||Tested throughout by using the methods in other calculations to see if any anomalies are outputted.|
|Ship/AIShip Objects||Tested for casting incompatibilities along with extensive testing on whether or not they are “seen” when appropriate in the game.|
|Float Panel||Tested by using a large map configuration and testing whether the panel correctly follows the node around as it is supposed to.|
|Overview Panel||Tested by switching turns and production types to see if the panel reflects the appropriate changes in render configurations.|
|New Game Panel||Tested by inputting invalid data to see if it disallows such entries, and tested further to ensure any settings turned on or off are reflected correctly in game.|
|Caption Control||Checked rigorously for spelling and grammatical errors|
|Battle Math||Tested for fairness and balancing, as well as correctly abiding to BODMAS principles.|
|Movement Math||Tested by moving ships about the map and ensuring they have re positioned themselves correctly.|
|World scaling Math||Tested against different resolutions. And whether the rest of the content positions itself correctly.|
|World movement Math||Tested on large map, if the world is rendered off screen does the correct behaviors occur when using the mouse to move about the map?|
|Correct Graphics||Correct graphics assignment bugs have been check to ensure each item is represented by the correct graphic, and fail-safe graphics are positioned if the graphic cannot be found.|
|Object positioning||The world engine algorithm is tested so that it doesn’t lag out when trying to calculate spaces for space objects to be render to.|
|Rendering performance||The game lag periods are measured to ensure that the rendering tasks of the program do not slow down the game to an unsatisfactory level.|
|AI decision system logic||The decision logic is tested to ensure that no deadlocking occurs and no infinite loop problems occur.|
|AI Outcome||The AI logic is tested further by simulating moments where the AI has an expected outcome and testing whether it follows that outcome.|
|GUI click Events||GUI click events are tested alongside the appropriate sounds that should be generated to ensure that each click is mapped to the correct outcome.|
|Load Time reduction||Achieved via optimization by removing all try & catch statements and adding more null checkers.|
Conceptual Designs & Forecasting
Below is the first design drawing that was produced at the beginning of the project:
Thrilling isn’t it? but it is incredible to believe that now I’m out the other end of the project, the end product was so wildly different yet so close to my dream design. The next step was to come to terms with the time plan, how I would assign my time to get the best outcome, this is shown below. In retrospect, the time plan acted as more of a guideline as it morphed and changed dramatically through the project.
Time Plan Review
This time plan is the final time plan, whereas earlier on there was a theoretical time plan that was developed with minimal prior research conducted, and it clearly shows now, after a review how inaccurate it was.
The timings were on target, but the list of tasks and what order that they’d be approached in was wrong. A prime example of this is the order in which the time plan suggested to produce the implementation, and what turned out to actually be programmatically feasible. The first part of the implementation that made sense to create first actually turned out to be the World Engine, as without seeing the world, visually commenting on the aesthetics of the game being produced proved very hard. Also, the Node class being created first came hand in hand with the World Engine, and immediately gave the development the vital push in the right direction that it needed, as these were the most visually prominent parts of the game.
According to both the old and new time plan, the project completed a week or so ahead of schedule, and this is mostly due to the drastic changes to the original time plan, as on the original time plan “Build the shell” which was meant to last 28 days, was a null task and scrapped. Allowing 28 days to go back into the pool to be reallocated.
The World Engine took far longer than 2 weeks due to the masses of problems experienced with the resolution support. I wanted to keep as many compatibility doors open as possible, and this problem involving the game not rendering correctly on anything below the resolution of 1080p caused a huge fall back. The result was having to spend another 14 days to solve it by taking into account the resolution of the users screen before any calculations occur. This is a huge learning point for the development, as not ensuring that all known variables were covered before the creation of code caused a 14 day delay.
The game works, which is the main aim. But that does not lead to say that the game is complete. There are several planned extensions to the game that will continue being developed way into the foreseeable future.
an aspect of the game that will be considered for future work is network play, so that two human players may play over a local network connection (LAN). The .NET framework contains lots of support for TCP connections and networking, which would be utilized for this. The game would load the map, and then send the map data to each player’s client and from then, send updates ad changes to each player from the host machine via a unique protocol. The protocol would most likely use byte streams to create special packets. A concept is shown below:
|0||Type 0-255||An 8 bit byte indicating what kind of information the packet holds.|
|1||Length MSB||A 16 bit byte indicating the length of the packet, giving a maximum length of 65535.|
|3||Payload||The Payload of information relative to the packet type for the client or host to carry out.|
The board game and indeed computerized version of Risk (Atari Inc., 2003) contain a Mission element where you must carry out a task whilst you play to further your goals. This is further replicated in Civilization V (2KGames Inc., 2011) & TribalWars (InnoGames GmbH, 2012) with their components of quests that must be completed to earn yourself free resources. This element was conceptually thought about, but deemed not important enough to implement into the final game, but there was thought and process that went into them as shown in this example flow diagram:
The Mission would be got on a random chance every time a player captured a node. This mimics the collection of a “Risk Card” in both the computerized and original board game. Which functioned in the same manner as described above, although the chance element is new due to the output of the focus group.
Contained in the ePortfolio on this site are multiple articles outlining how this project was made and some of the research techniques and planning that went into the project as a whole. Below are a few honorable mentions:
Conducting research whether it is market research or research into appropriate techniques is the cornerstone of any modern project and was not underestimated in this project. Read More…
Its important to look into what kind of game you’re really making… That way you can insure that you’re putting in the right level of cool when developing. Read More…
To keep a player entertained when creating a game that will intentionally last a long time, you need a robust system of content to keep them enthralled right up to the moment. Read More…
The universe is a vast empty space of unimaginable possibility, this games most defining moment has to be its attempt to capture a little of that magic with the World Engine. Read More…
To combat players not having any real friends they need someone to play against, the design and process to implement an AI decision system was the result of this problem. Read More…
Perhaps the most complex and challenging of the whole system, the main… system! The Game Engine forms the integral glue that holds and manages all the data. Read More…
2KGames Inc., 2011. Civilization V Manual. [Online]
Available at: http://www.2kgames.com/manual/civ5/civmanual_us.php
[Accessed 20 January 2015].
Atari Inc., 2003. ftp://ftp.atari.com/manuals/pc/6_times_the_fun/risk_2/riskii_manual.pdf. [Online]
Available at: ftp://ftp.atari.com/manuals/pc/6_times_the_fun/risk_2/riskii_manual.pdf
[Accessed 21 January 2015].
InnoGames GmbH, 2012. TribalWars Help Battles Wiki. [Online]
Available at: http://help.tribalwars.net/wiki/Battles
[Accessed 12 October 2014].
ISTQB, 2015. What is RAD model advantages, disadvantages and when to use it?. [Online]
Available at: http://istqbexamcertification.com/what-is-rad-model-advantages-disadvantages-and-when-to-use-it/
[Accessed 28 April 2015].
Sidky, A., 2013. History & Overview of Agile Development. ‘Agile Bootcamp’, SCG.