About StoneMonkeyStudios (twitter: @StoneMonkeyMen)


Ludum Dare 37
Ludum Dare 34
Ludum Dare 28
Ludum Dare 25

StoneMonkeyStudios's Trophies

My Religious Beliefs Prevent Me From Drinking Alchahol
Awarded by mohammad
on December 23, 2012
Awarded by shaneshanekavanagh
on December 20, 2012

StoneMonkeyStudios's Archive

One Womb Post-Partum

Posted by (twitter: @StoneMonkeyMen)
Sunday, January 1st, 2017 1:47 pm

Well, here we are, at the end of voting once more, and it has taken us three weeks to summon the motivation to create a Post-Partum for our entry.
One Womb is a fast paced race-the-flood wall climbing platformer where you are a lone sperm trying to outrace a horde of other spermies to fertilize the egg. We’re quite proud of this one overall, but we’ll go into detail on what worked, didn’t work, etc.

–>One Womb Entry Page<–

Our team once again consisted of:
Ryan Nohr
Kyle Olson
Jon Rasmussen
Tim Brandl


Programming/Design – Ryan

  • What worked:
    • The concept we settled on was a silly, fun idea. The first few jams Jon and I did were light hearted, silly things, and we had a lot of fun. The past few we’ve participated in though we’re a bit more serious, and much less focused. They each had their bright points, but for me personally, they were more stressful and less fun to work on. I think the return to silly was what we needed to really have another game click.
    • On that note, we all got on mostly the same page very quickly. Once the title ‘One Womb’ was suggested, there was no other course of action. The dominoes fell into place quite quickly, aside from a few miscommunications, and standard delays.
    • The game itself was fun. The majority of my time was spent making sure that the core game was fun to play, that aspect is easy to lose sight of, so in any decision I made, the fun answer was usually the best.
    • The actual level turned out to be decently balanced. I confess, I didn’t even beat the game until after the competition. During the jam, I only tested the parts of the level to make sure they were in theory beatable, but I hadn’t had the time to finish it. In the end, it was difficult, but I am happy with where it is at, because with some persistence, it is beatable. This gives it a bit of life that otherwise wouldn’t exist if the game was beatable in 5 minutes.
    • Gameplay is fairly addictive, and restarts are quick. When I actually did play the game to the end, i always felt that I could get it next time, and so I felt compelled to replay, which went pretty quickly by design. This felt like a good balance to me, so I’m pleased with where it landed.
  • What didn’t work:
    • Keyboard play. For the love of god, keyboard play doesn’t work. For what it’s worth though, we never intended it to work. The majority of my time was spent getting the game tuned to work with controller, and that was hard enough. Since this type of game is traditionally played with a gamepad, it seemed an obvious choice.
    • The biggest problem we had with this was that we didn’t properly convey this fact, so many folks expectations were not met. We added some post jam updates to try to alert the users to this design choice, but I feel like this may have impacted our “fun” score.
    • User expectation of difficulty/time investment. I think some people found the game just a bit too hard to complete. While I’m happy with where it landed, I think folks are maybe not willing to dedicate enough time to perfect the game, which is understandable because we’re all trying to rate lots of games! A checkpoint system might have been a decent option for letting people actually finish the game. We considered this in development, but ultimately it was lower priority than other aspects, like character movement.
  • Things I might change/Wish I had time for:
    • First thing I would probably change is smoothing out the look of the walls. They were created by clipping smaller pieces of wall into each other, and this is my personal choice for least polish. Fortunately, it’s only an aesthetic thing, and didn’t affect the gameplay at all.
    • A bit more fanfare on win. What is presented is the minimum bar for a Win Condition. I’d like to have added in some effects and animations, but time did not allow for this.
    • Distortion shaders. I would have loved to have wriggly, writhing walls with a nice distortion shaders. We’ve used them for other projects, but did not get one working in time for the jam. I think this would have looked really cool/funny/gross.
    • VR Mode. From the beginning I thought this would be entertaining to play in VR, but time again did not allow for this to happen. Without consideration of this, I handled camera control by directly moving the Camera transform, which means there would be a bit of rework (since you shouldn’t be trying to move the camera directly, as the headset controls this), and went with simplistic, overlay UI. It would not take long to implement VR mode, but we missed it within the scope of the jam.




Art (3D) – Jon:

