A week has passed since LD48 and it’s a good time to take a deep breath and reflect. Rub our sore muscles. Think about what’s next. Weep uncontrollably. Whatever you need. In my case, Mass Splitter went out the door without a hitch! Well, rather, it was well under the maximum number of allowed hitches. It was within hitch tolerance. In truth, there were three hitches: I didn’t get in a main menu, I didn’t get in a tutorial or at least an instruction page, and there was only one level. But all these hitches pretty much have the same cause, that of running out of time, so how comes I haz runs out?

What Went Wrong

Architect hat mostly unworn

I spent a bunch of time trying to get some view components working with HaxePunk. HaxePunk handles origin a little differently than I would think it should work, so I spent a few hours on my View class, getting the Scale, Origin, and Position components to all work together. Great, they now work together.

I did this because my game has orbs in it, and the active orb has a tube spinning around the outside edge of it. You hold the spacebar to shrink the active orb and start growing a new orb on the other side of the tube. After I got the tube spinning at the right radius around the correct center point I then went to add the new orb. This new orb also needs to be placed at spinning radius from the center, so how do I get the true position of the edge of the tube?

Well I can’t. The tube’s actual position is derived inside the view class, so it doesn’t exist at the component level. So now I’d have to either hack into the View objects to get this information (which horrifies my MVC sensibilities), or just calculate the orbital position myself, which I did. Well gosh, that was easy. And now that I’ve done that I can position and rotate the tube using the same logic, so the tube stops scaling along with the size of the active orb, which is a better look I like anyway.

In essence, I looked at just one next thing to do, rather than the broader landscape. Without putting on the architect hat, I spent a few hours going down a rabbit hole I didn’t need or want. On the other hand, I’ve got a cooler View class now.

Failed to take the time to split up complicated classes

I didn’t universally fail this, but I could probably attribute a few hours of wasted energy because of failing to do this early or at all. In particular my firing system is doing several things rather than breaking it up into different systems. See Ash Entity System / What Went Right.

Not putting more of my personality into my game

Friends often tell me I’m funny. Even fine, up-standing strangers — if not calling me that — have in the least called me irreverent. I try not to listen to other categories of people whose job is to be offended by everything. Anyhow – you wouldn’t know these things about me from playing Mass Splitter. Sure, I don’t have to make humor a central aspect of all my games, but a) it’s clearly desirable in a competition where there’s a category for it, b) there are many kinds of humor besides pratfalls and puns that can serve a dramatic cause. Heard of irony? Sarcasm? Deprecation? Pathos? Impudent contempt? Not that Mass Splitter is a deep example of erudition (it’s not), but it’s better for one’s self esteem to believe your personality is a strength. And if it’s not … well, you should work on your personality. Are you trying to tell me I should work on my personality? Stop staring at me like that.

What Went Right

Ash Entity Framework

Richard Lord’s Ash Entity Framework is really good. It’s an entity component system. I used the Haxe port maintained by Dan Korostelev. It was really fun to learn how to use an entity system and put it into practice. For those who don’t know, apparently those folks at AAA game houses have been using these things for years. The idea is to eschew traditional static object hierarchies for a data-driven composition approach. Richard has some great articles about it on his website.

Everyone seems to approach an entity system differently; in Ash the entity is a fairly generic object. You create a new Entity instance, optionally give it a name, add components to it, and add it to the engine. Usually it’s the job of a factory to create the entities with the components you need, but that’s up to you. Components are simply data-holders that you create, with little if no logic in them. Ash components do not need to derive from any base class, any object could be a component. All the behavior for your game goes into the systems you write, derived from the System class and added to the engine instance driving your game. When you call engine.update(time), all your systems execute in the appropriate sequence. Although Ash provides a signaling capability, Richard recommends you use boolean flags or components as markers to indicate when events happen, so that a component event (such as “this changed”) is only responded to by a system when it executes. Using engine.getNodeList(MyNode) a system fetches a list of entities from the engine that are relevant to it. Nodes are classes that contain one or more components; only those entities holding the components you specify will be returned.

I enjoyed using Ash quite a bit and encourage you to look at my source on Github if you’re interested in seeing one possible way of using the library.

