One course that I had during this spring semester was called Game Programming V, where the main focus was on AI theory and programming.
There was a lot of new theory during this course, but it was useful nonetheless. It covered both simpler for of AI like path-finding (using A* and similar techniques) and decision trees as well as more complex forms of AI like neural networks. This is a lot to talk about in just one blog post, but if there is one thing that the course thought me is that AI does not necessarily have to be hard, if you think of what you actually need for AI in your game.
One technique that I have used for some of the games I've made so far is called a finite state machine, which can be described (simplified a bit) as a class that keeps track of what state a the game, a character or whatever is currently in. If certain conditions becomes true, then the state changes. A concrete example of this would be a unit who's first stage is patrolling an area. If an enemy unit walks into a units vision, the state of the unit might change to defend or something else. This is rather simple to code, but can still be interesting AI in a game.
Another example of AI decision making that isn't necessarily boring (in my opinion) is in the Long War mod for XCOM: Enemy Within. At the start of each month, the aliens will make a decision on what kinds of missions that they will send against the player based on two factors; how much they perceive XCOM as a threat and how much resources they have available. Even if their decision is only based on two factors, it can still create interesting scenarios in the long run. Granted this also depends on other factors as well.
2015-07-09
2015-06-18
Final version of my thesis work
The final version of my thesis work (That I talked about earlier) has now been formally passed by my examiner. The feedback that I got from my examiner was mostly to clarify some things in the thesis and fix spelling and grammatical errors. One thing changed since the last post was the value of the gas resource. Previously it was valued at 1.4 minerals but in the final version it was valued at 1.6 minerals instead, with the justification being available in the thesis
More summary of my works at Campus Gotland will come later.
The thesis can be downloaded from the DiVA archive here:
The file "fulltext" is the thesis itself and the file "attachment" contains an Excel spreadsheet with the data that was used in the thesis
2015-06-01
Overview of my thesis work
It was a while since I last wrote something here, but now I'll write about what I did for my bachelor thesis work. My thesis was about the internal economy in RTS games; more precisely StarCraft II: Heart of the Swarm. My thesis was about if you could look at cost per DPS as a way to approach game balance on.
So how did I approach this matter? As the first step of the process, I decided to break down the various properties of all units in the game, with the most important properties being their cost and their DPS values. After lots the data had been gathered, average values were calculated for all the various properties. Both total averages and average per individual race in the game was calculated.
In order to make the analysis easier, I decided to treat a unit's cost as just a single variable, minerals. 1 unit of gas assumed to be slightly higher than 1.4 minerals (The total mineral cost of all units divided by the total gas cost of all units equaled roughly 1.4). Even though the exact number used may not have been ideal, it simplified the analysis process.
After that, the analysis process begun. Here, I would look at some units and mechanics in the game, compared their properties to the average values and make an analysis on if the units had some benefits or drawbacks for its cost/DPS ratio.
One example of this is the Protoss unit Dark Templar. Even though it's cost is very close to the average cost in the game (302 and 305 mineral respectively). And despite this, if the Dark Templar would have costed according to the average cost/DPS ratio (which was 27,8 minerals/DPS), it would have needed to cost 722 minerals (as the Dark Templar almost have 26 DPS). I figured that the Dark Templar has some drawbacks that compensates for it's high DPS (in relation to it's cost): it has very low health and a fairly long build time.
Another example of this included the Zergling unit (belonging to the Zerg). If a Zergling were to cost according to the average cost/DPS values in the game, it would have needed to cost 160 minerals, compared to 25 minerals that it costs now. I assumed that one of the reasons for this was because the Zergling is among the units with the lowest health in the entire game.
I did this kind of analysis for 1 mechanic and about 3 different units per race in the game. This study was obviously not a complete one, due to the time available for the thesis. But in the end I got to the conclusion that it could be possible to approach game balance by looking at a unit's cost/DPS ratio. I do however feel that the subject needs to be approached with caution, because when I was doing the analysis, some units came of as being way to powerful for their cost (among them the Zergling unit)
The full thesis, as well as the complete data used for the theis, will be posted here when it passes all the required formalia. Lastly, I want to give a big thanks to my tutor Jakob Berglund-Rogert for tons of valuable feedback during the process of writing the thesis.
So how did I approach this matter? As the first step of the process, I decided to break down the various properties of all units in the game, with the most important properties being their cost and their DPS values. After lots the data had been gathered, average values were calculated for all the various properties. Both total averages and average per individual race in the game was calculated.
In order to make the analysis easier, I decided to treat a unit's cost as just a single variable, minerals. 1 unit of gas assumed to be slightly higher than 1.4 minerals (The total mineral cost of all units divided by the total gas cost of all units equaled roughly 1.4). Even though the exact number used may not have been ideal, it simplified the analysis process.
After that, the analysis process begun. Here, I would look at some units and mechanics in the game, compared their properties to the average values and make an analysis on if the units had some benefits or drawbacks for its cost/DPS ratio.
One example of this is the Protoss unit Dark Templar. Even though it's cost is very close to the average cost in the game (302 and 305 mineral respectively). And despite this, if the Dark Templar would have costed according to the average cost/DPS ratio (which was 27,8 minerals/DPS), it would have needed to cost 722 minerals (as the Dark Templar almost have 26 DPS). I figured that the Dark Templar has some drawbacks that compensates for it's high DPS (in relation to it's cost): it has very low health and a fairly long build time.
Another example of this included the Zergling unit (belonging to the Zerg). If a Zergling were to cost according to the average cost/DPS values in the game, it would have needed to cost 160 minerals, compared to 25 minerals that it costs now. I assumed that one of the reasons for this was because the Zergling is among the units with the lowest health in the entire game.
I did this kind of analysis for 1 mechanic and about 3 different units per race in the game. This study was obviously not a complete one, due to the time available for the thesis. But in the end I got to the conclusion that it could be possible to approach game balance by looking at a unit's cost/DPS ratio. I do however feel that the subject needs to be approached with caution, because when I was doing the analysis, some units came of as being way to powerful for their cost (among them the Zergling unit)
The full thesis, as well as the complete data used for the theis, will be posted here when it passes all the required formalia. Lastly, I want to give a big thanks to my tutor Jakob Berglund-Rogert for tons of valuable feedback during the process of writing the thesis.
2014-10-12
First look at basic GDI graphics programming
One of the courses that I'm currently studying is called Advanced C++ for Games II, where we are currently working with GDI for rendering of simple programs that will eventually develop into a racing game. GDI is a core component of the Windows operating system, where it handles simple rendering onto devices such as monitors.
So far we have only worked with various things related to the very basics of 3D-rendering, drawing triangles. And why is that? The reason is because a triangle is the minimal geometrical figure that is always certain to have a flat surface, and it's therefor why all 3D-models in the end is a collection of several triangles.
Below is a screenshot of what our program currently looks like. It's may not seem like it is very much, but now we have the basics of rendering a triangle implemented, which is a huge step in the right direction if making this a proper 3D-game.
So far we have only worked with various things related to the very basics of 3D-rendering, drawing triangles. And why is that? The reason is because a triangle is the minimal geometrical figure that is always certain to have a flat surface, and it's therefor why all 3D-models in the end is a collection of several triangles.
Below is a screenshot of what our program currently looks like. It's may not seem like it is very much, but now we have the basics of rendering a triangle implemented, which is a huge step in the right direction if making this a proper 3D-game.
2014-09-30
An Introduction to Introductory Programming with Java
I'm currently studying a course called Introductory Programming with Java (Swe: Inlednande Programming med Java) at Campus Gotland.
In the course, we work with an Interactive Development Environment called Greenfoot. The environment comes with functionality that can be used to develop simple top-down games like 2D-shooters or simple puzzle games.
So far this course has been going pretty smoothly for me, as the course is meant for people who are completely new to programming. And compared to what I've been thought in my other programming courses at Gotland, the concept that we are being thought here are pretty simple. My reason for taking this course though was because of a combination of that there were no other interesting courses and I figured that a refresher course in Java couldn't have hurt (I studied Java in high-school for 2 years).
Although I don't have much impressive to show of right now, I'll show some of what I've been working on later.
In the course, we work with an Interactive Development Environment called Greenfoot. The environment comes with functionality that can be used to develop simple top-down games like 2D-shooters or simple puzzle games.
So far this course has been going pretty smoothly for me, as the course is meant for people who are completely new to programming. And compared to what I've been thought in my other programming courses at Gotland, the concept that we are being thought here are pretty simple. My reason for taking this course though was because of a combination of that there were no other interesting courses and I figured that a refresher course in Java couldn't have hurt (I studied Java in high-school for 2 years).
Although I don't have much impressive to show of right now, I'll show some of what I've been working on later.
2014-06-03
Post GGC-thoughts
So GGC is now finally over. Despite technical issues and that the demo ghost was present for me during GGC, I was still able to show of what I made during this course.
Feedback on my game
I couple of people came over and tried my game at the Gotland Game Conference. One thing that many people said was that the game needed more polish and that the player should have gotten more feedback, but it is a good base to keep developing the game further with. And If I'm going to be honest, that's all fair feedback, these are certainly things that could improve with my game.
Beyond that, this GGC proved to me once again that you cannot satisfy everyone all the time, some people liked the game more then others. But overall, I get the feeling that the game is something that could be developed further.
Future plans
Because of what I got to hear about the game at GGC, I'm going to keep developing the game. I can't currently give an exact timeframe for all of this, but here are a couple of things that will happen with the game in the future.
Feedback on my game
I couple of people came over and tried my game at the Gotland Game Conference. One thing that many people said was that the game needed more polish and that the player should have gotten more feedback, but it is a good base to keep developing the game further with. And If I'm going to be honest, that's all fair feedback, these are certainly things that could improve with my game.
Beyond that, this GGC proved to me once again that you cannot satisfy everyone all the time, some people liked the game more then others. But overall, I get the feeling that the game is something that could be developed further.
Future plans
Because of what I got to hear about the game at GGC, I'm going to keep developing the game. I can't currently give an exact timeframe for all of this, but here are a couple of things that will happen with the game in the future.
- More feedback to the players. This was the thing that I got to hear the most of at GGC, and as a result this is something that will have high priority going forward with this project.
- Add the missing mechanics. The GGC prototype does not contain all mechanics that i want to have in my game and I will keep developing
- More units to the game. As of right now, you only have one unit that deals randomized damage values. This will change in the future, more units will be added to the game as time goes on.
- Improvements to the back-end code. Towards the end of this project, more and more of the code was done in a way that only enabled it to work at GGC, while not providing the possibility to expand the game later on. With new code, I will hopefully be able to add...
- ...Network Support. It's not an RTS game if you can't play it against another human player. I will work on adding network support to the game in order to make this happen. I will write another blog post later about my plans on this front are.
2014-05-24
Final sprint for GGC
Next weeks is GGC, and I'm now on the last sprint for the prototype that will be shown at the GGC show floor.
And how far have I come with the prototype? Well, I'm basically done with it. All the systems are now functional and almost everything graphics related is implemented. The thing that is left for me to work on a fog-of-war system, add some particle effects, fix a few bugs, change a few numbers in the code, and then I'm ready to go.
Improving feedback
One thing that I got feedback on during the beta testing, which we had earlier this week, was that I need to give the players more feedback to what's going on within the game. I've been adding sound effect when the various units are in combat with each other. I've also made it is so that the unit that you currently have selected is rendered using different materials than the other units
New fog-of-war system
During this week, my teacher gave me a fog-of-war system that I could use in my game. And for most of the part, it was basically drag-and-drop to implement that system properly. The system worked in the way that the main camera was essentially all black, and then you put fog-of-war revelers on your game objects to show parts of the map.The system had one issue though. There was a hair-thin line between revealing to much and to little of the map. As a result, I decided to ditch that system and instead start working on another system. I can show more once I get the system to function properly.
Other improvements
I will also look into adding particle effects to the units when they are in combat. I will also fix the last few bugs that exists in the game. But other than that, the prototype is looking in good shape.
And how far have I come with the prototype? Well, I'm basically done with it. All the systems are now functional and almost everything graphics related is implemented. The thing that is left for me to work on a fog-of-war system, add some particle effects, fix a few bugs, change a few numbers in the code, and then I'm ready to go.
Improving feedback
One thing that I got feedback on during the beta testing, which we had earlier this week, was that I need to give the players more feedback to what's going on within the game. I've been adding sound effect when the various units are in combat with each other. I've also made it is so that the unit that you currently have selected is rendered using different materials than the other units
New fog-of-war system
During this week, my teacher gave me a fog-of-war system that I could use in my game. And for most of the part, it was basically drag-and-drop to implement that system properly. The system worked in the way that the main camera was essentially all black, and then you put fog-of-war revelers on your game objects to show parts of the map.The system had one issue though. There was a hair-thin line between revealing to much and to little of the map. As a result, I decided to ditch that system and instead start working on another system. I can show more once I get the system to function properly.
Other improvements
I will also look into adding particle effects to the units when they are in combat. I will also fix the last few bugs that exists in the game. But other than that, the prototype is looking in good shape.
2014-05-17
Warbreaking Point Weekly Round-up - May 10th-17th
More and more progress is being done on this game right now.
State Machine Progress
The work on the finite state machine of the units is going forward; I have one more bug to fix on this front (and I've managed to narrow down the possible causes for this bug) and then this part of the units will be done. However so far there hasn't really been much of a game and that's another thing that I've been working on.
Resource System, Constructing Units and Goals of the Prototype
I managed to get some kind of resource system to function this week, so I can demonstrate a demo of the game next week. It's not exactly as I want the final game's resource system to function, but it is at least something.
Now I'm working on a system to create units manually in the game. Currently the state machine bug above is putting a stop for my progress on this front, but once I manages to find that bug I think things are going to go smooth from here on. How this system will work is that the player will press a button on the keyboard and if the player as sufficient resources, a unit will spawn near the player's base. I wanted it to function a bit differently, but due to a bug that I (and a few friends that I ask) can't wrap my head around why it is happening, I went with this solution instead.
For GGC (The conference where all the students show of their games), the goal for the player will be to eliminate a certain amount of enemy units in order to win the game. This was chosen because it should be relatively easy to implement. Even though I want to have the player to destroy the opponent's building as the goal of the game, it would require more work in order to function properly, as well as a general overhaul of how the back-end code of the game works.
State Machine Progress
The work on the finite state machine of the units is going forward; I have one more bug to fix on this front (and I've managed to narrow down the possible causes for this bug) and then this part of the units will be done. However so far there hasn't really been much of a game and that's another thing that I've been working on.
Resource System, Constructing Units and Goals of the Prototype
I managed to get some kind of resource system to function this week, so I can demonstrate a demo of the game next week. It's not exactly as I want the final game's resource system to function, but it is at least something.
Now I'm working on a system to create units manually in the game. Currently the state machine bug above is putting a stop for my progress on this front, but once I manages to find that bug I think things are going to go smooth from here on. How this system will work is that the player will press a button on the keyboard and if the player as sufficient resources, a unit will spawn near the player's base. I wanted it to function a bit differently, but due to a bug that I (and a few friends that I ask) can't wrap my head around why it is happening, I went with this solution instead.
For GGC (The conference where all the students show of their games), the goal for the player will be to eliminate a certain amount of enemy units in order to win the game. This was chosen because it should be relatively easy to implement. Even though I want to have the player to destroy the opponent's building as the goal of the game, it would require more work in order to function properly, as well as a general overhaul of how the back-end code of the game works.
2014-05-09
Warbreaking Point Weekly Round-up - May 3rd - 9th
This week has been a slow week for me and the development of the game. There are two main reasons for this. The first has been that I have been sick during parts of the week, and therefore haven't had as much energy to work on this as I've hoped. The second reasons is that things have been going slowly overall, solving issues has taken more time than I anticipated. But some progress has been done, and now it's time to talk about what.
The State Machine for the Unit
This week I have been working on the units Finite-State Machine (or just State Machine for short). And this has been proven to be harder than I anticipated. There are essentially two parts of the State Machine that the units will have in my game.
The first part is a State Machine that automatically changes the internal unit type of the unit as required. And why is this needed in my game? The reason is because of how the the system I use for the grid, tiles as well as movement is built up internally; you can only have one unit of each unit type at a single tile at any given time. However; units from different units type can be on the same tile at the same time, and the type can be changed while the game is in progress. I manged to get this code to work, I just have some occasional bug left to fix and then this is done.
The second part of it is a State Machine that changes a unit's state based on the events on the board. For example, if a unit from one player is on the same tile as a unit from another player, then the two units should go into combat with each other. And this part in particular has taken more time than I anticipated. I only managed to get the very basic parts of this to work this morning. I will need to spend time during the weekend and next week to implement it properly. But I believe that it is doable to get done relatively soon
Work-in-progress screenshot
Here are one work-in-progress screenshot of the game. All the graphics are placeholders for now and they will be replaced with new graphics later on.
The State Machine for the Unit
This week I have been working on the units Finite-State Machine (or just State Machine for short). And this has been proven to be harder than I anticipated. There are essentially two parts of the State Machine that the units will have in my game.
The first part is a State Machine that automatically changes the internal unit type of the unit as required. And why is this needed in my game? The reason is because of how the the system I use for the grid, tiles as well as movement is built up internally; you can only have one unit of each unit type at a single tile at any given time. However; units from different units type can be on the same tile at the same time, and the type can be changed while the game is in progress. I manged to get this code to work, I just have some occasional bug left to fix and then this is done.
The second part of it is a State Machine that changes a unit's state based on the events on the board. For example, if a unit from one player is on the same tile as a unit from another player, then the two units should go into combat with each other. And this part in particular has taken more time than I anticipated. I only managed to get the very basic parts of this to work this morning. I will need to spend time during the weekend and next week to implement it properly. But I believe that it is doable to get done relatively soon
Work-in-progress screenshot
Here are one work-in-progress screenshot of the game. All the graphics are placeholders for now and they will be replaced with new graphics later on.
2014-05-02
Warbreaking Point Weekly Round-up - April 26th - May 2nd
Another week of development has passed and more work is being done on this project. Here's what I managed to achieve this week.
I got a logo for my game!
With help from one of the staff members at Campus Gotland, Lina Tonegran, I finally got myself a logo for this game. I gave some ideas of what I wanted, she gave my some sketches and eventually we landed on the final logo of the game.
Once again, thank you so much Lina.
Get the input, grid and movement system to work
After much sweat, I finally managed to implement the input, grid and movement systems inside the game. This was achieved by looking into the code for the scripting package Tile Based Map and Nav (Which is the base that I've been working from) and try to adopt the included code so that it could fit my game. It took some time to get right and it also took some time to debug it all, but I finally manged to make the core system of my game to work.
Some fixes still remains to be done on this front though, but most of it is now ready for further development.
Design decision: Max 3 units from one player can occupy a tile at any given time
I mainly based my decision on 2 big reasons. The first one is because of how Tile Based Map and Nav is working internally. Each tile in the game is assigned certain values for it's tile type. For example, it could be a land tile, an water tile or both at the same given time (For example, in an harbor). This makes it tricky (but not impossible) to make a general code that can handle a big amount of units on each tile at any given time.
The other reasons is that it would be to tricky to manage squares that has to many units on them at any given time. I noticed this when I was playing Europa Univeralis 4 a while back (that has a similar systems to those I want to have in my game), and I noticed it was hard to proper manage provinces that had multiple units on them at the same time. This is not a major problem in EU4, as you can pause and unpause the time in that game. However, my game is a real-time so unlimited unites per square isn't going to work all that well
Because of this, I decided that on each given tile, there can only be three units from each player at a single given time.
Implementing simple 3D-models
Even though I'm currently only using placeholder units from the grid system that I bought at the Unity Asset Store, I've managed to implement 3D-models into my game. It's just placeholder models for now, but it's enough for the development of the game for now. I'm not an artist, and my priority right now is to make the gameplay function properly.
I got a logo for my game!
With help from one of the staff members at Campus Gotland, Lina Tonegran, I finally got myself a logo for this game. I gave some ideas of what I wanted, she gave my some sketches and eventually we landed on the final logo of the game.
Once again, thank you so much Lina.
Get the input, grid and movement system to work
After much sweat, I finally managed to implement the input, grid and movement systems inside the game. This was achieved by looking into the code for the scripting package Tile Based Map and Nav (Which is the base that I've been working from) and try to adopt the included code so that it could fit my game. It took some time to get right and it also took some time to debug it all, but I finally manged to make the core system of my game to work.
Some fixes still remains to be done on this front though, but most of it is now ready for further development.
Design decision: Max 3 units from one player can occupy a tile at any given time
I mainly based my decision on 2 big reasons. The first one is because of how Tile Based Map and Nav is working internally. Each tile in the game is assigned certain values for it's tile type. For example, it could be a land tile, an water tile or both at the same given time (For example, in an harbor). This makes it tricky (but not impossible) to make a general code that can handle a big amount of units on each tile at any given time.
The other reasons is that it would be to tricky to manage squares that has to many units on them at any given time. I noticed this when I was playing Europa Univeralis 4 a while back (that has a similar systems to those I want to have in my game), and I noticed it was hard to proper manage provinces that had multiple units on them at the same time. This is not a major problem in EU4, as you can pause and unpause the time in that game. However, my game is a real-time so unlimited unites per square isn't going to work all that well
Because of this, I decided that on each given tile, there can only be three units from each player at a single given time.
Implementing simple 3D-models
Even though I'm currently only using placeholder units from the grid system that I bought at the Unity Asset Store, I've managed to implement 3D-models into my game. It's just placeholder models for now, but it's enough for the development of the game for now. I'm not an artist, and my priority right now is to make the gameplay function properly.
Prenumerera på:
Inlägg (Atom)