Knew going into this jam that time would be a lot tighter. That being said, I could have planned a lot better to more effectively use my time to make the game look more cohesive or add more enemies.

  • What worked:
    • Liked the aesthetic we kind of stumbled into (Banjo Kazooie-ish) and the main character concept by our 2D artist. I’m sure there are other styles which would have worked out, but the fact that it made light of the subject matter (hopefully) helped its likability.
    • I really enjoyed our direction with the theme just because it was rather silly and somewhat simplistic. This also matched the time commitment of the team.
  • What didn’t work:
    • The way the wall meshes were textured and used to construct the level. These were kind of slap-dash and meant to be placeholder but ended up sticking due to lack of time for reworking. This limited some of our lighting options and will probably have to change for the potential VR version.
    • The tail flap. Tried a couple different methods– and thought I got it at the end– but it was not quite right.
    • Time management (on my part). Wasted too much time on the tail and noodling with the level setup (as far as lighting and effects). That could have went toward finishing modeling/ animating other crotch dwellers like crabs.
  • Things I would change:
    • Change the character designs to increase their whimsy in the game with its current zoom distance. The characters were created without testing them at the distance/ size they would be displayed in the level, so by the time they were completed it was a bit too far down the path to change. They are tiny enough that their faces aren’t really all that noticeable– details (or the whole face) could be accentuated or enlarged.
    • Expand upon the gameplay a bit if given time. We didn’t really have time to explore what progression would mean as a sperm– like… can there be multiple levels after you have already fertilized the egg? What does the next level look like?



Audio – Tim

  • What Worked:
    • Having a fun/funny idea made the whole experience a lot more fun, once I saw the idea pop up in our chat I was so on board and really excited to make it happen.
    • I think the gameplay music ended up working out pretty well for the platforming portion, once I asked for more clarification and examples on the direction for the game play.
    • A lot of people that I’ve showed the game to tell me the song sticks in their head, which I take as a positive.
    • The sounds were a lot of fun to make! I tried to add some humor through the squishiness of the sounds and hopefully that came across. The direction I was given was squishy and sloppy, and honestly were some of the most fun effects I’ve ever had to create and edit.
  • What Didn’t work:
    • What is currently the music for the title screen and before you begin the game was my first shot at writing the music and I wasn’t exactly sure what direction to go at first other than “love makin music… but frantic” went kinda barry white-ish but I didn’t really go frantic with it.
    • I should have asked for more clarification or examples earlier, but luckily the music was still fitting for the opening/title and I’m glad it was still able to be used.
    • I hit a pretty hard writer’s block with the music, sleep helped.
  • Things I might Change:
    • If I could I would add more variety to the sound effects for each action. There are some sounds I could have added like more noise to the jumping/ moving and some kind of ambience… of a womb? I had some difficulty recording the sounds in my makeshift bedroom home “studio.” The squishes were too quiet and that really brought up the noise floor and was limited in what I got that was actually usable. Might need to soundproof my room better or get a better place to record, but I think it worked well still considering.
    • If there was more time it would’ve been neat to make the music speed up depending on the closeness of the spermies behind the player, to give some kind of auditory indication on the wave approaching behind.


Stone Monkey Studios in for LD37

Posted by (twitter: @StoneMonkeyMen)
Friday, December 9th, 2016 6:53 pm

Hello again friends!

It looks like Stone Monkey Studios will be participating once more in this hellish, thoroughly satisfying venture.

This year, we will be:
Ryan Nohr – Code
Jon Rasmussen – Art/Code
Kyle Olson – Art/UI
Tim Brandl – Music/Sound Design

We’ll be using Unity, with a few utility libraries.

Looking forward to seeing your projects!

We’re in for our fourth.

Posted by (twitter: @StoneMonkeyMen)
Thursday, December 10th, 2015 3:23 pm

Stone Monkey Studios and friends are in for our fourth Ludum Jam.

Our team is
Jon Rasmussen – Art/Code
Ryan Nohr – Code
Nick Amlag – Art
Zeke Fenelon – Music
Akash Thakkar – Sound Design

We’ll be using Unity3d for our engine and a whole bunch of standard tools.


FL Studio

Visual Studio

We’ll use a handful of “boilerplate” unity packages.
Sound Manager (I really hate writing a new audio engine every time)
Notification Center
Other minor utilities.

We’ll see you at the starting line!