Think smaller

Last compo I thought I picked a small idea but apparently it wasn’t small enough because I couldn’t get it done in time. This one was doable — juuuust barely.  I tried to get a playable prototype as soon as possible; I would have liked to go to bed on Saturday night with it playable.  Now, that didn’t work.  Pthbth. The prototype wasn’t playable until Sunday afternoon, but imagine if I wasn’t striving for earlier! Suck-sess.

Toolkit practice

I’ve had previous practice with HaxePunk, and I started messing with Ash in a previous game I attempted to complete for the 7-day Roguelike. Even though THAT attempt was a failure, it gave me crucial practice that made this submission possible, and also gave me base code to pick at for Mass Splitter. Of course, more practice would be better, so I shouldn’t wait four months for my next game…

BFXR

This audio tool is available in several forms; the one I used is BFXR. Sooooo convenient. Sure, all your sounds do tend to sound video gamey retro screechy crunchy if you don’t post-process them, but a lot of people go for that, and damn if it isn’t quick to pump out some placeholders.  (… that wind up being the final sounds when you run out of time)

Shut up, good enough, it’s playable

Shut up, I say! It’s good enough. It’s playable. I’m just happy I got out a game. Would I have liked to get those extra things I conceived of? Of course. Over time, with practice, I’ll be able to meet the goals I think I should be capable of. (I’m a damn perfectionist. I’d be faster if I wasn’t always trying some different way of doing things.)

I finished something playable in time that some people actually liked. Next time I’ll do even better.

Code damn you! Code faster!

I’m in for the compo. Too bad about the potato theme, though…

Editor: Sublime Text 2
Language: Haxe/NME
Framework: HaxePunk, HaxePunk-AI, Ash-Haxe
Visuals: Photoshop, FilterForge
Audio: Audacity, VLC, Bfxr, Autotracker-py
Version Control: Git

I’ll be using the Ash entity system. I’ve written some components, systems, and views in a prior game that I may want to pilfer leverage for the compo. You can find that base code on GitHub. Dead Grinder is not really a game at this moment, so much as it’s a pile of code that could theoretically be reassembled into something resembling a game given additional effort.

Good luck everyone!

Whelp, that didn’t work.

I made an attempt to complete a 7-day roguelike challenge over at 7DRL. I didn’t expect to complete it in time, but I had hoped to get more done. The game is Dead Grinder.

Scavenge and travel dur­ing the day, bar­ri­cade and fight undead dur­ing the night. Make your way to the heart of the city for some reason/​maguffin/​plot device to be deter­mined at a later point. First time build­ing a rogue­like, and I’ll fin­ish it, but maybe not by Sunday.

There were several reasons I didn’t get anywhere near done. Part of the process of trying to improve is to exposing myself to greater accountability. In other words, share with a load of strangers my ineptitude as an incentive to learn lessons.

• Late Start
• Distractions
• Did Not Leverage Work of Others
• Weak Design
• Weak Architecture
• Self-Sabotage

I started late. Partly that’s a failure to commit the time on my part, and partly it was real life interfering. I had some work, financial and medical issues to deal with, and I just didn’t cope with the extra stress that adds.

I found myself going back and forth re-architecting a roguelike engine around HaxePunk, so by the end of the week I had very little of a game in there. There are RL engines available, and I could have used them, which is definitely something you want to consider when you’re working under a severe time constraint like 7DRL. I chose not to. I’m okay with my reasons for this – mostly it was my desire to maintain a commitment to Haxe. It’s a good language, and I love like the rich variety of target platforms you get with NME (targeting mobile, desktop, or browser) using the (mostly) same codebase. I’m also trying to realize the benefits of maintaining a commitment to HaxePunk, built on top of Haxe/NME, but the implementation has been shifting so much lately that I consider the current build still broken. I wasted time trying to work in the latest 2.x build before rolling back to 1.72a which is the most stable build out there. I KNEW I shouldn’t have wasted time doing this under a time constraint, and I should have stuck with the older API; this is somewhat an element of self-sabotage, which I’ll cover in a bit.

