Here We Go Again: Sprint 2
Here We Go Again: Sprint 2
Joy Schulze: Programmer
This second sprint, my mission was to complete the main gameplay loop of Here We Go Again. This includes level creation tools, progression, and monitoring the game state. I was able to accomplish all of this as well as clean up some of the work I did in the first sprint.
As for the less interesting cleanup, I gave everything health bars as our designer requested, and I fixed some issues that the units were having. They would just kill 1 enemy and then stop fighting anything, or they would fight 1 unit and when they killed that unit they would ignore another unit who was already attacking them. Turns out I was just using the wrong collision event for the vision.
The next thing I did was make the starting phase where the player places down units and strategizes before the fight starts. At first I did this by just freezing time, but I have since changed it to just halt all of the units until the start button is pressed. I did this in case I need to do anything with time, but also it gives us the ability to give our units idle animations to give them lots of charm.
However, my producer and I realized that we misinterpreted our designer’s vision as he does not want the player to place down units like a tower defense game, but for each level to have units already placed down that the player has to figure out how to use. So I had to scrap placing units down and pivot to them being placed in each level. Thankfully, I had something similar planned for the enemies and I was able to implement them side by side.
My favorite thing that I implemented this sprint is something that I call, the encounters system. This is a scriptable object that will make it super easy for my designer to make levels. It’s basically just a set of arrays that correlate to the grid spaces on the map that you drag and drop player units and enemy units into and, voila, a level is made. That is all you have to do to create a level for our game.
It connects to a game state object that contains all of the encounters, the current encounter that the player is fighting, spawns the encounter, and keeps track of the enemies so it can count the encounter as beaten. This object will handle all of our progression for the entire game, and I’m very proud of its implementation.
I then ended the sprint off by creating the conditions for the player to win and lose the game.
I was almost done with touch controls which would have allowed me to implement other mechanics for our game, but I am still learning Unity’s new input system and how to handle different types of touchscreen input.
I am happy with my work, not just because it works, but also because it means that our designer can make just about everything he needs to make now. In the first sprint I made our modular units that he could edit and make all of the units for our game, and now he can make all of the levels. Next sprint, I will finish getting touch inputs to work, and hopefully knock out a bunch of player actions like shooting enemies, merging units, and casting spells. I am also excited for our first electronic prototype, even if we don’t have too much in our little autobattler, our foundation is very fun to watch.
Comments
Post a Comment