Stone Monkey Be Jammin’

Posted by (twitter: @StoneMonkeyMen)
Wednesday, December 11th, 2013 5:17 pm

Hello World!

After a year-long hiatus from LD, we’re back again to jam!
Most of us don’t actually have time to do this, but we’re doing it anyway!

The team will be:
Ryan – Code Monkey/Unity God
Jon   – Artist/Coder/Jack of all trades
Nick – Artist/Clever second title
Sean – Artist/UI+Particle Slave
Zeke – Composer/Plumber (+1 to you if you get this joke)

Magical Music Creation Tools (Clearly, I have no idea how music gets made, I just trust that it does)

Probably/Potential Unity Plugins:
2DToolkit? (Since I haven’t been bothered to learn Unity’s new 2D tools yet).
Internal Code Library (Mostly boring stuff like XML parsing and design patterns)

We may even attempt to get some streaming going on, but it depends who feels like it.
My stream is probably going to start really boring, but then get awesome (being that I’ll probably be doing most of the coding, but also likely much/most of the scene setup as well).

Cheers, and Jam On!
Stone Monkey Studios
@StoneMonkeyMen | StoneMonkeyStudios.com

The Fall of Mister Wily – Post Mortem

Posted by (twitter: @StoneMonkeyMen)
Sunday, December 30th, 2012 11:00 am

Heya folks!

Ryan from Stone Monkey Studios here! I tossed out an email a few days ago about a Post Mortem for Mr. Wily, and we all came up with a few things to comment on. I’ll post them here in no particular order.

The game can be found here.



Ryan – Programmer

What worked:

  • We managed to work out a pretty solid plan in only a few hours.
  • Working together for at least part of the time was very beneficial. It was good to bounce ideas off each other and have quick communication.
  • Using Dropbox was great for getting content into the game quickly, but was very annoying for other things I’ll address below.
  • In terms of code: It worked much better when I gave up trying to design things to be modular. In general, it’s good to have reusable code, but it generally requires more forethought. This is unfortunately more difficult (for me at least) in a rapid prototyping situation. Once I embraced the mindset of writing very specific code, my output sped up significantly.
What didn’t:
  • The original idea for the game was a pretty large scope. We managed to keep most of our key features in the game, but some of the ties that were meant to bind them together fell by the wayside. The stork/baron thing was only every tangentially tied to the rest of the game, but without even giving it a cursory explanation, it did not fit well at all. (Fortunately, the stork game itself is pretty fun in my opinion, so I don’t regret keeping it in.)
  • Because of the large scope, there was a lot of polish that could have made the game better. Many simple things would have gone a long way.
  • The plane could have rotated (Something Jon mentioned off the bat, but I just didn’t have time for)
  • Text sizes could have been normalized, and placement was occasionally halfhazard, so there was a bit of inconsistency.
  • I would have liked better control over starting a minigame. The explanation splash (“Get to the princess!”) should have been dismissible by space bar, and no other input should have been accepted while that was shown.
  • Dropbox did not work with unity because you cannot exclude the VS project and various assemblies from dropbox, so every time someone would cause a reload on their Unity project, it would rebuild assemblies for everyone and cause problems. This was extremely frustrating as the programmer, because it would break predictive text, autocomplete, and just generally mess with me. I lost a surprising amount of time closing mono, closing Unity, and reopening.
  • I think the “Coolness score” could have carried through the entire game with a bit of planning, and could have been an actual gauge of score instead of an arbitrary thing.
Other stuff:I would agree with some of the folks that call this more of an “interactive story”, but I strongly disagree with the idea that this fact makes it a less valid entry than a more traditional game.
We discussed the idea of having losing states, but ultimately opted for this format so we could tell the story. I think the game works best as a short experience. The point is to build up frustration and then release it. If you could lose games, then it is much less likely that we can hold people long enough to give the satisfying payoff.

Screen Shot 2012-12-29 at 12.42.08 PM
Jon – Artist
What worked:
  • Working with four people allowed us to accomplish much more than last time (and at a higher level in general); last LD it was just Ryan and Jon.
  • Creating several mini-games to simulate the daily grind (and being able to control pacing by switching between them); this was a gamble (and a bit of a drawback, stated below), but it came together nicely.
  • Sleep. It was good to get a good nights rest to stay productive during the following days.