I’ve been developing apps for other people for many years, and one of the problems I have writing apps for myself is failing to maintain a clear delineation between the hats I have to wear, namely the Designer Hat and the Developer Hat. Because of this, I was not only guilty of feature creep, which is bad, but “developing for maybes.” That’s when you skimp on the design because you want to get right to coding and hope that “if you have time” later you can fit in these broader, vague ideas. It’s akin to not designing at all, or coding by instinct. You’re not really sure what you need to implement, because you haven’t committed to it, so you wind up trying to add support for ideas that probably aren’t going to make it in and you haven’t thought through how it’s supposed to work. If a paying client tried to get me to start coding without a clear set of requirements I’d raise hell, that’s what they pay me for. Why would I not demand that of myself?  Worse yet, I also skimped on wearing the Architect hat, pressuring myself to jump into coding and winding up making numerous knee-jerk architecture changes along the way. C’mon man, be professional.

Knowing it was not going well, that there was precious little time left and that I had made mistakes from the offset, I wasted more time on self-sabotage. That’s when I procrastinate. Sometimes it’s your explicit, run-of-the-mill procrastination; reading your social media, or taking another “coffee break” that winds up eating an hour. But more often it’s under an insidious disguise. Trying to get HaxePunk 2.1 to work, as I mentioned earlier for example, appears on the surface to be a useful endeavor, but it is a terrible time sink I’ve encountered before. Once I realized it wasn’t a slam dunk, I should have stopped, putting it off until a point where I’m not under a time crunch. Or even better not start subconscious-distractions-as-procrastination at all. I think time-boxing might be a helpful technique to raise my  awareness of self-sabotage and the challenges I’m having/avoiding. It’s easy to let your frustration guide you, rather than your intellect.

I’m going to continue working on Dead Grinder until it’s playable, at least. I’d like to use it for my March 1GAM. To that end, I decided to finally READ my copy of Game Engine Architecture. At least the bits that are relevant to a non-AAA 2D game. I’m generally resistant to learning other people’s best practices, preferring to invent my own path, like an idiot. I’m clearly not an academic, teaching myself to code 30 years ago when I became a teen. That’s one of my personal issues I’m trying to address: leverage the work of others. Drop my arrogance and acknowledge that despite all my experience, my knowledge of practical, real-world game development is fairly limited, and it’s never too late to open your mind.

Thanks Ludum Dare and 1GAM, for encouraging me to put out more games … even if they are shamefully dull and unplayable. I had been working on a game about operating an underwater base but it was taking me too long to figure out what the game is actually about. I mean, okay, yes, it’s about an underwater base, but the game I want to make which is part economic sim and part micromanaging the staff was again reaching beyond my February grasp. Instead I cranked out a quick idea I had about manipulating Conway’s Game of Life.  The game, Death to Conway, is a turn-based simulation of the Game of Life, and you’re given an opportunity to kill an extra cell in between generations. Excitement? Thrills? Who needs em! We’ve got cells, lots of terrible cells, and they must all be killed!

Play Now (in browser)

This was another HaxePunk joint. HaxePunk is sort of in flux now as the developer is making some additional changes to better support hardware acceleration on native targets, so I rolled back to HaxePunk 1.72a to build this one.

I don’t know why I have to code everything twice. I think it’s a failure to personally commit to my own requirements. I knew I wanted to have the ability to run the simulation separate from the display, but since I didn’t commit to it at the start, I  tightly coupled the simulation with the rendering system. Then of course I get the game working and realize no one is going to have an idea if they did well or not. The game showed you how many turns you took, but this doesn’t factor in how hard the level is. So then I decoupled the simulation from the rendering. Now I can quietly put it through 50 generations or so to determine how long it runs before it becomes stable, and then use this number of steps and number of remaining  live cells to come up with some estimated “par” value for the player to play against. If I had simply committed to adding this feature in at the start, I could have saved myself some rework.

What Went Right

1. Haxe/NME with HaxePunk
I really enjoyed Haxe as a programming language. It’s got some gotchas (like iterators are automatically created variables that only exist in loop scope and loop ranges are exclusive not inclusive) but overall it was a charm to work with. I’m also glad I got to use NME. This meant I could target mac, pc, mobile devices, and swf all from the same source. There were a few cross-platform few issues, but not as many as I expected.

