Moss is an endless-runner inspired game meant to show the OneGameAMonth.com's April theme of "Age."  I thought about the old saying, "A rolling stone gathers no moss" when I was brainstorming ideas for the jam.  


It felt like a really cool idea to have a sort of "Brave Lil' Toaster" version of a stone exploring the wilderness.  As the player progressed, the seasons would change and so would the types of obstacles they face.


I learned a great deal working on this project. I also had to cut quite a few of the ideas.  This game was an excellent learning opportunity for me and I feel like my next jam will be much better!


Now let's get to the good, the bad, and the future...

What Went Right

Level-building Tools

When I thought about the way the player would move, something like Happy Wheels came to mind, rather than Temple Run or BitTrip Runner.  So I started with finding tutorials about the generic 'car physics' games and found one with HeartBeast on youtube, that mostly solved the problem.  It worked, but there was still a great deal I didn't understand about it all.


That is when I discovered the outside source DLL(Download library file) for Game Maker: Studio by KeeVee Games.  It was a handy tool for making paths created in Game Maker into a physical landscape that aknowledges and adheres to the physics-world restraints within Game Maker.  The tool itself was very easy to use, and provided enough commentary that I could sort of work it into whatever project I was making, without fully understanding the in's and out's of it all.


Using this tool, I was able to quickly make a landscape for the rock to roll around on. And I'm sure that I would not have been able to turn in this game for the jam without this DLL tool.

Scale down, not up

I am well-aware of the problems with scope that arise while making games. If you think about it, technically a game could be in production forever. It can always be tweaked, enhanced, upgraded, etc. so it's up to the developers to decide what get's cut and what stays- what is most important to the core aspect of the game, and what isn't.  The creator of OneGameAMonth.com, MrFunkyPants, gives really good advice when working on games and one of them being to focus on your MVP(Minimum Viable Product).  In other words, what is neccesary to have in the game and it still be playable?  


Even simple games can get complex fast, and this was no different.  I had rather simple mechanics in my head for the game:

-The rock rolls 'forward'

-The rock can jump

-There are obstacles


So, from there, I decided what these 'obstacles' might be. Things that are simple to draw in pixelart, simple to code, and naturally there; the game is very minimalist in design but also 'non-gamey' with the exclusion of a HD(Heads-Up Display) and the like.  So, I made a spreadsheet with Google Drive that detailed the different environments(Seasons of the year) and obstacles present during them.  I had things like rain, leaves, bugs, wet mud, dry mud, pollen, snow, ice, and branches.  Each of these would affect the rock in various ways, either by pushing it back, slowing it down, speeding it up, increasing moss growth(lowering health), removing moss buildup(increasing health), etc.  


Honestly, I think all those obstacles would have made the game much more fun, but they were not necessary.  Things I felt were absolutely necessary were the wet mud, ice, and branches.  This gives a sort of high-end, low-end, and median to the mechanics.  Wet mud slows the rock down, while ice increases its speed.  Branches simply psh against the roll, provided the rock doesn't jump over them.  So, with only these obstacles present, the game is sill playable.

This sort of works hand-in-hand with scaling down.  The simplistic concept and design is very smart for game jams.  In the past, I tried too much for a jam and wound-up with nothing at the end.  So, whenever I'm working on these types of things, I always try to think about the amount of everything required.  


First off, the player character is a rock, it has literally no 'animation.' Not like a moving, breathing protagonist.  Everything else can be represented as static characters/images as well: grass, backgrounds, obstacles, hills, and the family of rocks.  With all this setting in-mind, I could not only stay focused and clear on what to do next, but I actually had a chance of completing the game jam in time.


All of this cut my workload down tremendously, and it even allowed me to do some minor polishing for the game. Things like, editing several 'rolling' audio files to try and match when a player is moving quickly or slowly or a a normal pace.  Or creating a screen-shake effect when the player hits a branch and breaks it. And drawing extra portions of sprites that working in the foreground or background or both, to give the world a bit of depth.

What Went Wrong

Learned, but not learning

When I first started working on Moss I thought the only real new concepts to learn would be the physics landscape and interaction, but that was a bad thinking approach.  Even though many of the concepts I'm well-aware of like machine states, flags, controlling various sprite properties, etc., every game is unique and offers unusual challenges when one is creating it.  


I felt like I was quite prepared, having worked through a Game Maker textbook, and being familiar with its interface, programming language, and game design methodology.  As others may know, something you can think of to be very simple in your head can become a major headache when trying to explain it to a computer.  


In larger projects, I would be updating a GDD(Game Design Document) with the technical portion of it being as clear and thorough as possible.  In smaller projects, and because I'm not the best coder in the world, I try to avoid extensive documentation so things can be done. Of course, the truth of the matter is, better planning and documentation will save you more time in the long run.


So, at first I would comment parts of the code, and try to even comment the pre-built events defined by Game Maker, but through many confusing iterations of various types of code to see what works, most of it is not commented. Some of it is probably redundant, and it's definitely not efficient.  


If I come back to this code in a few months, I may not understand it, but in all honesty, nothing present is too complicated so I doubt that.  Still, it would have been nice to keep things more organized as I enjoy organization.

Falling off the horse

The month of April was pretty hectic for me, and because of the that I feel like I didn't devote enough time to working on Moss for this game jam. Each little thing in the game is small, accumulatively the project is quite large, but that's the beauty of working something like this.  


While I had the entire month to work on this game, I probably only spent 10 days(I have no idea how many hours) on it.  Part of this was due to being busy with other things, but a large part of it I feel is due to thinking I need a good 4-5 hour chunk of time to just sit down and code, draw or whatever.


The reality, as I sort of pointed out above, is that each small things can be done in a more concise amount of time; I just get lots of things down over a larger session(in most cases) than shorter ones.  So, I think it is really important when working on something like this to do 'something' progress in some way every single day.


I lost a great deal of time to polish this game because I was thinking I didn't have any time to work on it amongst other things. Some days I'd be so busy that I wouldn't even think about the game jam, and often what resulted is the following days I wouldn't work even if I had huge hour blocks available to do so.

Looking Ahead

This was a great learning experience for me, and I'm so glad that I finally produced a game for a jam.  In the future I plan to do a lot more pencil work so I don't have to do as much coding work.  While many of the coding problems I had were unavoidable, some were simply problems with logic.


I plan to try and document/organize all of my projects from now on, no matter how small they may be.  Even small, but well-made games can become quite popular; things like Flappy Bird comes to mind.  


I'm going to maintain a minimalist/MVP approach to my jams which somewhat limits the types of games I can make, but also not really. Lastly, I want to keep the mindset that I can always work on the game, no matter how little.   In short, any progress is still progress.  


What Went Wrong

This site was designed with the
website builder. Create your website today.
Start Now