I'd like to introduce a map/framework I am working on called Reckoning. At its core Reckoning is a framework for turn based strategy games, though the initial implementation is heavily catered towards the map I am making. To make this post more sensible, I'll just refer to the map and framework as the same thing.
I'm going to log progress towards the map here.
Concept Overview
Reckoning is loosely based off of turn based strategy games such as Civilization and Advance Wars. It will feature a customizable turn based system where a game can be run in different speeds of one of two modes: traditional turn based, where each player must wait for all others to complete their turn, or pseudo-real time, where all players perform their turn at the same time.
It uses a hexagonal grid system like that seen in Civilization 5 and supports different types of in game terrain. Each grid cell in the game can have a different type of "terrain," with its own vision, movement costs, and other various attributes. Units are given a movement maximum per turn and the game solves a shortest path problem to figure out the optimal path for your unit to get to location:
The terrain system is designed such that the terrainer does not need to have knowledge of the workings of the game to make terrain. After doing traditional terrain design, the terrainer simply places regions or special units to distinguish in game terrain types on the map. This way multiple maps can be created for the same general game.
The game will play a lot like Advance Wars, with many different unit types available that are produced from various buildings on the map. The overall objective will be to capture all enemy capital.
So far I have implemented a lot of the data structures that are hidden behind the scenes. The map is entirely written using Andromeda, an OOP extension to Galaxy. Here's a pretty screenshot of what developing this map looks like most of the time:
Though I've written a ton of code, there isn't enough done to actually play the game yet. I ran into some interesting problems which might be useful to others:
Triggers have an execution limit, which is probably based on a certain number of instructions they can execute. I have a few complicated functions that iterate over a lot of data, so they were exceeding this limit. It turns out that the Wait() function causes the trigger to sleep (all triggers are run in their own thread) and when it resumes, it has a fresh execution limit. So by putting in things like:
Wait(0.0,c_timeGame):
You can make your trigger force a context switch and reset its execution limit. This does of course slow down the code a little bit (since even the minimum wait - 0.0, is at the mercy of the trigger scheduler to resume execution), but in my experience it can be optimized by carefully testing and seeing how often to insert these Wait() commands.
Another issue that is actually a big deal for this map is the 2MB memory limit. Maps in Starcraft can only reference up to 2MB of memory which means that the sum of all global variables and text (actual program code) in your map cannot exceed this. The way I do shortest paths right now, I need an N by N array of integers which represent the weight between any two nodes in the graph. Using a hexagonal graph, there are N = 169 nodes in the maximum unit range (7) in the map. Not only do I need one of these, I actually need one of these for each player in the game if I want them to be able to act at the same time. I'm aiming for an 8 player limit, so this set of weights alone takes up 913952 bytes, or almost half of the memory I have to work with. If someone can think of a good way of chopping this down - I'm all ears. I can't move it into local memory because local memory is limited to only 32k. I'll probably try and figure this out sometime in the future.
Side note - working with hexagons created a few cool problems to solve, such as:
How many hexagons are there within a radius r of some point?
What are the positions of them in game
User Interface
I've started creating a custom UI for the game. The UI is once again done in code and I have a pretty nice class hierarchy going on that makes creating new things relatively painless, but as many of you probably know, working with dialogs is a bit of a pain.
That's the current work in progress. The textures are all placeholders until I can do or select better.
The upper right part of the screen will display the player's resources, income, army count, and how many turns have elapsed in the game.
Below that is the event log. When one of your units takes damage, is killed, a building takes damage or is captured, or an enemy comes into your vision, it generates an event. The event log shows the first 8 events in your event queue. These can be clicked on to center your vision at the event epicenter and have a small description in the tooltip of what happened. This makes it easy to track what's going on in big battles as the game gets more complicated.
Clicking on an event or clicking on the "X" button will dismiss it, making new events fill the list if they exist. I'm working on some cool animations for these - right now the events fade in when they show up, and I plan on having them slowly move up to replace removed events.
The bottom right contains the minimap and end turn button. There's nothing special about the minimap going on. The end turn button will actually change functionality when you have units that can be commanded - it will bring you to the units that still need instructions before it allows you to end your turn.
Still to be created and not in the picture: the bottom left will contain information on the unit you currently have selected and contain a list of its available commands. Highlighting a unit will cause another display to pop up, showing combat stats if you already had something selected.
Other Random Things
I had to disable smart clicking for the map because I don't want people to be able to move units without going through the new UI, and I didn't want to do anything fancy with creating movement behaviors and such. However, this led to the problem that right clicking on the minimap still gave a unit a move order and circumvented the smart click disable. I got around this by creating a trigger that makes sure that only units that are allowed to move can move.
I just finished the general animations for the events list. Took a while longer than I wanted it to because I ran into some bugs where the events would shoot off the screen at really high velocity. Anyway, I'm really pleased with how it came out:
As you cans see in the video, dismissing an event causes the other events to scroll up to replace it. New events show up at the bottom most empty spot, fading in. If the user clicks on a bunch of events, they take this into account and all adjust position at an appropriate rate to compensate for that.
In the final version, the events will actually correspond to things going on in the game - so clicking on one will take the player to that event location. Clicking the X will exhibit the behavior shown here.
Good luck, just so you know, i'm having plan for a map based on advance wars also, a lot of stuff are implemented exactly like you did. Gameplay might be different
Edit: The trigger execution limit is a trouble for me also, wait 0.0s wont solve it in most cases, guess it was even more serious in hexagon. (it was about 300000 calculation in a loop as I can tell)
It has a few bugs which can be easily worked around and that are patched relatively quickly. I'm finding it a easy to use and very stable overall. The standard library is still a little lacking but covers most things you could need already.
Will there be some sort of "cutscene" battle short that occurs when units wants to engage combat with each other?
There needs to be more map that does this, maybe risk maps would be interesting with turns, and cutscenes for infantry vs infantry etc.
Making the waiting more bearable if you get to watch cutscenes.
How it can work can be similar to Advanced wars:
You can either have 5 units or 10 units to represent 100%, so for each whole 20/10% that drops, 1 unit dies, but unit death only occurs in a specific order.
i.e: You don't have a column of infantry and have them randomly die when they lose "life" as a whole, they die in order (top to bottom or specific pattern).
If you don't like doing physical coding and stuff, always know that it's possible to get video or pictures embedded to make your "scene" look decent. No need to work out unit animations and such when you can get a video running that shows exactly that? Meaning you put tiny clips into your map that plays when unit vs unit battles?
Will there be some sort of "cutscene" battle short that occurs when units wants to engage combat with each other? There needs to be more map that does this, maybe risk maps would be interesting with turns, and cutscenes for infantry vs infantry etc. Making the waiting more bearable if you get to watch cutscenes.
I'm debating whether the map will include anything like that. Most people I know end up turning these kind of features off eventually when they play these types of games, so if it is included there will definitely be a way to turn it off. The intention of this is also to basically create a style of playing were you do a very minimal amount of waiting, since all players will be able to act out their "turn" at the same time.
Nice! i really like the grid movement system. could be cool to use it to make a Lords of the Realms 2 remake(not 3, seriously that was one of the worst games ever made.. they removed everything good about lords)
I am trying to find out how to make a grid based movement map. I plan to make a box-grid type map. A lot like chess but not exactly.
Any tips on how i can code this into Galaxy editor? My plan is the ff:
1. map will have a 9x8 box grid
2. units move 1 grid at a time
3. it is a turn based map
Also, is there a way to make units look different to your opponents? For example, I have a Zealot but to my opponent it would look like a probe.
Thanks of any help in advance.
Reckoning (Working Title) - Progress Log
I'd like to introduce a map/framework I am working on called Reckoning. At its core Reckoning is a framework for turn based strategy games, though the initial implementation is heavily catered towards the map I am making. To make this post more sensible, I'll just refer to the map and framework as the same thing.
I'm going to log progress towards the map here.
Concept Overview
Reckoning is loosely based off of turn based strategy games such as Civilization and Advance Wars. It will feature a customizable turn based system where a game can be run in different speeds of one of two modes: traditional turn based, where each player must wait for all others to complete their turn, or pseudo-real time, where all players perform their turn at the same time.
It uses a hexagonal grid system like that seen in Civilization 5 and supports different types of in game terrain. Each grid cell in the game can have a different type of "terrain," with its own vision, movement costs, and other various attributes. Units are given a movement maximum per turn and the game solves a shortest path problem to figure out the optimal path for your unit to get to location:
The terrain system is designed such that the terrainer does not need to have knowledge of the workings of the game to make terrain. After doing traditional terrain design, the terrainer simply places regions or special units to distinguish in game terrain types on the map. This way multiple maps can be created for the same general game.
The game will play a lot like Advance Wars, with many different unit types available that are produced from various buildings on the map. The overall objective will be to capture all enemy capital.
Oct 1st - What's been done to date
Coding Stuff
So far I have implemented a lot of the data structures that are hidden behind the scenes. The map is entirely written using Andromeda, an OOP extension to Galaxy. Here's a pretty screenshot of what developing this map looks like most of the time:
Though I've written a ton of code, there isn't enough done to actually play the game yet. I ran into some interesting problems which might be useful to others:
Triggers have an execution limit, which is probably based on a certain number of instructions they can execute. I have a few complicated functions that iterate over a lot of data, so they were exceeding this limit. It turns out that the Wait() function causes the trigger to sleep (all triggers are run in their own thread) and when it resumes, it has a fresh execution limit. So by putting in things like:
You can make your trigger force a context switch and reset its execution limit. This does of course slow down the code a little bit (since even the minimum wait - 0.0, is at the mercy of the trigger scheduler to resume execution), but in my experience it can be optimized by carefully testing and seeing how often to insert these Wait() commands.
Another issue that is actually a big deal for this map is the 2MB memory limit. Maps in Starcraft can only reference up to 2MB of memory which means that the sum of all global variables and text (actual program code) in your map cannot exceed this. The way I do shortest paths right now, I need an N by N array of integers which represent the weight between any two nodes in the graph. Using a hexagonal graph, there are N = 169 nodes in the maximum unit range (7) in the map. Not only do I need one of these, I actually need one of these for each player in the game if I want them to be able to act at the same time. I'm aiming for an 8 player limit, so this set of weights alone takes up 913952 bytes, or almost half of the memory I have to work with. If someone can think of a good way of chopping this down - I'm all ears. I can't move it into local memory because local memory is limited to only 32k. I'll probably try and figure this out sometime in the future.
Side note - working with hexagons created a few cool problems to solve, such as:
User Interface
I've started creating a custom UI for the game. The UI is once again done in code and I have a pretty nice class hierarchy going on that makes creating new things relatively painless, but as many of you probably know, working with dialogs is a bit of a pain.
That's the current work in progress. The textures are all placeholders until I can do or select better.
The upper right part of the screen will display the player's resources, income, army count, and how many turns have elapsed in the game.
Below that is the event log. When one of your units takes damage, is killed, a building takes damage or is captured, or an enemy comes into your vision, it generates an event. The event log shows the first 8 events in your event queue. These can be clicked on to center your vision at the event epicenter and have a small description in the tooltip of what happened. This makes it easy to track what's going on in big battles as the game gets more complicated.
Clicking on an event or clicking on the "X" button will dismiss it, making new events fill the list if they exist. I'm working on some cool animations for these - right now the events fade in when they show up, and I plan on having them slowly move up to replace removed events.
The bottom right contains the minimap and end turn button. There's nothing special about the minimap going on. The end turn button will actually change functionality when you have units that can be commanded - it will bring you to the units that still need instructions before it allows you to end your turn.
Still to be created and not in the picture: the bottom left will contain information on the unit you currently have selected and contain a list of its available commands. Highlighting a unit will cause another display to pop up, showing combat stats if you already had something selected.
Other Random Things
I had to disable smart clicking for the map because I don't want people to be able to move units without going through the new UI, and I didn't want to do anything fancy with creating movement behaviors and such. However, this led to the problem that right clicking on the minimap still gave a unit a move order and circumvented the smart click disable. I got around this by creating a trigger that makes sure that only units that are allowed to move can move.
October 2nd - UI Events Update
I just finished the general animations for the events list. Took a while longer than I wanted it to because I ran into some bugs where the events would shoot off the screen at really high velocity. Anyway, I'm really pleased with how it came out:
As you cans see in the video, dismissing an event causes the other events to scroll up to replace it. New events show up at the bottom most empty spot, fading in. If the user clicks on a bunch of events, they take this into account and all adjust position at an appropriate rate to compensate for that.
In the final version, the events will actually correspond to things going on in the game - so clicking on one will take the player to that event location. Clicking the X will exhibit the behavior shown here.
Good luck, just so you know, i'm having plan for a map based on advance wars also, a lot of stuff are implemented exactly like you did. Gameplay might be different
Edit: The trigger execution limit is a trouble for me also, wait 0.0s wont solve it in most cases, guess it was even more serious in hexagon. (it was about 300000 calculation in a loop as I can tell)
How is it like working with Andromeda? Is it in the state ready for general use yet?
@Colawaffle: Go
It has a few bugs which can be easily worked around and that are patched relatively quickly. I'm finding it a easy to use and very stable overall. The standard library is still a little lacking but covers most things you could need already.
@progammer: Go
I hope they both turn out pretty differently.
Will there be some sort of "cutscene" battle short that occurs when units wants to engage combat with each other? There needs to be more map that does this, maybe risk maps would be interesting with turns, and cutscenes for infantry vs infantry etc. Making the waiting more bearable if you get to watch cutscenes.
How it can work can be similar to Advanced wars: You can either have 5 units or 10 units to represent 100%, so for each whole 20/10% that drops, 1 unit dies, but unit death only occurs in a specific order.
i.e: You don't have a column of infantry and have them randomly die when they lose "life" as a whole, they die in order (top to bottom or specific pattern).
If you don't like doing physical coding and stuff, always know that it's possible to get video or pictures embedded to make your "scene" look decent. No need to work out unit animations and such when you can get a video running that shows exactly that? Meaning you put tiny clips into your map that plays when unit vs unit battles?
I'm debating whether the map will include anything like that. Most people I know end up turning these kind of features off eventually when they play these types of games, so if it is included there will definitely be a way to turn it off. The intention of this is also to basically create a style of playing were you do a very minimal amount of waiting, since all players will be able to act out their "turn" at the same time.
@AzothHyjal: Go
omg you sir are a patriot. This could be the beginning of new turn based gaming like civ and fallout and such
Nice! i really like the grid movement system. could be cool to use it to make a Lords of the Realms 2 remake(not 3, seriously that was one of the worst games ever made.. they removed everything good about lords)
Hello,
I am trying to find out how to make a grid based movement map. I plan to make a box-grid type map. A lot like chess but not exactly. Any tips on how i can code this into Galaxy editor? My plan is the ff:
1. map will have a 9x8 box grid
2. units move 1 grid at a time
3. it is a turn based map
Also, is there a way to make units look different to your opponents? For example, I have a Zealot but to my opponent it would look like a probe. Thanks of any help in advance.