HaxePunk is a game library built on top of Haxe/NME (based on FlashPunk) and that worked out pretty well. I bumped heads with the API a few times, but ultimately it was a time saver. Without it, I would have spent too much time working on my own game tools instead of working on my game.

2. Using Texture Packer and Tiled Map Editor
Texture Packer (TP) is a great tool for assembling all your graphics in one place. Tiled Map Editor (TME) is a decent (and free) tool for drawing level maps. TME needs a “packed” image to work properly. That’s the image below on the left. Although TME needs packed images, it doesn’t read the associated XML files that TP produces. So when you add new images to the folder TP is monitoring, TP annoyingly moves images around to make room. So the images get shuffled around and then TME’s map gets all messed up, carpet showing where grass should be, walls turning into desks, etc. The solution I used was to number my images (04_carpet.png) and tell TP to sort by name and use a short fixed output width. It was still a pain to remove images using this process, so I just didn’t. Bear witness to the first two tiles in the first image below, which were placeholder graphics.

I also separated sprites going straight into the game without TME. To better work with HaxePunk spritemaps, I make several spritesheets based on the image size. Mostly I worked with 64 x 64. But I also found it easier to deal with larger sprites as whole images, rather than breaking them down into 64 pixel tiles. This isn’t optimal, but it worked. Hopefully by time for my next game Spritemap will be updated to work with texture packer images rather than fixed tile grids. If it isn’t, I’ll make my own class. Below from left to right are the TME map tiles, 64×64 sprites, and 256×256 sprites.

3. Dynamic object creation

This worked out really well. I used Matt Tuttle’s Tiled Map Editor code (not currently part of HaxePunk) to read the TME file and create a scrollable map. This code and TME both also support the ability to add generic “objects” to the map. Generic objects can be given a name, type, and (most awesomely) properties. Here I’ve got a worker, an effect, and a zone. The zone is used to detect when you’re close enough to interact with the worker (and therefore the spacebar is active). The quest effect (smoke) is searched for when you complete the quest. The worker uses facing to determine which direction to face, has all of his speaking lines in one place, including the line he uses when you complete the quest. Color is an old prototype property I never bothered removing.

In my main game world, after loading the TMX map (that’s the extension for a TME file), I process all the objects I can find on the “items” layer.

 var group = map.map.objectGroups.get("items");
 for(i in group.objects)
 {
     var clazzName = ENTITY_PREFIX + i.type;
     var clazz = Type.resolveClass(clazzName);
     if(clazz != null)
     {
          var obj = Type.createInstance(clazz, [i, i.custom]);
          add(obj);

          if(Std.is(obj, Zone))
          {
               var zone:Zone = cast(obj, Zone);
               zone.playerSignal.bind(playerSignal);
          }
      }
      else trace("Unknown object class found: " + i.type + " with name:" + i.name);
 }

So when it finds “Worker” in the Type field, it creates a Worker game entity dynamically, and passes it the properties I defined on the object. It uses those properties to bootstrap itself. This was very cool and has a lot of potential. Also I started messing with the HSL signaling library for cross communication. In this case, I’m binding the playerSignal() method to each zone, so the game world can know a zone is entered or exited, and can display the “press space to inspire!” message.

I started putting together a cascading notification system, where an object can receive a message (the only message I care about is “the quest just completed”) and can also pass on that message to other objects. In response to a message, the object can show, hide, or remove itself. So for example in the stolen lunch quest, two workers are arguing over stolen lunch. When the riddle is solved, the main worker is notified. The main worker has a property “notifies” that contains “arguingCoworker,lunchBags”. In response to being notified, the worker notifies the other worker (who speaks his “success” line), and notifies the lunch bags (which specifies “show” for its “onNotify” property, so the lunch bags suddenly appear).  I’ll be doing more stuff in this direction.

What Went Wrong

To some extent, these “wrongs” were also successes. But I suppose that’s just because failure is just an opportunity for improvement.

1. Tried to move to HaxePunk 2.x.

