Developing SokoVirus

I started working on this game near the beginning of March. I set out to make a sokoban game of some kind after watching Lazy Devs Academy’s video on 5 good starter genres. I used the first few episodes of his roguelike tutorials to get my character moving and doing what I wanted.

The first big hurdle was in understanding movement animations. The roguelike tutorial was based on an 8x8 movement grid, so any movements were offset by 8. I would still say animation is a difficult subject for me, but I want to grow in it.

For the story, I had the general idea of a hacker trying to get into different servers. My first few character concepts are shown in the early screenshots (I enjoyed the little mouse cursor dude). The theme sort of came about as I was developing the game. Another thing that came about randomly through the development was the actual levels. Most of them came from me looking at random shapes and seeing if I could make a puzzle out of them. I also played some other Sokoban games for inspiration (I learned I do not have the best patience for them. This is why I added the save feature).

Early Screenshots

Near the end of march I made a few really big changes to the project. The first was starting to use VSCode as a helper code editor. I was still using the pico editor, but I was using the VSCode editor as a reference and a helpful searcher. Later on in development, I almost exclusively coded in VSCode (split view is amazing!). I also used the Pico sound/sprite editor along with a tiny amount of Aseprite for the logo text. Git also makes versioning really simple.

Using VSCode

Around the 31st of March I began to work on the particle system watching some Nerdy Teacher videos and looking at some code. This is where it became clear that I needed to change my organization. Before I would separate out the draw, update, and initialize functions into their own tab. I think this is standard and a good way to do things and I want to revisit this idea in the future, but I changed my organization to the following:

Each game state had an init, draw, and update function and these functions were right next to each other in the code. The idea was that it would help with debugging. Any "game state" consists of an init that sets the _drw, and _upd, an update that updates (yeah), and a draw function. This made writing the code easier for my brain at the time.

Another important takeaway for me: It is better to bust out an isolated feature than to try to find an “optimal solution” online. Trust your instincts, fail, and try something else. It is all learning. Also implement a debugger early.
It was most helpful for to start either writing stuff down or coding when I hit a problem. I spent a fair amount of time being stuck because I wasn’t trying things.

4/9 nearing the end of development. This is where my morale definitely dropped. I felt like it was done and I didn’t like it. It felt like a waste of time. But after watching Lazy Devs’ postmortem I was again encouraged to see it through.

No new projects. Finish the one you have.

4/10 cool, I’m done. But what if I added a way to play any level at will and keep track of the best score? What about some cart data while you are at it? Some of the animations could use some polish as well. What about an end screen? Ok, so the game is done, but not really done. I am now on to cleaning and implementing some final features.

Random thing that came up often: init/upd workflow with animations. If I wanted to slide the menu or something, I would add an offset into the draw menu's text or whatever I wanted to animate, and then take over the update function to change the movement variables until the animation is complete. You can see that with my init_slidemenu() function that is called from the upd_menu().

The Notebook

I found that dotless notebooks work the best for me. I tried bullet journals in the past and I just got caught up in putting everything between the dots. Also, when I return to old pages my brain would get distracted by the dots (I was always jealous of engineering students using gridded paper. My mind just can’t differentiate that well).

Overall Takeaways:

Oh my gosh, scope is sooo important.

I have tried gamedev before on other platforms. On those platforms I didn't set out to make "my dream game", but the ideas had mechanics that were uncommon and a not necessarily fully realized gameloop. More like “it’d be cool to make a story game about a cave”. And then getting lost without a vision. I can’t stress enough how amazingly helpful it was knowing

1) What I was making in terms of game design.
2) how many levels it was going to be.

Thank you Lazy Devs.

That isn't to say you always need these two things clearly planned out from the beginning for every game, but as a new developer I think it is an essential thing to work towards.

Tracking small changes is great

I liked making tons of little checkboxes for things like “change the color of a lock” to some bigger things like fix the player animation bug or design level 12. Being able to physically check things off was really helpful. I also had a page for big feature ideas. Some features didn’t make it into the game, but it was fun to cross or check things off when they were completed (or scrapped from the game).

Juice and UI will take more time than you expect.

I can safely say “I finished the game” halfway through development. The other two-three weeks were spent adding extra menus, making smoothish animations, and lining up the UI.

There is so much joy in making small things with limited resources.

I was so hesitant to develop on Pico 8 at first because of its size limitations. I was like, “I want to make a game that can scale up to a giant Zeldalike game if I want” (spoken in an evil genius voice). The truth is you don't need a ton of space to make fun games. A benefit of the limitations is that without generating my levels in code, I had about 12 levels to make. This saved me from getting bogged down making levels all the time and freed me up to try other things.

Pico 8 Games are great!

In making my game, I ended up playing a ton of Pico 8 games. Some games were absolutely massive games considering the constraints and some were these short little juicy arcade games. I enjoyed them all.

Anyway, thanks for listening to my ramble. Definitely let me know if you have any comments or questions. I am happy to answer.

Happy gaming,

Olivander

Great write-up! I'm enjoying the game. Congrats on the release!

This project is awesome! Very high level of polish. Will likely be rummaging through for some tips later on.

Agree with your idea of scope being important. I just finished my first project in Pico-8 having bounced off unity last year (maybe because I was trying to learn Unity+coding+3d at the same time… whoops). But yeah, I also found that having a cap on what’s feasible helped me finish it!

Are you doing another pico project?

Thank you both! I am excited to be finished. I plan to work on another project! I am going to spend some time scoping out what I want to do next though.

I completely understand trying to do everything all at once haha. I have several unfinished gamemaker projects that will probably never see any form of completion. Pico 8 is good for reigning in some of the scope creep haha.