Month: June 2020

Now Available

https://github.com/Romans-I-XVI/MonoGame-Snake

So I was prompted about a month ago by a person who played Snake on the Roku if it would ever be available on other platforms such as PC. I had considered doing it before, but just never really got around to doing it, as it’s sort of a fun side project more than anything else. However, having even just one person request it was enough to prompt me to actually do it. I worked on it in the off time along with my continued work on Retaliate and have not gotten the original Roku game fully re-implemented. It was an interesting task.

First off I always find porting to be fun and even relaxing as there is not creative work involved. The game already exists, all I need to do is recreate it. That said there did end up being some challenges, the game was originally written 5 years ago and well, let’s just say I was less organized back then. The source code was difficult to understand and had a lot of code duplication as well as tons of raw data that could/should have been stored in variables and reused. Though I attempted to reduce this in the port, this factor is still somewhat obvious; for example the data the defines the positions of various text building elements are still large arrays of positions. I had originally exported these positions using a GIMP script, a script which I’m not sure if I have anymore.

The second challenge was a bit more unexpected. I knew I would be dealing with old unorganized code, but I hadn’t considered the difference in implementation. In the original Snake game the movement is locked to frame rate, which has a hard cap of 60fps on the Roku. I think we all know this story, it is easier to develop this way but leads to undesirable results. If the game runs slow, the snake moves slow. It isn’t that big of a deal on the Roku where frame rates are fairly constant, but it had to change for PC. In this implementation there is no frame rate limit, just think of how fast that snake could move on a gaming PC if it updated its position with each frame :P. So of course the simple solution is to use delta time to adjust movement based on time passed between frames, fairly straightforward, except that it breaks how I keep track of positions for the tail in an array of x/y coordinates as that needs to stay constant regardless of frame spike/dips. Oh, and then by the way now to make the game look smoother I want to have float positions instead of only moving in integers. Well, it’s difficult to explain in writing but if you look at the code you might see the convoluted solution that involves tracking InternalPosition, CurrentPosition, and Position simultaneously. Basically InternalPosition is the actual float position being updated based on delta time, CurrentPosition is the whole integers used for tracking the tail array, and Position is what is drawn to the screen.

Lastly, I realized how wacky my original UI implementation was. In all honesty it’s still sort of confusing how I re-implemented it here. It’s almost amusing how some of the most complicated code for the game is actually just controlling the UI. I figured this is also some of the least interesting code to tinker with and modify though, so I didn’t do much in terms of simplifying it.

In summary, it ended up being a bit more complicated than I expected to port to PC, but I had fun tackling the challenges.

For the access to the source code and technical information of how to build the game yourself visit the GitHub link at the top of this post. I will also be releasing the game on various platforms, so if you just want to play the game you can find those links on the game page.