I just wanted to let people know about the enhanced version of my game I just uploaded. It’s an abstract game where you use shadows to orient yourself and go through walls to escape enemies.

You can play Shape of shades here : [PLAY]

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.

So this was my third time entering Ludum Dare, but only my second entry.

In the game, salesmen will come to your house and place shit you don’t need. So you need to get rid of it before the shit starts stacking.

GOOD

- I manage for the first time make a game under 48 hours.

- Learned Haxe.

BAD

- Time, I planned something else but I got distracted with stuff around me.

- Programmers art..

Short and sweet

Now keep playing games and rate!

Intro

IceBreaker is a minimalist free-pause RTS-ish thing (probably better described as an FTL-like, though bearing little similarity) set in a Cyberspace similar to the one portrayed in William Gibson’s Neuromancer (a book which changed my adolescent life and is at least partially responsible for my getting into programming).

I didn’t get much (okay, any) journal-writing done during the weekend, though there’s a vague run-down of events in the project’s github page.

So consider this (rather large) postmortem post-hoc overcompensation. (and apologies in advance for the spam)

Blender was extremely helpful for rapidly producing the future-retro look very quickly, even the sprites were tiny renderings with wireframes

You can’t quite tell, but it’s a stripped-down RTS:

• no resources or buildings (instead you have gestation periods for replication)
• since you can’t build unit factories, you instead have to replicate (and be vulnerable), but if you’re standing still you will heal
• there /are/ classes, but they are restricted to *strength* (hit amount) and *vitality* (health)
• it’s meant to be broken down into very short levels, generally with you collecting/destroying something which is being protected.

Statistics

• Four litres of coffee consumed
• A whole forest of tobacco
• 3,617 lines of code
  • That’s 60 A4 pages if printed out
  • According to Wolfram Alpha that’s:
    • about 17.8 metres ( 58 ft ) tall
    • 6.6 storeys high
    • and about half the diameter of the Hindenberg
  • Very sore wrists (hush, you!)
• somewhere between 3 and 6 hours of sleep

What went wrong

1. strong underlying system
   • unlike my last two LudumDare attempts, I knew what I wanted to do very quickly, I wrote about three pages of ideas and then stopped when I realised I’d already made my mind up to do the first one.
     However I didn’t flesh out the details as much as usual and so started building the basic framework while pondering, knowing I could change the details later on.  This resulted in a lot of code ( ~60ft worth! ) that, whilst extremely useful was probably not necessary to get the basics of the game done.
     I remain convinced that it was doable within the alotted time period (the post compo version is only an extra 4 hours work, with the last 3 mostly being unnecesary tweaking)
2. not enough testing of environment
   • I did more preparation than previously, but I wasted time on a few things which could have been sorted out before the compo:
     • setting up the live stream stole about 1-2 hours, admittedly I was feeling a bit braindead/overwhelmed/uninspired so this was a better utilisation of time than say, nothing.  But this should have “Just Worked”
     • Final builds (I’ll get to that)
3. using an unfamiliar framework and language (again)
   • In my first LD, I used AS3/FlashPunk which I’d picked up a couple of hours before the compo.  In the second, I used Java/LibGDX and didn’t complete – whilst I had familiarity with Java I was very very new to LibGDX and as a result spent wayy too much time googling.  This time was a fair bit better (Haxe is quite similar to Java/AS3) but I still had little to now experience with either it, or HaxePunk
   • HaxePunk is quite nice, but unfortunately not quite “there” yet for me, I wrote a disproportionately large amount of patches to the library in order to get basic features to work normally.  This stole quite a bit of time, but it was far too late in the project to change ships.  I look forward to using it more though.
4. refactoring at the halfway point
   • despite having most of the system quite well designed in my head, I had to stop and write a vast swathe of code on day 2, partially to undo the odd choices of my sleep-deprived self the night before
5. sleep (braindead 6+6 hours)
   • I should have done it sooner, and more.  I’m quite good without sleep, but I ran rampant on the code-base when I  started getting exhausted.  Much time was spent rectifying this spaghetti.  I’m not sure how long I actually slept (somewhere between 4 and 6 hours), but I easily lost 12 hours to silly choices and then the bleary-headedness upon waking.
     

     an early screenshot complete with pointless UI and ugly tiles

6. didn’t demonstrate theme clearly enough (despite following it)
   • I had basic gameplay down very early in the project this time, but the sleep-spaghetti resulted in about 10-12 hours of programming which left me (effectively) where I started
7. planning
   • I actually planned quite well in a lot of ways, but some very fundamental (and rudimentary) aspects were overlooked initially, resulting in much confusion and wasted time
8. submission process panic!
   • I tested my environment this time to avoid this exact thing.  However I discovered (at submission time) that whilst my project ran perfectly in the Flash standalone player, it would silently fail completely in-browser.  It turns out all I had to do was add “-web” to the build command, but it took me far too long to discover this!
9. no end-game detection or automatic level progression
   • despite “shipping” with a few levels, the submission process issues resulted in my missing the 20 minutes that I needed to finalise this important factor of a “short-level based game” and the gameplay suffers for it.