Mid project HaxePunk 2.x was released and I tried applying it. Everything broke instantly. For the most part I did a good job of suppressing my natural tendencies to fixate on a problem, but I wasted a couple of days trying to get 2.x working properly before I came to my senses and rolled back to 1.72a. That’s just time you don’t have to spare during a jam, even a two week jam, not if you’ve picked a project plan with no slack in it. It’s a hard lesson to learn, especially for an aging dog like me, but I have to pick my battles. It’s my Achille’s heel. This was such a unwinnable battle that, in fact, a week or so later 2.x still doesn’t work with my post-compo build. The good news though is HaxePunk 2.x is adding support for hardware accelerated blitting, so it’ll be worth the growing pains.

2. Started late, dreamed big.

I started a few days late, missing out on the initial weekend. And of course I picked new tools and game styles I’d never done before: Tiled Map Editor, Texture Packer, HaxePunk-Tiled (that’s the TMX reader), and orthogonal 2.5 perspective. This is all great learning stuff but it made it really tough to make the deadline and things had to get dropped out.  I also put together 10 puzzles, plus a bonus puzzle and an easter egg. If you haven’t played the game (feel free, it’s here), it’s about an alien who is fascinated with a piece of old poetry, and uses that poetry to inspire his coworkers. The way that works is you go up to a coworker, hit spacebar,  pick a stanza from the poem, and then see if that dramatically solved the worker’s problem.  I came up with the puzzles first, and then worked backwards to make the poem. That was a challenge, and probably not the best way to approach it.

It was a race to the deadline, which shifted on me. I thought it was 10PM GMT-5 on Friday and they extended it to Sunday. So I busted my backside to get as much as I could in there literally down to the last moment, and then I noticed the submission was still editable. In retrospect, this probably helped me, because I was able to slow down over the next two days and address some glaring issues that I couldn’t get in by what I thought was the deadline.

Still, there wasn’t enough time to do everything.  I wanted to add an end game cinematic, where after stealing from the guy who was stuck in the elevator you have a change of heart and learn from Hrothmok’s mistake. A FIRE-O-METER got dropped; this would have filled every moment you weren’t at a desk (tap tap tap!). The meter would fill rapidly if you gave a wrong quote and the boss would try to find you if the meter went red. The plants were originally a place you could hide from the boss. Now they’re just silly. Using aliens instead of humans was a time constraint compromise. Human animation was harder. I started messing with Spriter and would have loved to get some neat animation in there but there was just no time. And finally I needed a lot more art. The place was barren.

3. Three votes

For those who gave me feedback, thank you so much! I was very happy to receive it. I was unhappy with the lack of voting from the members. There were only 12 submissions. I voted for 8 of the 11 other folks, holding back from two who had voted for no games and one who had voted for one but also received  some votes. I knew that Mini LDs had less participation than the regular compo, but I expected more than 3 folks to rate my game. The lack of feedback is disappointing given the amount of work I put into it. How do you get better if you don’t get critiqued? I kept checking to see if someone else would rate my game. I didn’t know when the voting was going to end, I couldn’t find that information anywhere. They also didn’t announce the rankings (here) although maybe I’m being impatient. I made it to the top two, if you consider 3 votes statistically significant.

At this point I’m a tiny bit soured on Mini LDs. I’d rather come in last place and get lots of great feedback. I do see that other Mini LDs have gotten more participation. I guess I was surprised to see the ratio between compos and minis to be so extreme (1327 vs 12). But it was a good experience overall and I’m looking forward to entering the LD#26 jam in April. I hope that the lesson “pick your battles” sticks because I’m going to need it to stay focused for 48 hours.

If anyone is curious, Hrothmok – the protagonist of the poem – is a portmanteau of Hrothgar (of Beowulf fame)  and Darmok (from the ST:TNG episode).

I’m pleased to have finished a game for mini ludum dare #39:

http://www.ludumdare.com/compo/minild-39/?action=preview&uid=17811

The theme was hindsight. I’m surprised more people don’t do the miniLDs. Two weeks is a luxurious deadline in comparison to the 2-day compo. I didn’t complete the compo last time so I think the mini was a good step for me.

Last time I entered LD #25 giving MOAI a spin and being generally out of practice with game development. I was not able to complete my (surprisingly complicated) game idea in the time provided. I chose MOAI because I’d been exploring different game platforms and that was my first stop. Since then I’ve been looking at Haxe + NME + HaxePunk. For those who wonder:

