Game Link

As of today, I finished working on a game that I’ve been working on for a week in HaxeFlixel. Today I’d like to talk about the struggle and experience I had working on the game as someone just getting started in Game Development. With that said, let’s start with the concept for the game.

Game Concept

The concept for this game was a tower defense. The tower defense was based on each tower having a specific range and status effects for each tower. But, given the timeframe, we had to cut out the elements and focus on the range and damage for each tower. It was important to know when to scale back considering we were working on this while maintaining my day job. We put this into a game design document and started working on the game immediately on Saturday.

Development Experience

The experience of creating the game in HaxeFlixel was pretty straight forward as HaxeFlixel came with many of the tools I needed to do what I needed out of the box. For example, I had access to a good tilemap implementation, a good renderer, and a solid debugger for my needs. But, everything wasn’t easy.

One thing that was difficult was getting the tilemap working in the game. In Flixel, the parameters for creating the tilemap are hard to understand. After getting help from the community and reading some blog posts I was able to get everything working in the game using the previous work I did in another project as a basis. Once that was done, the majority of the was creating the interactions for the player, which included the UI, turrets, and enemies.

Flixel & UI

So, UI in Flixel is…not terrible, but not easy for anyone who doesn’t want to mull around adjusting numbers in code. But, it’s not Unity or Godot so this is to be expected. Now there is a UI library for Flixel, but this seemed overkill for this project and would just add one more thing to learn on top of the work for the project. But, creating the UI elements with what’s already provided out of the box with Flixel was not that bad. It was tedious creating the necessary elements through code, so I wouldn’t recommend for anyone making a UI-heavy game to do it through Flixel unless you enjoy creating all of your UI in code (masochist). I would recommend using Unity or Godot for a UI-heavy game.

The total amount of work was a couple of hours. It a was fun experience and I’d definitely use Flixel again to make a quick game. Now, once the UI was done, which was somewhat tedious, we started working on the turrets and enemies.

Turrets & Enemies

Creating the turrets and enemies was the easiest part of the game after reducing the scope to just focusing on cost, range, attack, and speed as the most important stats in the game. By focusing on these, we decided to make certain turrets that were stronger cost more or fast attacking turrets do less damage to vary the gameplay on our single map. Additionally, we made it so that you can’t just create the perfect setup and take no damage.

You may ask how we handled doing the stats in the game and that was using a custom solution of mine via a Haxe Macro. All stats in the game were handled by a flat-file database known as Depot that acts as any old JSON file. The great thing about our macro though is that it converts that JSON file into Haxe code saving us time when it comes to putting the stats into the game. Now, once all that was taken care of we focused on implementing the behaviors.

Implementing the behaviors in-game was a simple process. We simply added a simple state machine in the code that was provided in the HaxeFlixel tutorial series and applied it to our game. You can see the code below.

package game;
class State {
public var currentState:Float -> Void;
public function new(initialState:Float -> Void) {
currentState = initialState;
}
public function update(elapsed:Float) {
currentState(elapsed);
}
}
view raw State.hx hosted with ❤ by GitHub

That’s all the code for our state machine and this is used for both enemies and turrets. Once we were all done, we polished the game.

Polish

Polishing the game was surprisingly one of the fastest parts this time around. When we talk about polish, we mean improving the game feel. Game feel is incredibly important, and a lot of it has to do with the feedback the player gets from the game. This includes things like screen shake, music, sound effects, animation, and more. To provide that game feel, we added a lot of small things such as animations for the turrets and the heart to make the game feel more alive. We also included music for the two phases in-game and the title screen along with sound effects for almost every click the user makes. All of this added punch to our one level which I found really fun to play! But, this game isn’t perfect and there were a lot of lessons learned here.

Lessons Learned

This was my 8th small game and I’m pretty happy with how far I got in a week considering I’m still starting out in Game Development. I learned a lot here on the basics of creating a tower defense game and improving my game design skills from having people play the game. Right now there is only one level but I may add more in the future to make it more interesting and fun! Anyway, that’s cool and all, but let’s get to the lessons learned.

One of the most important lessons learned is to always write some sort of Game Design Document. On another project I was working on, we didn’t have a game design document at the start and a lot of the core ideas and concepts were lost to time including things like the color palette and the type of game we were aiming to have at the end. This made development a lot harder because we had nothing to refer back to. Now, that’s one lesson. The other lesson learned was about playtesting.

Always playtest your game. Right now in the current build things that need to be removed are the continue button and the controls need a better explanation. Our game is mouse-oriented, so we should have everything work with mouse controls. When I had someone besides myself finally play it they were kind of confused that the game didn’t work exactly how they thought it would. That’s a big problem. They expected the game to primarily just work with the mouse, but we betrayed their expectations. Next time we’ll lean into a control scheme that’s more familiar based on their initial expectations of the gameplay.

The last thing I learned was to just take pride in the game and that’s it’s “finished”. Now, a game will never be 100% done, but you can walk away and be happy with it while meeting your deadline. Be glad you finished something, even if it sounds like a cliche.

Lastly, do a little work daily; many times in previous projects I would just stop working on things once I took too many breaks in a row. Just working on the game for 10 minutes a day can get you into the groove to make progress on the game. After all, it won’t get done for you!

Conclusion

With that said, I hope this post was informative and fun! Happy game-making!! Hope to see your completed games one day as well! If you’d like to play the game, you can find it below along with the Github repository.

Game Link

Repository

%d bloggers like this: