Game Design Tools Recognize Hex Tile Game Board

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 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.

*Author's notes:

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 here.

The complete project for this paper can be downloaded here.

To submit questions to the author regarding the provided information, please email the author at

[email protected]

Overview

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" , 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)" for C# and VB.NET developers and "libGDX" 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.

For Java developers only

Being from the Microsoft side of the fence, I develop in either VB.NET or C# as I am fluent in both. For such a discussion, this does the Java Community little good to only have my sample code as a base-line for their own efforts. As a result, I have done a bit of research for Java developers who want to use their language for game development. As mentioned in my previous article, Java is not very high on the list for use in game development but it is getting more tools to work with.

So for starters, Java Developers who want to try their hands at war game development would want to first get a hold of the Java graphics engine, "libGDX", which can be freely obtained at the link provided above. You will also find some very good books that can be purchased either from the "libGDX" site or from Amazon. And unlike on the "Monogame" side of things, Java developers have an advantage in that that these books appear to be recent publications. We "Monogame" developers still have to rely on XNA documentation but this will change in time as "Monogame" continues to move away from this discontinued platform and becomes its own standard as it has started to with its latest release, which no longer relies on any XNA framework technologies but is now providing direct support for "DirectX" and "OpenGL".

Now that you have a good game engine you will also need to understand the differences between my C# code and what you would do with Java. An excellent article on the Microsoft's Community web site, "The Code Project", provides a rather extensive side-by-side example of Java and C# code, which includes the gaming code as well. It may not be totally complete but from the looks of this piece, it should provide you with a good grounding to understand what I have done. The article can be found here.

There is also a rather extensive set of tutorials for using "libGDX" with Java at the "Games From Scratch" web site, which can be found here.

C# and Java developers… Let's begin

Please note that Monogame still uses the Microsoft XNA namespaces for compatibility purposes with prior releases of this engine. This is expected to change in a future release.

When working at the lowest levels in game design such as with the "libGDX" or "Monogame" engines or directly with either "DirectX" or "OpenGL", such infrastructures often provide for pre-defined "game loop" events and methods that you have no control over. Thus to work with these constructs successfully you have to understand them to bend them to your will. Since the "game loop" processing runs in a continuous cycle you have to ensure that all of your own code falls in line properly with such requirements or nothing in your game project will run correctly. Note that the "libGDX" engine does not provide explicit "game loop" internals as "Monogame" does, though it provides for the same set of "game loop" events through an "Application Listener". However, there are implied internals that a Java developer can take advantage of through his or her own coding.

To begin with then, after you have installed either "libGDX" or "Monogame" you first must create a new project. With "libGDX", as far as I can tell, you will be offered a dialog box with a number of options for you to initiate your project with. Not being a Java developer I am taking this information from the "libGDX" site documentation, which demonstrates the use of a "libGDX" platform add-on to do this called "Gradle". See the "Gradle" interface below:

"Gradle" allows you to set up your project for the platform you would like to build your game for. In our case, we would want to select "Desktop". By the way, "Gradle" will interface with the following popular Java development IDEs:

• Eclipse
• Intellij IDEA and Android studio
• NetBeans
• Commandline

With "Monogame", we simply select the type of project we want by selecting from the installed list of "Monogame" templates in Visual Studio as shown below. As a note, those who are Visual Studio developers should ensure that they are using Visual Studio 2013/2015 on a 64bit machine… The 64bit machine requirement will be explained later in this piece.

In our case, we want to select the "Monogame Windows Project".

Once you initiate the creation of your project, two things will be defined for you. The first is the link to your framework's internal "game loop". The "game loop" cycles through repetitively listening for actions that fire one of the events that are now defined in your primary game module. It should be noted that "libGDX" does not have an explicit "game loop" since it is a purely event driven game engine. However, it does have implied "game loop" mechanisms, which Java developers can take advantage of. This information is cited in the article at the link previously provided.

So in the case of Java and the "libGDX" engine, you will have the following events defined in your primary module…

For C# we will have the following similar events defined for us in our "Game.cs" module, a result of the "Monogame" project initialization…

To see the exact correlations between the sets of events\methods between the Java and C# languages see the section titled, "Game Loop" in the cited "Code Project" article.

Creating your class level declarations for the primary game module

Whether I write in VB.NET or C#, I always compartmentalize my module code into specific areas in the document. In Visual Studio these are referred to as "Regions", which can be expanded or collapsed by the developer for legibility. "Regions" merely provide comment headers to each area and can be nested within each other as well. "Regions" allow for the immediate recognition of the types of code contained in each. There is no equivalent in Java per-se since such a feature is based upon the IDE that a Java developer uses. Thus the posting at the following link can assist Java developers in incorporating them into their specific IDE if they have not already done so.

As to my own class level declarations for the primary game module, I have defined the following assignments…

#region Class Level Declarations  	    // Microsoft.Xna.Framework.Graphics.GraphicsAdapter.DefaultAdapter.CurrentDisplayMode.Height;     // Microsoft.Xna.Framework.Graphics.GraphicsAdapter.DefaultAdapter.CurrentDisplayMode.Width;              private int        ciScreenHeight = 600;                 private int        ciScreenWidth = 800;                   private int        ciRowPosition = 0;             private int        ciColumnPosition = 0;              private string     csScrollDirection = "";  // R,L,U,D              private MGWorkBench_ScrollingHexMap.Classes.TileMap          coTileMap;             private MGWorkBench_ScrollingHexMap.Structures.HexTexture2D  coHexTexture2D;                          private Microsoft.Xna.Framework.Input.KeyboardState          coKeyboardState;             private Microsoft.Xna.Framework.Graphics.Texture2D           coTexture2DTile;             private Microsoft.Xna.Framework.Graphics.SpriteBatch         coSpriteBatch;             private Microsoft.Xna.Framework.Graphics.SpriteFont          coSpriteFont;             private Microsoft.Xna.Framework.GraphicsDeviceManager        coGraphicsDeviceManager;          

Share this post