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.
2014-05-24
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)