What didn’t:
  • I really liked the art style, but it took significantly more time (from Jon’s POV) to model and unwrap (specifically trying to maintain the ratio 1 block in 3D : 1 pixel on the texture).
  • Some of the mini-games did not have enough user agency. It would be nice to turn the bar fights into something like Punchout. The computer screen could be turned into a game (or maybe omitted).
  • Finishing several different games kept us from polishing and expanding upon the individual games.
Other stuff:
    I regret that I (Jon) could not help polish the game on Monday as I had to work that day.
Nick – Art
What worked:
  • Team composition.  Our approach the theme was far more content-heavy than feature-heavy; fortunately, our team was comprised of 3 content creators and 1 programmer.
  • Quick and ready communication.  We actually jammed out at one of our places for a majority of each day, which was beneficial not only to meet up to quickly establish our direction for the design ideas, but also for all the little things.  This is my first Ludum Dare, my first jam, and the first time I’d ported and created assets for Unity in any capacity, so getting quick pointers and assistance from the team made sure I didn’t waste any time when they already had the answer to my questions.
  • Taking time for charm and personality.  It’s easy to plan to implement every important feature and design, then cascade downwards to less important things, but I believe it to be equally important to take the time to inject a little personality into the product every now and then; doing so ensures that you at least have a little fun as you develop, and prevents you from mentally burning out.
What didn’t work:
  • Despite concepting the characters first, they were among the last assets to be implemented into the game.  All the animations were done on the last day, and while we actually have some assets and characters that didn’t make it into the game (the bar scene and the office had several assets created for them), we didn’t have time to put them in the game.

Other stuff:

Did you find the goats? :)

Akash – Sound/Music
    Unfortunately, I had trouble getting in touch with Akkash for the Post Mortem due to the holiday season, but if we hear back, we’ll get his thoughts and comments either in an update or in a new post!Thanks for reading folks!!

–Stone Monkey Studios–

Stone Monkey Studios is In

Posted by (twitter: @StoneMonkeyMen)
Wednesday, December 12th, 2012 12:14 pm

Hey there folks!
The Stone Monkey Studios team is in for the jam on LD 25.

This time around the team will be:

Ryan — All things Code
Jon — Art
Nick — Art
Akash — Sound/Music

Dev Environment: Unity 3.5/MonoDevelop

Art: Maya, Blender, Photoshop

Music: Really, I have no idea. Akash will be using crazy magician magic as far as I know. Probably some instruments, and I assume some sort of computer program, but I (Ryan) don’t know much about that.

Libs: Using CCTextBox for text rendering and also bringing in a Code Library we keep for general stuff such as UI.

Other tools: Dropbox, Coffee, Frozen Pizza.

Happy LD Folks, see you on the inside!


It’s bedtime

Posted by (twitter: @StoneMonkeyMen)
Saturday, August 25th, 2012 2:21 am

Hey folks!
As many of you mentioned, I also had some trouble coming up with a good idea for the topic, but after some talks with Jon, I’ve settled on doing a fighting game/shooter where enemies are determined by an evolutionary algorithm. Hopefully the idea of evolution comes through.
And for a pretty picture, here’s the base model for an enemy, animated and ready to go, wearing the skin of several enemy types (right now Zombie and Robot).  He looks a bit Abby Road it seems.

I’m Streaming

Posted by (twitter: @StoneMonkeyMen)
Friday, August 24th, 2012 10:26 pm

Heya, I’m streaming.

I’m afraid most of tonight it will be boring boring code, but hopefully tomorrow should be a bit more interesting!


Juh Juh Juh Jam

Posted by (twitter: @StoneMonkeyMen)
Friday, August 24th, 2012 11:17 am

Heya, Ryan of Stone Monkey Studios here.
My fellow Stone Monkey, Jon, won’t be participating this time, but I will.
Since I’ll be going solo, I’ve been debating whether to do the competition or the Jam. I think I’ve settled on the Jam, simply because we have a few utility classes written that I’d like to use , but am not yet prepared to release to the public.

Tools: Unity3d pro, Audacity, Blender, Photoshop, SpriteSomething, Audacity, Wolfram Alpha Tones, Bfxr.
Libraries: A few utility classes we’ve written

I’m planning on recording as well, so I can make a nice timelapse. Hopefully that’s not much trouble!

*Fingers crossed for a fun theme*


[cache: storing page]