Category: Development

,

  • A touchy subject

    Touch input! The considerations involved with making an intuitive input system for a phone or tablet

    Touch input! Yep this is going to be a phone/tablet game so of course touch inputs are required. It has been an interesting technical exercise to convert touch inputs to the square grid based game – both short, long and drag touches being available. The game is almost ready for its alpha release so the focus is solely aimed towards usability.

    What a user wants to do and have it intuitive is interesting. Say there is a unit that the player wants to avoid being attacked by. How best to display its ‘danger range’. The unit could attack, could move, or some combination of both. Having a long hold identifying the total move+attack action is tempting. However, what if the unit has more subtle mechanics than that? If the unit has multiple different attacks that are possible, if the unit could use a combination of movement and attacks and that will change its attack pattern, some attacks being much more effective so they take priority, some units cant attack but knowing its movement range is essential… It is not straightforward when you don’t know exactly what a unit will be able to do to plan what is best to be shown to the user.

    There is the possibility of allowing the person making the configuration of each unit to choose what it wants to show. I.e if someone was making a ‘moving wall’ unit, then seeing the movement range would be most useful so that the opposition player can see if the unit has enough range to block up a strategic bottleneck. So each unit would have a set way of giving usability to the user interface. This is most likely how the development will end up but for now I have settled on if it can attack, show the attack range – otherwise show movement range.

    There will need to be an extensive test with different users as people will find different ways of interacting and what they find intuitive.

  • Configuration Issues

    Patching a dangerous process with decent alerting

    This game is very much reliant on configuration and in particular user created configuration at present. Unfortunately it is currently a ‘hand made’ process. The configuration that is created unfortunately has a high chance of user error. In the meantime I have added a *bunch* or error catching and alerting the user to the issues. It will hopefully indicate roughly where the configuration errors are found and allow the user to apply a fix. This is linked to the concept of Configuration on a Branch where when developing the new config the developer will be able to get some proper debug information so when it is ready to go live and merged with the main branch there is a reasonable confidence of it being valid.

    In the future I would like to make a tool to create the configuration in a more graphic and streamlined way but that is a long way away currently. At the very least there needs to be a schema and tooling to verify that the configuration is at the least valid. In a dream world, I would love to create a proper development pipeline with automated validation of the config – such as running the new configuration through a validation checker to ensure that the new config at least complies to the schema. Many many steps to go but for the meantime alerting users to the errors is a good start.

  • Configuration on a branch

    How development configurations are managed using branches!

    This game relies on multiple config files all pulled from the source control (github) which contains all of the details. Collaboration source control does allow multiple people to work on the same set of files without having too many conflicts to manage – if 2 people alter the same file at the same time there is a system to resolve all of the good changes. Now, when a game type is in development, not all updates need to be pushed to each game client. Therefore we have added the functionality to use different github branches in game!

    A settings menu has been added to allow global settings to be added. One of those new options in the settings menu is the config branch to use. Therefore clients can set the development branches when testing/developing a new game mode and all of the config associated for that branch will be pulled. This system means that the game engine/install does not need to be changed when switching between development or the ‘main’ branch for ‘production’ gameplay. Game files that are outdated will need to be re-downloaded but it it requires no code changes.

  • Time to buy stuff – Networking and Resources in game

    Strategy games need resources to do things with such as upgrading and building stuff. How to create a system which does this in a generic way?

    As with a lot of strategy games, there is quite commonly some form of resource that needs to be managed – for example if you had a medieval themed games then you may have food to buy swordsmen and wood to construct catapults. There may be areas of the map that supply those resources when either captured or worked on.

    How I see it, there are essentially 2 different ways that this can be managed. Probably the most common way is by having a series of global shared resources. This is when the resources are gathered and put into a single bucket which can then be spent on whatever the player wants, regardless of where things are on the map. The concept of logistics is not relevant in this style of game as for example your ‘village’ which makes the resources can be immediately spent by your ‘barracks’ and there does not need to be any consideration of connection between the two. Another implication of this is if a player has two bases, they will still share resources so gameplay will not be as isolated.

    As you have probably guessed, the second way of managing this is through a more local system of resources. This can take many forms such as discrete items of resources that need to be moved around to a networking system where resources are shared on a continuous connection requirement I.e if the enemy cuts one area that you control into 2 then they will then have 2 separated resource pools. This style can lead to the concept of logistics being more vital to gameplay and having remote bases more vulnerable and supply lines more important to protect.

    Introducing the Network

    Combining all of these concepts into a single engine could obviously be very complicated. I have therefore started with the concept of a ‘Network’. Each entity can be defined as using either a local network or the team network. These network objects look very much the same at a code level, however a local network needs to have all entities connected adjacently. Therefore if you have a game mode which only has the globally shared resources, then each team would just have a team network and each entity that can network will be subscribed to the single team network. Local networks just have the requirement that all entities are connected. You could imagine that this would lead to capturing ground types of games, or ‘wiring’ or ‘roads’ connecting strategic points together. If the network is severed, then currently the resources are split between the two networks based on the size ratio (ratio of number of entities in the resultant networks). In a single game mode, it is also possible to have a mix of team and local networks which could lead to some interesting tactics.

    Now that there is a rough outline in the buckets of resources in play, time to move onto the resources themselves. Each network will have access to the same resources types (food, wood etc). Some entities will generate more of certain resources than others and some may drain resources. Entities such as ‘factories’ can consume resources when constructing other entities. Obviously these resources will be themed to the certain game type that is being played so all of those will need to make itself into some form of configuration file. Currently the number of resources are hard coded to be up to 3 as I believe that will cover most cases. Due to the user interface considerations, having more than 3 would be more difficult as it would need to be more dynamic so as not to look cluttered.

    So there you have it, Networks are constructed which each will have its own pool of resources. Networks are either the global team network or multiple local networks. Any entity in a network has access to the resources that the network owns. Hopefully as a first implementation this will cover a large number of the desired game modes.

  • Creating the entity and map configuration

    How to deal with managing a (hopefully) large churn of the configuration without annoying users

    This game has the configuration; the stuff that actually defines how the game plays and what maps are available, from the engine. The engine is obviously essentially a load of code and is the thing that would actually be downloaded from a mobile app store and is the thing that I will be putting a load of work into. As I want that flexibility, the configuration cannot live in the code as otherwise if I or anyone else wanted to add any new maps or entities then you would need to create an update to the app (everyone hates lots of updates…). This could be frequent and I don’t want the app having constant updates, not to mention if there is more than one person working on maps and entities at the same time then it would be unmaintainable.

    What is the solution here? It is to host the configuration remotely and have the game itself pull the configuration say when the app starts or the user wants to download a new set of maps etc. Ideally I would like multiple people to contribute to the game in these ways by coming up with cool new entities and maps and graphics. Luckily there are already lots of tools that are particularly good at managing a load of files with multiple contributes – git! So the plan is to have a public git repository which will hold the configuration for all the game essentially where people can contribute to. The game engine will pull files as required down from that git repository and of course all of the power of git can be used to manage the config on the server side.

    In fact, here is the current public repository which I am using: https://github.com/James-Silvester/RealmTacticsConfig. Please feel free to have a peruse and get involved!

    Although this may change in the future, it certainly works for now and allows me to make a build of the game as a completely separate process to tinkering with the configuration that is being run. So far all of the configuration is hand done, manually constructing the structure and figuring out where things go. In the future, I would love to make a sandbox within the game itself where entities can be edited and maps created. Those could eventually get pushed up to the configuration repository so could be consumable by other people. These however are all ideas for the long long backlog…

  • How to make an enemy – Giving the enemy some brains with artificial intelligence (AI)

    Making the enemy intelligent is no easy task. The complexity of the final game will be a real challenge to make the enemy both tactical and adaptable to be an enjoyable opponent.

    I do love the idea of being able to play against human opponents. However it would also be great to be able to play the game against non-human players. Therefore an AI system will need to be created. This… how shall I put it…. will be extremely difficult. Obviously a lot of games have AI systems. Most games the AI can seem relatively complex but are actually made up of lots of individuals following simple rules that overall create complex outcomes. There are exceptions such as real time strategy games where the AI is complex but can very much make or break a game. For strategy games, if the AI is not clever enough, random enough and adaptable enough it can severely damage the gaming experience. Every time the AI does something non-human or particularly stupid, a player will learn how to replicate that situation and start exploiting the AI and ultimately break the gameplay.

    Moving back to this game, a turn based strategy game with multiple entity types and actions that each entity can perform. Games like chess it is possible to effectively simulate a bunch of possible moves and construct a decision tree, finding the best move to make based on the most favorable branches. In principle it would be possible to do the same for this game except for one thing – there are way too many possibilities. If there is an entity that can move 1 space, there are 4 possible destinations. If they can move 2 spaces, there are 12 possible spaces. 3 there are 24 spaces, 4 there are 40 etc. This is a situation that can easily get out of control when you have a lot of entities that are relatively mobile, not to mention all of the possible actions that can be taken (attack, capture etc). Considering I am wanting this to run on a phone in real time, that is very much off the table.

    So there has to be a more restrained solution where it figures out a subset of possibilities. The solution which I have come up with and currently exploring is adding ‘Features’ to a ‘Heatmap’. During an AI turn, the system will loop over all entities on the AI team and will calculate features and add them to a heatmap. Once all of the features have been calculated, the ‘hottest’ square of the heatmap is proposed, escalating to the next if the move is invalid.

    As an extra layer of abstraction, there will also be the concept of separate ‘Modules’. A module is a collection of features which link to a particular tactical decision that an entity can do. For example the ‘Attack’ module, a feature could be ‘Is enemy entity in range’ or ‘Is attack cost effective’, whereas a ‘Capture’ module feature could be ‘Distance to enemy headquarters’. Each module will calculate its best square on its heatmap and bid for its associated action to be taken.

    This will leave a hierarchy:

    • Modules which define a particular tactical decision (attack, capture, run away etc). Each module has multiple Features and a resulting action.
    • Features which are calculable values for each entity in the current map configuration. The collection of features for a module added are calculated at each position on the map, summed and added to the modules heatmap.
    • Heatmap The map grid which collects the features for a module. The best position can be found which dictates both the modules resultant action and the bid – The modules reckoning as to how effective its action will be.
    • Resulting action will be performed by the module if it wins the bid. It will move the entity to the best heatmap square and perform the modules action.

    For example, the Capture module will have a feature to capture the enemy headquaters. The best position on the heatmap will be the position closes to the enemy headquaters. If the capture module wins the bid, it will move the entity to that position and if it has reached the desire square then captures the enemy headquaters.

    The specific modules and features will need to be somewhat manually defined from experience but down the line it may be possible to train the relative weights of each feature. In theory with enough features and weighting, it would be possible to have a learning system but that is very much down the line in the distant future.

  • How does stuff actually happen – What does the entity configuration do

    Entity config time. How can a few numbers dictate how the game is actually played?

    Right back at my first post, I did mention that one of my motivations of making this particular type of game is that I have a deep love of ‘Advanced Wars’. Each entity in that game (units and buildings) can do a number of actions which take place in a series of battles against the opponents. Ultimately with the aim to destroy all of the opponents entities or complete a specific objective I.e capture the enemy headquarters.

    I certainly do not want to make a carbon copy of this game as for one it would not be as good and secondly this will be a product of my creation and I want it to stand on its own. That being said, it is a great model of how these types of games can be constructed. In particular, each entity can perform a certain number of actions which ultimately can be defined by some configuration. These actions include:

    • Movement
    • Attack
    • Capture
    • Resupply
    • Build
    • Defence

    These are to name a few but to get to the point, each ability e.g attacking can vary wildly from each unit but for the most part fall into a small set of parameters. For example, an infantry unit and an artillery unit are used very differently and their interaction can create some very interesting tactical decisions. However, they are at its core very similar from a programming perspective but just vary on the parameters I.e artillery range Is longer, its strengths against different entities are different, artillery cannot use their attack once moved etc. But those are just a series of numbers and adding the other abilities and all of the other entity configurations together, ultimately make an exquisite game with lots of tactical gameplay and replayability.

    Therefore what remains is to choose what actions to implement and for those actions, what specific properties to add. Ultimately the only consideration should be what combination of actions will make interesting gameplay.

  • Where can we play? Introducing the Map

    Next concept is a brief description of the so called ‘map’ where all of the action will take place.

    All of this entity defining is all well and good, but what do these entities do? As there needs to be a place where these entities live and do things, I am now defining the ‘Map’ or ‘Battle’ or ‘Arena’ or whatever theming that is desired. I will refer to these general concepts as the map going forward. Ultimately, the map is where all of the action will take place.

    There is a big discussion around square grid or hex grid. I believe that the hex grid is commonly considered to be superior as it does allow more movement (6 directions rather than 4) which leads to more natural gameplay. I however have decided to stick with the good old fashioned square grid as I think that it will be much easier to make and get my head round.

    So there you have it really, I have a square grid, plonk the entities on it and add some core gameplay concepts I.e teams, AI, win conditions etc and bish bash bosh, I have a game. Easy right!? Well of course there is a lot of work to go and there will need to be some decision over what these entities can actually do – as even though configuration will define all of the properties there does need to be some structure to the configuration and how they relate to gameplay.

    I think for now though I will leave that discussion up till next time…

  • Diving in – Introducing the concept of Entities and Tags

    Introducing one of the core concepts in the game, entities and tags. This will ultimately be what makes this game customisable.

    One of the core concepts that will power the game is the creation of entities and tags.

    This is actually the second iteration of the game. Initially I was adding classes for each ‘entity’ I.e I was making a class for ‘Infantry’ in the code. This is great and all assuming that you know what your game will be but I have currently no idea – ‘Infantry’ in fact is just a placeholder. As mentioned in my first post I have decided to go with the concept of more of an engine than a finished game per-say. Therefore I have scrapped that hard coded concept of each entity and came up with essentially a configuration file which defines how each Entity behaves.

    To clear up any confusion, I will give a quick definition of an entity in relations to this game:

    Entity: Every single gameplay item that a player will interact with during the core game loop will be an entity. Each map/stage will be filled with such entities where their look and behaviour are defined by the given configuration. Entities can be directly player intractable e.g units, buildings; or can be more passive or cosmetic e.g terrain, signs etc.

    The configuration which will define all properties of an entity will be defined in a json (text with structure) file. I have also considered the concept of having default values for the configuration. For example, if you wanted to define a tank and an infantry unit, there may be common configuration between the two I.e can move, cant fly, cant produce other units etc. Intruducing therefore the concept of the Tag:

    Tag: A tag defines certain entity properties without being an entity itself. Each entity can be given one or more tags which when the game initialises, will pull the tag values into each tagged entity as its defaults, being overwritten by any values given on the entity itself.

    For example, imagine having the following tags with properties:

    • Units: Can move and attack, Can be attacked
    • IndirectUnit: Cannot move and attack

    With the following defined entities:

    • Infantry: Tags: <Units>, Range 1
    • Artillery: Tags: <Units, IndirectUnit>, Range 2

    Results in:

    • Infantry: Can move and attack, Can be attacked, Range 1
    • Artillery: Cannot move and attack, Can be attacked, Range 2

    As you can see, each final entity can have much less configuration as it can be built up from tags of similarly grouped sub-configuration

    Of course with a very well documented configuration, hopefully this will lead to a usable system where one can define any iteration of the game that you can imagine.

  • Hello World! Introducing Realm Tactics

    This is the first post. Introducing Realm Tactics

    Hello World! This is my first post about a so called project ‘Realm Tactics’ game. Concept: I absolutely loved the game ‘Advanced Wars’ back on the Game Boy advanced. So much so that when finally getting round to making something myself, it is a natural choice of game styles.

    The Vision:

    Create a game/engine where creating new maps, units, buildings and everything else is just config and can be done by anyone – ultimately I want users to actually make the entertaining things and I (an engineer) can focus solely on the engine. Some may call that lazy but I’m happy to play to my skills.

    Nitty Gritty:

    As my love of the game style was ultimately born on a GameBoy, a hand-held console, this will hopefully materialise as an Android (and hopefully Iphone) app. Definitely not bounded by that but playing on the toilet is definitely how I imagine people will be using my creation (as glamorous as that sounds!)

    The basic gameplay would involve moving things around a square grid – usually themed as some sort of battle where you have to outmaneuver and defeat your opponent but I don’t necessarily want to be constrained by that. That is a very loose description and engineering constrains will require the first iterations to be much more locked in. I will create a set of functions that each entity can perform I.e movement, attack, building, capturing etc and using that some interesting game types can be put together. These will all be packed up with different graphical components and hopefully some interesting story lines. All of this is very vague at the moment but this will be an ongoing development project.

    The How:

    I don’t know yet how ‘technical’ I am going to get in this blog but thought I would get things started. I have recently picked up using Unity and am relatively comfortable with that environment (at least for nothing too flashy). This will be coded in C# as I do love a bit of well structured object oriented programming. As an ex-java developer I am happy to get stuck in with the code so not worried on that side. I have never done graphics before so, as mentioned earlier, it would be great to eventually (I mean in the far and distance future) to get things more community created.

    Help Wanted:

    This currently is a solo project but I would love to work with someone – especially for people with all the skills that I currently don’t have as unfortunately that is quite a bit. If anyone has a passion and would love to get stuck into programming, artwork, sound, storytelling, level design, publicising…. and everything else under the sun then feel free to get in contact!