What went right

1. strong underlying system
   1. Yes, it’s a dirty trick having this in both sections.  But I maintain that the approach was a good one, early efforts resulted in the tutorial system being a mere 45 minutes to implement, and most new features were added extremely quickly
   2. I used JSON for most of the configuration of the game, allowing rapid prototyping of enemy AI, character attributes, menus and the tutorial system)
2. using Haxe and SublimeText 2
   1. This was a pretty awesome combination, I look forward to being able to justify the $70 license for SublimeText2 (this was my first real experience with it, and it was wonderful).  I have been using (shudder) Eclipse for a while despite my lack of appreciation for IDEs in general so it was nice to have a “real” development environment again.  However I’ve gotten rather dependent on Eclipse’s easy mass-refactoring, and you can really tell (names of things changed through the course of the project and thus there are some things named Agents which are actually Actors and so forth)
3. the game idea
   1. I think this concept is pretty sound, and I enjoyed playtesting it.  Definitely building some more levels and a little more “Juice” and thrusting it in the face of anyone who walks by
4. music and art
   1. There were a few times when my brain completely went on strike, so it was good to change gears and work in Blender or Renoise to build some of the feel, having these elements in game was also fantastic for morale.
   2. The music was made in about 5-15 minutes for each of the two tracks
   3. Art was quite quick too, despite a few false starts
5. tutorial system
   1. I’m really happy with the tutorial system, which could also double as a mission introduction system.  It hooks into game events and each dialog of the tutorial can have a number of events required before it appears, or disappears making it very easy to make a clear (and importantly, responsive) tutorial.

The in-game tutorial system is quite smart, if a little overenthusiastic

Last words

Thanks to everyone for an awesome experience yet again!

Project source (github) | Project page | Live stream (twitch)

I strongly encourage you to try out the Jam/Post-compo version after you’ve rated, as it’ll be a lot more clear what I was trying to achieve

when I was a kid this sort of image was like crack. it’s so laughable now. stupid kid.

------------------------------------------ 
--- I - C - E ---- B - R - E - A - K - E - R --- 
------------------------------------------------

(When I get up I’ll do a post-sleep post-pre-mortem-post-mortem, some of this will just be taking some of the prolix and manic text out of my submission page – yay sleep dep!)

That was a lot of fun! (but it’s not over yet..)  I somehow wrote just shy of 3,000 lines of code in 48hrs.  It’s almost certainly 90% ugly horribleness, and I’m not a fan of LOC as a metric of productivity – but it still feels pretty cool.  (If I printed it all out it would take about 46 A4 pages).

Unfortunately, quantity of code does not equal a finished game.  About halfway in (after some sleep) I lost a lot of time to vascilating between confusion at the code I’d added before passing out (that guy was craaaazy) and feeling generally dumb.  But eventually I got it nailed down and was grateful to discover that, whilst I had lost track of what I was doing – the more responsibly-minded part of me had sent me down a tunnel with no wrong turns.  Not to say I didn’t bump my head a few times, slip over in miscellany or mistaken inanimate objects for long-lost lovers..

 What went wrong / right

that one’s for the morrow I think, sorry – they’re my favourite part too.

Tools Used

• Music made in Renoise
• Sound effects in Renoise + Audacity (and Bfxr at the last minute)
• Graphics in ASEPrite, Blender and the system default editor
• IDE/Editor almost entirely SublimeText2 (unregistered)
  • I feel terrible about that, as I finally see how cool it is
• Coded in Haxe with HaxePunk
• I also (eventually) streamed my progress at Twitch.tv

It may not be much right now, but I think after I’ve checked the rules I may enter the Jam so I can see it closer to a working game.

I’ll be uploading post-compo editions to the entry’s page as I go (in about 8 hours or so)

NOTES

(this is just copied over from the submission page to reduce clutter, tl;dr: rambling…)

circa T+05 mins
began writing submission
circa T+20 mins
I’m having a few unanticipated issues with publishing; the .swf
seems to work fine in the standalone Flash player, but not
even remotely in a browser.
I’ve got 20 minutes or so of submission hour to work it out, but
here’s the swf for the time being (same link under “Windows” unfortunately)
circa T+56 mins
Okay, got it to publish. Seems to have odd framerate issues.
Will use my last 3 mins to see if I can suss it out.

My game, Minimalist TD is done! Play it here.

This was my second LD (First one being LD24). All in all, it went a lot better than the first one. I’m kind of happy with my result and I think it’s kinda playable, even though it’s probably not terribly innovative (a generic TD game really). I have never done a TD game before, so I thought that’d be fun as well as a nice learning experience.

Still not quite sure about the difficulty curve. It probably ramps up a bit quickly, but then again, there’s only one level and a bit of trial-and-error can be fun. Lemme know what you think!

Here are the tools I used:

Coding:

FlashDevelop + Haxe + NME + HaxeFlixel

Graphics:

GIMP (although I didn’t need it very often, as you can tell by looking at the screenshot).

Sounds:

Bfxr and WAV to MP3 for soundeffects

