It is now a week into the creation of my very first game: Hue Hopper. And progress is actually going pretty well. I set a rough development timeline in my game design document post. So far, I feel like I’m right on target. Perhaps even a little ahead of schedule? All the pieces are in place minus a few of the major ones such as:
- Color changing platforms
- Level maker
- Options/pause menus
- Working timers
- Score calculations
In the post, we’ll take a look at what’s been done so far, what I’ll be working on next, and what I’ve learned so far. Let’s get started.
What’s Been Done
The main title screen was the first piece I worked on. It’s what leads to most of the other game states, so I thought it was the best place to start. It’s fairly simplistic, it gets the job done.
All pieces from this menu are working properly. Selecting quit exits the game entirely. The options menu currently changes to an options screen. But there’s nothing to actually change (yet) so right now its just the message to go back to the title screen. Eventually, I’ll add the ability to adjust the music and sound effects volume. Possibly the ability to adjust the player’s input buttons.
The credits screen outputs some text with my name and a “thank you for playing” message.
The high score board is working properly, though there is currently no scoring occur in the game. And with no scoring, there’s nothing to actually pass to the high score screen. Regardless, the pieces are in place. (I’m aware of the text overlapping.)
Play State
In Hue Hopper, the play state is where most of the time will be needed, so I figured it probably deserved its own section.
Player movement was my first priority. The player states are implemented except three: sliding, wall jumping, and sliding down the wall. All three of these were in place, but the code was not clean at all and I felt I was spending a little too much time on them. For now, I decided to comment that section out and move on. Both sliding pieces are optional anyways. Best not to focus too narrowly on the details early on.
A basic level maker is in place. I’ve created a 50×25 grid-based tile map which I populate with tile objects. For now, the whole level is just three things:
- The room itself
- A small platform to test player collisions and movement
- A single colored platform that currently disappears after a set interval
What’s Up Next
This next week, my main focus will be on the pieces need to complete a single level. Most of that will center around the platforms.
Currently, the platforms are on a static 5 second timer. It doesn’t matter if the player is standing on them or now. After 5 seconds, the platform disappears. The player colliding with the platform will be the first priority.
Once collisions are working, the next step will be connecting the time remaining to the color. I haven’t worked out all the details, but here’s what I’m thinking. The time remaining will be divided by a maximum time value. The quotient will be converted into a hue value (H of HSL). Then this result will be converted to RGB and an animation tween will adjust as necessary. Not sure if that’s the best way, but it’s what I have so far.
The level timer will probably be the next step. I don’t imagine it being too difficult. Though it will likely be placed inside a LEVEL_DATA type file along with the level maker data.
I’d like to get some sort of game object in there that ends the level. This would allow me to get a level change state in place, allow for score calculation, and pass scores to the game over/high score states.
Finally, I’d like to implement all the option/pause menu items I mentioned.
Most of this I feel can be implemented inside a week. That would roughly 2 full weeks to focus on the level maker. Which I feel I will probably need. That will be the most complex item I think.
What I’ve Learned
1.) Definitely the biggest takeaway from Hue Hopper so far is: set specific goals. Having that rough timeline of how long everything should take (and in what order) was extremely helpful. I knew what to focus on each day. Basic, but way more helpful than you would think. That said, more info would been help. Be as specific as possible, without taking development time away.
2.) Creating the various game states from the beginning made a ton of sense to me. After adding the game’s state machine, I had pretty much all the screens created with a way to get between them (and in the correct order). This was huge in making it seem like I had made more progress than I really had.
3.) Add more comments earlier. I spent part of one day just commenting out my entire player movement script. I was having an issue with the sliding and didn’t know what was causing it. And with no comments, I had kind of lost track of what each piece was doing. Just a comment explaining each section would have been a big help.
4.) Having a developer panel in-game to display information is helpful. I made it just to identify what state my player was currently in, but ended up using it for a few more things. I may develop my own library just to handle a little in-game developer panel.
5.) And finally, don’t focus on the details too early. My player movement was pretty good minus sliding down walls or sliding on the ground. I spent time working on them, but couldn’t immediately figure it out. Identifying that it was not critical and moving on was a really good decision. Worth taking the time to identify the most important pieces of each element earlier on.
Final Thoughts
Overall, I feel like Hue Hopper is making pretty good progress. Especially for my first non-tutorial game development project. I’m pretty proud of myself for actually starting this journey and making it this far.
I’d be curious to get feedback, especially from my fellow developers out there. There’s a ton out there that I don’t know. And I don’t even know that I don’t know it. If you see something in my process that could be improved, by all means, let me know. I’d certainly appreciate the feedback.
