Posts Tagged ‘processing.js’

Grease Colosseum – Postmortem

Tuesday, April 28th, 2015 11:17 am

Hey there, BoxedMeatRevolution here.

First post since joining in LD 31.

Who are we?

Just a bunch of people who like to program but struggle with pretty much everything else.

Our game?

An arena game where you kill enemies by using grease to slide enemies into obstacles. Play and rate our game here!

Grease Colosseum. Beware of fire!


This time ’round we used: Processing (js), MS Paint/, LMMS, SFXR.

Stuff we did well?

  • We pulled through in finishing (we had a bit of a crisis halfway through in our creative direction)
  • Execution of our mechanic was passable; the grease was fun to use, albeit with a bit of a learning curve
  • Fairly complete game in most aspects
  • Deployed the game via the web

Stuff we could have done better?

  • Smashing into enemies is too difficult to pull off
  • There are some graphical incongruities
  • Our choice of using processing.js made debugging painful and performance terrible on low-end machines
  • We had some light-bulb moments after submission was over for cool gameplay enhancements, too bad we didn’t have time to implement them :(


Postmortem: Nothing Left

Posted by (twitter: @isaackarth)
Monday, May 13th, 2013 3:57 pm

So, minimalism turned out to be a great theme for me. I’d already been thinking about the idea of just doing a simple, fun game to relax after all of the hard work I’d been doing on my other game, so everything worked out. But not before a sidetrip through the insanity of development that was just a little bit more insane than usual.

I decided to take a well-known genre and pare it down to the core experience. Hence, a bullet-hell shooter with no shooting. The player doesn’t even have to click on anything–the click at the start is just to make sure your web browser is focused. While the art style references De Stijl, I felt that for a game the essence was in the mechanics, not the visuals, so I avoided the visual minimalism of horizontal and vertical lines in favor of an interactive minimalism of a handful of actors and the tightly defined but emergent relationship between them.

Despite everything in the game being a square, you can pretty much instantly tell how they relate to each other just but how they move and interact. I like how that turned out.


You can play the game here:

What Went Wrong


Technically this didn’t go wrong so much as I knew going in that this was going to be an issue. I had a major paper due the week of Ludum Dare, so there was no way I would be able to devote the full time to the game, or even very much of it. I actually wasn’t sure if I was going to participate at all until a late evening conversation on Saturday made me realize that I had to get this idea out of my head. I always make a point of sleeping properly and not disrupting my usual routines, so even though I had deadlines about to steamroll me I ended up putting in about three hours on the game Saturday night and picking development back up at about ten or so on Sunday. In total, I probably spent about twelve to fifteen hours on the game.


I knew I wanted to get audio into the game, but a bug earlier in the day had put me behind, so I ended up with three hours to go, no audio–and no idea how to add it, because Processing.js doesn’t natively do audio. I had to learn HTML5 audio and make the sounds in three hours or less. Preferably less, because I like to leave some extra time at the end of Ludum Dare for breathing room. It worked in the end, but I’d have liked to have a bit more attention to the audio–but not to add much, because the minimalistic effects that are currently a part of the game do fit the theme. Just be glad my screeching temp sounds got replaced.


The procedural generator I wrote is fairly clever, given the time constraints. It divides the different possible features a wave can have into buckets and then uses Perlin noise to select a subset of those features to use. But it needs a bit more tuning than it has. I was the only one testing it, so I knew the ins and outs of the generator, but other people take a bit of time to figure it out and mostly die when the difficulty curve ramps up really sharply at the fifth level.

If I had been able to watch other people play the game I probably would have been able to avoid the other big problem, which is that there’s no “Game Over” screen. I didn’t need it while I was testing, and I didn’t care what my score was, so I didn’t notice that it was missing. But having one turns out to be really important for the game. Adding it in was a simple 26-line change, and the post-comp version has it, but I feel that if I had other people test it during primary development the game would have ended up even better than it is now.


What Went Right


Processing was a great platform to work with. I had to implement my own collisions, but that wasn’t a problem since I already knew how. I was able to use a lot of programming tricks that are technically feasible anywhere, like adding easing to most of the movement, but Processing’s immediate feedback let me fine-tune to get the exact feel that I wanted. And feel is a huge part of a game like this. Processing.js was easy to get working once I figured out which PVector functions weren’t implemented yet–in fact, it was so easy that I switched to make the web version of the game the primary one for the competition release.


I gave myself permission to not do everything. That is, the game wasn’t going to be the best graphics, the best sound, the most innovative concept–I was going to focus on making a game, not starting a revolution. Minimalism turned out to help with that, since it let me make a game that is deliberately about the most basic expression of a core idea.

No Feature Creep

Speaking of which, minimalism gave me an excuse for avoiding feature creep. Every time I had an awesome idea for something that would be an awesome addition to the game, I could just say, “Nope. Minimalism,” and go on my way.

Source Code Control

I took a few minutes on Sunday to set up a git repository for the game. I never ended up needing it, but it let me experiment, knowing that there was always going to be a mostly-working version of the game that I could go back to. I can, right now, jump back to the compo-version or forward to the post-comp changes with no trouble at all. If you aren’t using source code control, take a few minutes to learn how. You won’t regret it.


Keeping yourself healthy is important, even during a crazy crunch situation like this. I made a point to sleep and eat–and that really helped when I needed the energy and concentration to learn a completely new thing three hours before the deadline.

Finally, the community is a big part of why I participate. I make a point of rating a bunch of games–nowhere near all of them, but as many as I can find the time to do. I’ve already incorporated some of the suggestions I’ve received into the post-comp version I’m working on. I try to leave feedback that will help make the games better and I encourage you to do the same.


Will try to make a game…

Posted by (twitter: @Stoney_FD)
Friday, August 20th, 2010 4:28 pm

So, I don’t really have the time to write a lengthy introduction post, because I’m at the gamescom in Cologne right now, well actually I’m already there since Wednesday.
Here are the cornerstones:

My base code: Download here
Language: Javascript with Processing.js
Graphics: Cinema 4D and Blender for 3D stuff, GIMP and MS Paint for 2D stuff
Sound: Garage Band and sfxr

My workspace is whereever my notebook is at the moment, so no deskphoto, but I can take some nice pictures of the gamescom instead. :)

Well, I guess that’s it for now…

[cache: storing page]