Tag: Overview

, , ,

  • Show off – Purchasing, Capturing and AI

    A speedy demo of the Hacktics game mode showing off some of the latest features

    As things progress, its hard to capture all changes in a single illustration. So here is a lightning example of two AI players battling over a network (hacktics game mode):

    The Hacktics game mode is all about capturing ground which generates more income which allows more expensive units to be purchased. This mode uses the ‘network’ concept such that only continuously connected captured locations generate income. Therefore it is possible to cut through an opponents network and disrupt their income. As you can see, the AI occasionally purchases additional units from one of its construction buildings.

    There are 3 units available:

    • Workers which can capture network but not attack
    • Viruses which have a direct attack
    • DDOS which have a range attack

    Each unit has a different cost and although not very visible in this video there are 3 different currencies at play. The more expensive units using the rarer currencies. In addition each location generates a different amount of income – the two ‘generator’ locations for example generate a high amount of the rarer resource.

    It takes a worker 2 actions to capture a location and the worker has 2 actions per turn. This leads to the ‘ability’ config where each type of ability that any entity can do can have associated ability config – detailing how many action points each ability costs, if it can be used multiple times a turn, if it ends the entities turn etc.

    The AI in this scenario acts reasonably intelligently (currently no training has been performed so not bad considering!). It understands the concept of the network and attempts to capture continuous locations in order to expand its income. It also attempts to purchase the most useful units it can given its current wealth. The units also attempt to engage intelligently and cause damage with an aim to get the best attack value while preserving themselves.

    Note that each entity in this scenario have direct attacks although other forms of attacks are available which have been experimented with – in particular splash attacks which causes damage to multiple units at a time.

  • 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!