Haxe is a programming language based on Actionscript. The compiler is multiplatform and can target C++, SWF, Neko VM, PHP, Javascript and to some extent C# and Java. This means you can use the same source code to compile multiple targets and produce native (read: fast) executables. NME simplifies this build process a good deal and adds project files, asset management, and a graphical API among other things. HaxePunk is a port of FlashPunk to work with NME. It’s a game library, providing a particle emitter, sprite maps, entity management, collision detection, and animation. An alternative to HaxePunk is Flixel, or you could roll your own game library on top of Haxe/NME.

One thing I like over MOAI is the greater variety of targets. I can compile and run my game in the Neko VM using nme test myproject.nmml neko, which builds pretty fast and launches the game. Then change neko to flash to build a SWF instead. Then change it mac or windows and it begins churning out C++ and creating a native build. Or change it to ios, android, html5, linux, etc. That’s pretty nice. Caveats include you can’t build some targets from some platforms (notably IOS from Windows), and there are some gotchas where some behaviors are slightly different between platforms, but overall I’m pleased with this set up.

Although I’m late to the party I thought I’d commit to producing a game for MiniLD 39, and use it for One Game a Month. I figure I come up with a game design that I think should be completable in 2 days … then with some luck I have a chance at just finishing it in 8 days.

Editor: Sublime Text 2
Language: Haxe/NME
Framework: HaxePunk, HaxePunk-AI
Visuals: Photoshop, FilterForge
Audio: Audacity, VLC, Bfxr, Autotracker-py
Version Control: Copy and paste

By the way if you missed the keynote video by McFunkypants at One Game a Month, he ends it with this great quote from Ira Glass:

Nobody tells this to people who are beginners, I wish someone told me. All
of us who do creative work, we get into it because we have good taste. But
there is this gap. For the first couple years you make stuff, it’s just not
that good. It’s trying to be good, it has potential, but it’s not. But your
taste, the thing that got you into the game, is still killer. And your
taste is why your work disappoints you. A lot of people never get past this
phase, they quit. Most people I know who do interesting, creative work went
through years of this. We know our work doesn’t have this special thing
that we want it to have. We all go through this. And if you are just
starting out or you are still in this phase, you gotta know its normal and
the most important thing you can do is do a lot of work. Put yourself on a
deadline so that every week you will finish one [thing]. It is only by going
through a volume of work that you will close that gap, and your work will
be as good as your ambitions. And I took longer to figure out how to do
this than anyone I’ve ever met. It’s gonna take awhile. It’s normal to take
awhile. You’ve just gotta fight your way through.

T-3 remains, but I’m losing steam. If I had the game framework all in place and working fine, then I might think there was a chance and I would keep going. But I’m still struggling with basic camera and animation systems. I didn’t THINK this was a complicated game when I started it, but I guess that’s often the case.

I learned a lot about MOAI, so that’s good. I can’t say I’m going to stick with this framework — the accuracy/lack of documentation was quite frustrating at times. I liked that I could drop to C++ if I needed to, and I didn’t like that I had to drop to C++ just to add arrow key support. I like how easy it is to do threads and action blocking, but dislike the lack of type safety in Lua. I would prefer a solution with better browser support, and the Chrome examples that come with MOAI are uselessly out-of-date. I clearly need to study more best practices in game development (my knowledge of the subject is rusty by 15 years), and do a better job of examining other people’s games with a developer’s eye.

I’m leaving off with a scrolling map full of procedural Abbey rooms. Although there’s some variation in the doorways I didn’t get to implement more interesting room types. There are monks who move around on their own, but without pathfinding they look silly. Monks experience hunger, fatigue, and guilt. When any value is sufficiently high enough they have a chance to seek food, a bed, or do work. Here’s a monk chowing down in the middle of nowhere with little “num num num” messages popping over his head:

The monks have four sides to them, and that’s call. I didn’t get to animating their movement or any other actions:

Here’s the dust monster (that’s you) in native form. The camera was not cooperating. Sometimes I could get it to smooth scroll and follow you about and sometimes not.

