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.

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

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.

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.

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.

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.

Warbreaking Point Weekly Round-up - April 18-25th

After a deserved Easter break together with my family, I'm now back on track with new mental energy for the Big Game Project. First of all, I have decided on a proper title for my game, which is "Warbreaking Point". This was just something that I came up in my head while I was getting back from the Easter holiday.

Then, I'll talk about what has also happened since the last post. Since that time, I've been looking into the Unity Asset Store for assets and useful technology for my game. So far I've found 2 technologies and 1 asset  pack that I will use for this project:

• Tile Based Map and Nav is a scripting tool that allows the creation of tiled grids (both square- and hexagon-based tiles), and some useful functionality that comes along with it; like simple path-finding for moving from one square to another. After looking into the source code and a couple of examples that was included with the purchase, I think this is going to work out great for my game. I will need to make some adaptations to the code that was included with this pack, but I don't think that it is going to be too big of an issue, as it already has a good foundation of what I need going forward with my project.

• GoogleFu is an Unity editor extension that allows you to export data from Google Spreadsheets into Unity and access the data from there, with no need for internet connection once the spreadsheet is exported. This was the daily deal and the Unity Asset Store a few days back and I bought it because it could come in handy when I (hopefully) develop this game with a full team next year; as Google Spreadsheets are a good way of collaborating when several people are working on something together.

• Even when working alone, GoogleFu is also useful because it allows you to extract game variables (like a unit's health, speed, attack damage and so forth) into an external file rather than hard-coding it into the game. As a general rule, you should never hard-code numbers into a game's code, as you might want to use that number in several places in the code and if you had hard-coded it into the game, you'd had to change it in several places if you every decide to change it and you might very well miss one variables because of this. This also allows people to understand your code better, as the number 100 does not really tell what it is used for; while a variable named Unit_Infantry_Health is very informative, even for those how are not directly involved with your project.

• 300+ 2D Projectiles, Icons, and Items is a collection of various icons for usage in games. I bought this because it's made by an Indie Developer whom I am personally a big fan of, and it had some useful stuff that I could use for the GUI in my game.

Overall, it feels really good that I've now started looking into how to make my game. I feel that I can accomplish a vertical slice to show at Gotland Game Conference. It may not be a full game, but my teachers want to see what I can do of the concept

In the relatively near future, I'm planning on making my concept/design document publicly available for everyone to watch and submit feedback on. 

Project Clint Weekly Roundup - April 12-17

This weeks round-up post comes a bit early because it's Easter and all what that means.

Sitting with Unity
While not complementing previous courses, I've sat more and trying to learn myself the Unity game engine. I'm starting to get a hang of how the engine and the  scripting system and such is working, although this will probably be a constant process as the development goes along. I feel ready to start working for real next week.

Talking to teachers
I've been talking to my teacher about this project as well, and I've made some small changes to my plan based on what happened during those talks. No change were major though.

Next week - Grid and movement system
Next week I finally start working on this game for real, and then my main task will be to get the grid/movement system working, and the subsystems that are required for that to work properly (like A* for the movement system and the unit's path-finding). This task is being done first partly because of that this is a part of the core mechanic of my game, partly because of that the other tasks related to this one should be easier to implement once this system is on place

Big Game Project Weekly Roundup: April 7-11

My first, real week of the Big Game Project is now finished. From now on, I  will blog at least once a week, and do some weekly roundup on what happened during the week.

April 7-9: Talking to my teachers about what to do
I spent the first three days of this week talking to my teachers about what I should do during the course since I was the last man standing while every other Big Game Group was filled. In the end, we decided to let me work alone on a vertical slice of the game I pitched to them earlier in the course, and hopefully make the game in  full next year.

The reason why I didn't pitch this concept for the rest of the class was not because of the fact that it was a bad idea. In fact, my teachers really liked my idea and they really wanted me to keep working on it. The thing was that since this is a strategy game, you'll need lots of  Rock-Paper-Scissors triangles of units and such to keep it interesting (Håkan thought that 12 different units was the bare minimum required for the game to be interesting). It would simply be to much work for the Big Game Project, even if we were to work in a big group. That's why I'm only making a vertical slice now

April 10-11: Learning the basics of Unity
The past few days, I've been sitting and trying to learn myself the Unity game engine; which I only have limited experience since earlier on. I've been mostly sitting with a stealth game tutorial from Unity's official site. So far I have a hang of how things work with the engine and such

Next week: Keep learning Unity
As planned together with my teachers, I will keep sitting and learning myself Unity the next week. I will look into more tutorials, as well as reading a book on Unity that I got to borrow from my teacher that it very up-to-date.

Looking ahead: Assets
Since I'm not an artist, I'll most likely download/buy assets from the Unity asset store and work with them. My teacher also told me that there might be a person who can help me with the GUI of the game, but that comes later.

Announcing "Project Clint"

Since I was the last man among my class that was without a group after all groups were filled, I talked to my teachers about what to do. After listening to a few suggestions and having discussions about it, we arrived at the conclusion that I would work on a vertical slice/prototype about a certain part of the idea that I pitched to my teachers last week, and then make the full game once the third year starts.

So that's why I'm announcing my project, which until I've decided on a better title will have the working title "Project Clint" (After Clint Barton, aka Hawkeye from Marvel comics, whom I'm a big fan of). You can have a look at my first, rough concept document here. Because it is the first rough version of the concept document, things will most likely change as time goes on. I will talk more with my teachers later today (April 9th) about the project and help on deciding a project plan.