Step Seq. for music and Audacity to record it (Inspired by Arkeus. First time I’ve ever created music, not sure if I’m happy with it. It’s kinda short and doesn’t loop very well… but better than nothing, right?)

Other:

DAME for tilemaps

Using temporary art and basecode from a previous unfinsihed haxe game:

first screenshot

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!

I have had HaxePunk recommended to me by a few people here and there, and now that I’ve done enough to get it (seemingly) working, it seems like I should use it.

So, I’m going back to my roots of having no idea what I’m doing.

That’s right! I’m going in with minimal experience. Ludum Dare is at its best (for me at least) as a trial-by-fire. The struggle of learning under that kind of pressure keeps it fun for me.

I’m not completely without knowledge, though. I’ve done plenty of things with FlashPunk (which HaxePunk is a port of) and I’ve used Haxe a little bit before (though it’s certainly been a while since I last used it), so I kind of have some idea. Kind of.

As for the type of game…

I want to make a shmup. I love shmups. They are probably my favorite genre of game. Kenta Cho’s shmups are some of my favorites. I also like Danmaku (aka “bullet hell”) shmups since they are nice and challenging. I also love to destroy lots of stuff, and shmups are generally pretty good for that.

So, with all that said…

- Henry

(Edit: Put some tags on this post, that’s all.)

I’m in and i think i’ll be using:

Haxe as programming language.

Autotracker-c for music.

…

Last time I entered the Jam with Carduus but this time I am going back to the 48h Compo

Like every time, I will be using Haxe + NME as this provide the most flexibility for multi-platform.

You can follow me on G+

I will also be streaming on twitch : http://www.twitch.tv/thotor

With all the potato craziness, I forgot to announce this fact!

I’m in for my 6th(!) Ludum Dare. I plan to use Haxe + NME + HaxePunk to make a game for web and mobile devices. I’ll use GraphicsGale or GIMP for art, bfxr and audacity and maybe something else for sound, and caffeine to keep me awake.

Have fun everyone! Remember: #NoPotato #YesMeat

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.

I’ll be entering this mini ludum dare and will be using h3d/h2d to make an Earth-themed game using Haxe… I’ll probably be starting on Thursday or Friday.

Here’s why I don’t like my game.

(more…)

Somethings went right, some things went wrong, but they came together in the end to make my entry. For example, in the middle of the dare (Saturday at 7pm GMT) the game I was working on glitched and the tiles loaded from the TMX level file were incorrect – in this case it was a good idea to restart the game with a different concept.

Concept:

Whilst the idea of running over cats is an original one, it needs a story.

Controls:

Shown at the main menu, but some other keys like ‘p’ and ‘enter’ for pause and ‘space’ for jump exist.

Mechanics:

I wish I had added in a few more kinds of cats and animals, but I probably would have ran out of time.

Mood/Lighting:

The game itself, is very upbeat, but I suppose it’s got a dark undertone considering you just run over cats.

Graphics:

I did the lazy thing and used mtPaint to make pixel art, but they turned out alright.

Humour:

Did pretty well here considering the game consists of running over cats.

Overall:

It was a good experience that benefited me in management of time etc in game developing. I look forward to the next Ludum Dare.

Linky: http://www.ludumdare.com/compo/ludum-dare-25/?action=preview&uid=4506

I think I have everything working in time. Maybe I have forgotten something but, booya, nobody will find that hopefully.
Now its time to get some sleep

I’m pretty much done for today, and I only have a few hours tomorrow to finish the game. At least I got some of the functionality done, though.

As some background, the game is called “One Bad Apple” and the basic plot is that you are one of a group of adventurers fighting monsters in a dungeon (no points for originality). Everyone else in the group wins if they defeat all the monsters in the dungeon. However, your victory condition is different: make sure everyone else is dead and that you escape with as much loot as possible. You can’t directly attack your “friends” so instead you have to make sure they all die by aggro’ing too many monsters, and setting off traps at the right time.

Right now all I have to show is this measly screenshot, and I need some sleep so I’ll try to finish more tomorrow.

The Minotaur is a little tired…

The game design is almost complete: You are the Minotaur and every day is the same, the nice people of Crete send you a virgin to sacrifice and warriors show up to defeat you… mmmm… warrriors.

“A day in the life of The Minotaur” is a board game (yes like the ones with dices) x Roguelike. The board generation is procedural and you move throwing he dices. If you face a bifurcation you have to decide which way to follow. A cell of the board can have an item or an enemy. You win when you find the virgin and sacrifice her…

Done:

• Board random generation
• First version of gfx
• Board scrolling
• Simple HUD
• Dice throwing
• Minotaur movement
• Goal and new level

Left to do:

• Enemies, treasures and energy (are already there but they do nothing) so if you land in a cell with gold, for instance, you should get gold coins
• I may implement a combat mini game
• Much better HUD
• Sound effects
• Epic Music
• Dice animation
• Cut scenes or at lest lines.

You can try it here: v0.3

See you tomorrow!!!

I’m now a few hours back from work and already did some work. Added player movement and of course dynamic lights, because that is very important for the game.

Now I have done that it is maybe smart to add some collision detection to the player to prevent it walking trough walls.