In native form, you can sneak behind a monk and possess them. Well, that’s the theory, that’s where I left off. The notion was you’d have a timer before the mythical underworld sucks you back in, so you’re hopping from body to body trying to forestall that. Here’s a possessed monk:

Little blue swirlies about his head. You would then control the monk, be able to pick up items (such as knives), and then kill other monks with it. Possessing monks provides a kind of nourishment that resets your meter, and also causes it to drain slower. The ultimate goal (because you are a villain, by the way) would be to kill all the monks in the abbey. Monks were built with an alarm level that would determine how suspicious they are, which makes it harder to kill them.

I cut the idea of a snake form, but apparently that wasn’t enough to get this completed in time. Snake-thing would have been your true physical shape, birthed out of a possessed monk. As the snake, your timer would become a health meter, you could kill monks by biting them, but they could fight back. If you died as a snake you’d go back to dust form. The snake could also merge flesh with a freshly-killed monk. This is better than being stuck in dust form but it really freaks out the friars, not to mention the blood trail it leaves when you walk… No matter.

I had fun and I’m glad I did this. If I do it again, I will definitely do some warm up and get together a better personal library. Hopefully by then I’ll also be more adept at MOAI, or something else. I was on my way to trying out Haxe/NME when the contest came up. I will likely continue this game in my spare (and spread-out) time. Good luck to everyone else!

As expected my lack of experience with this framework has slowed me down ridiculously. That and I’m out of game dev practice. I mean I kept saying “oh yeah, I remember doing something like this 20 years ago” but that was after a few hours of trying to fill in the gaps. Don’t get old. Some definite things I like about MOAI at this point but documentation is not one of them. You get the feeling that when Patrick says “documentation is weak” his standards are even lower than yours. They’re not weak, they’re virtually absent. There’s some doxygen API code, but most of the words there are one-liners and fail to say how anything works together. For that, you go to the tutorials, which are nearly all out-of-date. It’s not all bad, but it means this – my first game jam – I’m flying by the seat of my pants. I’m also digging Lua, for the most part. I love the multiple return parameters. I hate the lack of type safety.

Would be nice if all the rooms didn’t look the same. I like the marble tile floors, though.

That’s a “procedurally generated” abbey. Which is a fancy term for I thought it would be easier than using a tile editor and three hours later all my rooms look the same. I’m scaling back already with hopes I can come up with a finished product by tomorrow night. Next step is getting these ugly little monks walking around. I’m way behind.

I worked last night and came up with several ideas. Then I went to bed and tried to sleep, which failed, so I went back to work until 6AM. I’ve got the base code for Murder Among Monks together, although there’s hardly anything to see yet. This is a game where an ancient deity has risen up out of an isolated abbey and is systematically possessing and murdering the monks who live there. Already I can see I’m going to have to trim a lot from my design doc to get something complete by Sunday night.

The other serious contender was The World Needs More Chaos, a game where you are a super villain and the best score possible came from raping the world of its resources, collapsing governments, starting riots, killing people in massive numbers, bending people to your will, getting a space ship built, blowing up the planet and escaping in time. While this seemed like fun, the actual ruleset needed a lot more fleshing out. It probably would wind up being a bigger task than the monk game.

Long-time developer, Ludum Dare first timer. I’m trying to get back into game development after a long break, and this compo seemed like a great way to realize how out of practice I am. I’m using MOAI because that’s what I was last evaluating. If I tried Haxe/NME first, that’s probably what I’d be using now. With my perfectionism, limited experience with the framework, bad attitude, poor habits, low expectations and … uh … what was I saying? Well never mind that, I accept this challenge. With a fervor. And a hat. And inside the hat is additional fervor. With cheese. And inside the cheese is another hat, an impractically small hat, also made of cheese and probably additional fervor. I’m revealing how little I know about fervor, cheese and hats, aren’t I.

Editor: Sublime Text 2
Debugger: ZeroBraneStudio
Languages: Lua, C++
Framework: MOAI
Visuals: Photoshop, FilterForge
Audio: Audacity, VLC, Bfxr, Autotracker-py
Version Control: Copy and paste

Mac on the left, PC on the right, confused “child of divorce / joint custody” monitor in the middle of it all.