This past weekend I made a game, “Naos”, for Ludum Dare 23, around the theme “Tiny World”. If you haven’t played Naos yet, you should do so now, the blog post will make more sense.
http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=7853
The sound.
Aesthetics were very important for me in this jam game. So I tried to pick carefully what kind of music I wanted to write. The game wasn’t supposed to represent a wholly realistic thing, so the music sort of reflects that in a haunting/minimal way (the organ-like house loop, the chime-like thing in the forest). The more action-like piece at the cliff helps to show that there is some action going on there (i ended up redoing this one the most…). As for the intro/ending thing…I couldn’t really think of a fitting melody, so I added some fancy-ass white noise that I thought fit.
I like the chimes piece the most, and would like to expand upon that. I feel like part of it was definitely influenced by listening to the Fez OST ( http://disasterpeace.com/ )way too much over the weekend – especially with the bitcrushing it uses, which I felt I may have overused in a place or two. Two pieces in particular I found salient were Spirit and Nature.
https://player.soundcloud.com/player.swf?url=http%3A%2F%2Fapi.soundcloud.com%2Ftracks%2F44156155 Seagaia – Songs from Naos (Ludum Dare 23) by seagaia
Graphics style…WHY? MY EYES!
Admittedly the game’s blur was a bit much. I did think it suited the quiet/haunting/ethereal-esque nature of the game, though. I wanted to try the scribbly style. Spending more time would have of course improved…well, everything. In a normal setting they wouldn’t be that rushed, I’d use a tablet, etc. Right now, it looks just good enough to not seem completely sloppy. (But is, still, of course, sloppy :P)
I was playing a lot with BitmapData objects in AS3 (surprisingly for the first time…why? I don’t know…but now I’ve got a level of comfort). They more or less represent what will be drawn to screen. And you can do interesting things like pull out certain color channels, transform them, and superimpose them on the original graphic. Or, you can blur things at different levels. The way I did blurring wasn’t ideal, I surely could come up with a more plug-and-play way of doing it, rather than the somewhat terrible way I have now (at least it’s organized terribly), which was to copy the sprite’s data, and keep some external data that determines how much to blur it – essentially, I have a copy of the data – I copy it to the displayed sprite, blur it, draw that to the screen, etc. The same idea goes for the color offsets. I played around until it looked okay.
I also played with a new logo for Seagaia today. It shows up on the intro screen. I like it. It’s a bit of a rip-off from. It was fun to make, at least the top part. There’s this nice thing in GIMP where you can copy and paste every other row, and then you make it a bit transparent, modify it a bit and superimpose it to get this neat shadow-y effect.
oh so how was the coding
Straightforward for the most part. Every room was a different state, with its own events and so forth.
Became an ugly mess near the end with the event coding since I haven’t figured out a nice way to do events with flixel yet…want to definitely figure that out. I’ve been asking around a bit, but not much in the way of detailed cutscenes. x_x
Since I already talked about the graphics coding, the only really interesting aspect was the events. How do they work? Well, for one, it helps to draw a tree of your dependencies with state variables. For example, “E_CLIFF_2” represents the 2nd cliff cutscene, “DRAWING_1_DONE” represents finishing the second drawing. And so every iteration of the game loop, depending on what screen we’re in, we check to see if we need to start an event. Essentially, events just freeze character controls, and wait for some condition (my player’s x being at some point, pressing x to advance text) to occur. Each event has an “event_pos” variable that is incremented when that condition is true, bringing the event to the next part (text, movement, whatever).
While this method works for a game jam, it doesn’t really scale well (see the other game I’m making) when it comes to moving many sprites that you don’t want to have to hard code into the game…and it’s a bit hard on the coder with the repetitive switch statements (see. https://github.com/SeanHogan/seagaiald23/blob/master/src/CliffState.as JEEZUS.)
An interesting bug resulting from this was that I didn’t nest one of the “if you press x increment the event counter” things deep enough, so if a player pressed X before they should have on the forest screen, you would be frozen when you actually pressed X over the right thing. Thanks to my friend Runnan for showing me that issue…gah!
One way this could have been done better is to have only checked for events once upon entering a screen, or have had some single “an event happened” variable to be checked, rather than all of these conditions on every iteration of the game loop. While this is okay because performance didn’t really become an issue here, it would be something to think about in some sort of later implementation.
so what the hell was this about?
it’s a secret! well, a few people have messaged me on NG about it, surprisingly. My interpretation of it is more or less solidified, but it’s interesting to see other people’s takes on it as well. In lieu of not looking all pretentious, i won’t write about it here. but if you’d like to know, shoot me a message.
that’s all for now.
if you found this interesting, you should follow me on twitter . http://www.twitter.com/seagaia2
ambient-melodic 