Time for another update! Not much progress overall but the important thing here is: (a) I’m moving forward a little bit everyday, working at least half an hour on something game dev related and (b) I feel like I finally have a game with a small scope and that could result in something that is fun and actually slightly different from the other games out there.
Last month I talked about my puzzle game prototype (based on Pokemon Puzzle Challenge), by that time all I had was this simple puzzle with moveable pieces.
Since then I have written the code to check matches and generate new rows from the bottom.
But testing this puzzle without any kind of visual feedback was hard, often I was randomly moving pieces and some pieces just disappeared, and I was like: “Is it a bug or a match I didn’t see?” – I have already heard of game genres that requires to be polished soon on development, I though that maybe this is one of them.
So I went on to write the functionality of having the pieces glowing for 1 second before they disappear, and, although it worked on the end, I had to change the structure where each piece was represented which led me to rewritting all of my game’s code. Oh well, things like this just happen. See the video below for the current state of the puzzle
Changes on the structure: Before, the structure was just the piece represented, now, each position where there is a piece, there is actually a vector, this vector has (i) a piece to be displayed; (ii) a value indicating whether the piece is set to be destroyed and (iii) a timer indicating how many frames has passed since the piece was marked to be destroyed.
When a match occurs, the piece to be destroyed is marked, and they are destroyed after a second on the Step function (or Update function) – The glow is achieved by a simple “is odd” function on the timer, if the time is odd, it is rendered a white sprite overlaying the piece.
Next on my To Do List:
- Adaptaing the “fall” algorithm (the piece of code which runs after matches to check if any pieces above should fall) to make it seem like a smooth fall, not just changing piece positions.
- Reinserting the new row generator.
- Make the new rows appear slowly so the player can play around what pieces are coming.
- Write the “Overworld”/Roguelike Part.
Talking in Roguelike Part…
Let’s talk Design
One of my intentions on this blog was to also talk about programming and design, I recently realized that I’m just writing what I’m doing, time to change that. I’ve written a little bit on programming above (on how I structured the pieces and how the glow was made), and now I am going to talk about some of my design process this month.
I tried to do a definitive simple game design document and it had 5 pages, the 2 most important pages are below, I’ve written about Game Identity, Design Pillars, Genre/Story/Mechanics Summary, Art, Music, Flow
The most important is the Flow, actually, all 5 pages could be just the flow (Please forgive my handwritings)
But these writings doesn’t matter anymore because…
Yeah! I’m proud of myself for cutting stuff from my games!
Last update and on the first two images it is possible to see that “Turn Based Like” gameplay was a feature of the game, the scope seemed too big and I asked myself “Why Turn Based Like Combat mixed with the Puzzle is important?” and it isn’t. So I removed it from the game, making the puzzle and the roguelike part much more simple. After all, the aim is for it to just be a puzzle game with some kind of a roguelike progression.
That’s enough for this months update. For some non gamedev related news, I’m embarking to the US tomorrow! Yay. I will be a week in Orlando. I just hope that I can move on with my life after buying a Nintendo Switch and Breath of the Wild there.
See you on next month!