About StoneMonkeyStudios (twitter: @StoneMonkeyMen)
My Religious Beliefs Prevent Me From Drinking Alchahol
Awarded by mohammad
on December 23, 2012
Awarded by shaneshanekavanagh
on December 20, 2012
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).
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
- 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.
- 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.
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.
- 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.
- 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.
- 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.
- 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.
Did you find the goats?
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!!
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!
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.
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!
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*