This article is written for experienced developers using the C# language and the Monogame Framework. Monogame is in active development with a new release just published recently. This piece is highly technical and requires that developers be proficient in their chosen language of choice. Therefore there is no information that will enable new programmers to work with the sample code easily.
The title prefix, “Part I”, indicates an expectation that as this project progresses into a war game I hope to develop over time that simulates a major conflict of the 18th century, it is hoped that as new code is developed additional articles will be published with the intent of guiding developers in such a difficult form of game development.
Because this piece is published on both Microsoft and Java Community sites, there is information in this piece that should make it easier for Java developers to develop similar code for their own projects. However, the Java information is limited since such a piece cannot provide code and explanations for both languages as the libraries used are completely different from each other
It should also be noted that there is code in the provided project that is no longer currently used but was left as reminders for further development as the project progresses. Such code is noted in this piece.
Due to the length of this piece, a downloadable Word document is available at the following link…
The complete project for this paper can be downloaded from the following link…
To submit questions to the author regarding the provided information, please email the author at…
One of the most difficult aspects of developing a game is one in which the genre you would like to develop for is such a niche area of development that standardized tools have yet to be created for it. With the popularity of 3D graphic art and gaming the 2D aspect of this creative endeavor hasn’t kept pace with current technologies to the same degree. For 3D game development there are several popular genres that have a wide degree of support; first-person-shooters, simulations (ie: racing, flying), adventure games, and strategic simulations, which are in many cases simply war games on steroids without the thought provoking challenges that a turn-based game of the same genre can provide. For such development there are excellent tools freely available, the most popular being “Unity”, which also has a wide array of 3rd party support in the form of add-ons that provide tools for all the mentioned game types.
With 2D development, scrolling games have been developed to the point that there are many excellent articles describing how to implement one with quite a bit of sample code along with a few very good toolsets to help a developer in his or efforts.
The one genre in 2D development that has gotten very little or rather uneven exposure in the development area is that of the original turn-based, hexagonal map, war game. And beside the original style of adventure gaming whereby the “maze like” foundations were quite thought provoking, war gaming itself has been considered the top of all such mental challenges and at one time was even promoted for the “over educated”.
However, with a lack of some level of standardized tools for such development, this realm of gaming has probably become one of the most difficult areas in creative activity within the game development field. There are several reasons for this that has been described in a number of texts on the subject.
For starters, the computer AI in such games is at a terrible disadvantage compared to the Human opponent since the Human opponent can take as long as he or she likes to develop tactics and strategies that if done carefully over time will not only defeat the computer AI but yield weak spots in it that can aid the player in increasing their battlefield wins somewhat consistently.
In an article describing such a situation within the “Civilization” series of games it was found in one case that players were able to defeat the AI in one significant area of lumber yields by repeating the creation of forests in a single hex, deforesting the hex through lumber production, and then seeding a new forest to start the cycle over again. The AI in the game could not do this giving the Human player a significant advantage in such production, which in turn allowed the Human player to build wooden-based entities more quickly than the AI could.
Though Firaxis Games has openly admitted that their “Civilization” AI cheats (and pretty unfairly as well), when they realized this weakness (called “lumberjacking”) in their AI, they issued a patch placing the AI and the Human opponent on equal footing in this part of the game, making “lumberjacking” no longer possible by the Human player.
The result of this drawback in turn-based war games is that the AI implemented in such games has to be quite good in order to make the game not only enjoyable but repeatable as well. Thus, turn-based war games require above average AI implementations that are more than just what any pre-made tools can offer.
In addition, the AI implementation has to be suited for the level of war game being developed. In such games there are three primary types of AI that can be used, strategic (large unit formations such as divisions), tactical (medium sized unit formations such as regiments), and squad based where each unit represents a single piece of equipment or a soldier. And in each case the AI implementation, as mentioned, has to be done quite well.
This is not the same as with RTS games (real time strategy) where the Human player is at a disadvantage being that he or she must stay on their toes to do battle with an aggressive AI whereby studying the battlefield for any length of time is not an option. The result is that most such games are not very realistic in terms of technique since in reality, as fast as it may occur, war would never be as fast as a computer emulation would propose unless it was designed to be such as with in-depth military training emulations. The lightning fast movements for example in the “Battlefield” franchise could never occur since Humans cannot react at such speeds normally.
The next area of difficulty in the development of turn-based war games are the graphics employed. With the exception of some tile mapping tools that provide the ability to create maps using hexagonal tiles, the developer still has to use original programming to control the map and the units portrayed on it once it is loaded. And since such maps can have a variety of sizes, no one code base offered will necessarily be able to provide the mathematical calculations for the chosen sizes for any individual developer. That being said, one of the most popular mapping tools is “Tiled” (http://www.mapeditor.org/), which will allow a developer to create large hexagonal maps through a visual interface.
“Tiled” creates maps using the “TMX” format, which is actually code that describes a map to a graphics system. Both “Monogame (with the Monogame.Extended plugin)” (http://www.monogame.net/) for C# and VB.NET developers and “libGDX” (http://libgdx.badlogicgames.com) for Java developers support this file type allowing a developer to display his or her maps somewhat easier than if one were to do it on using just the graphics engine and their tiled images.
This article then will describe one way that a hexagonal map can be created and displayed at the lowest level; using the “Monogame” graphics engine only with individual tiled images.
Read more of this post