I had a great time rushing like a headless chicken to get things done. It’s great to have another game jam under my belt. I love all the feedback I’ve received on 10 Seconds in Hell, and seeing players’ reactions go above and beyond what I was hoping for.

It feels amazing to craft an experience in this short a timeframe that really impacts people on an emotional level. So much for needing millions of tris to get feelings out of gamers!

Thank you all! <3

[Update: I wrote a spoilerific post-mortem, which you can read here.]

Hello everyone!

So I’m super-thrilled that people have been getting in to Total Spaghettification, a lot of people have ‘clicked’ with the mechanics and have been perfecting their runs through the game.

There’s one point of contention that is proving to be an annoyance to people, and that’s arguably the most important part of any game: the controls!

Why are they so weird? Well:

I knew early on I wanted to strip the game controls down to a minimum. Canabalt + Nikujin was the base equation, and I wanted to experiment with not having the usual directional controls. I liked the idea in my head of the lil’ guy just charging around like a Lemming until exploding, and I felt that if you were flowing well enough in the game, just bouncing off walls like a pinball would be enough!

So as I started to put together the movement controls I went with an ‘A’ button to jump and wall-slide, ‘B’ button to floor-slide and dismount from walls. I developed most of the game like this, and got used to the way they worked.

Late on Sunday, I showed it to my partner and quickly found out that the controls were a useless mess, with no flow or form, and only served to make a frustrating game more difficult. Whoops.

So I spent a few hours furiously re-writing the movement logic, and settled on the ass-backwards way that it currently plays – different keys for jumping in different contexts. It was the only way I could get the game to feel like it was flowing again, as doing a succession of wall jumps was just impossible with the jump/wall-jump being on the same key!

I thought it was a fair compromise – if you managed to get to grips with the controls it would be rewarding, but there was a huge danger that I was asking players to get used to an unnatural control scheme, on top of being pressured by the time limit and fall damage. It’s like saying “Hey, I know you’ve got a bus to catch, but would you mind filling in this survey? Also we’re standing next to a wasp’s nest.”

This might have worked out better had I had time to implement a proper tutorial. In fact, this all served to highlight some major flaws in my development skills – how to best teach the player how the mechanics work in a way that is fun and compelling. I just banged in a practice level with no time limit to try and address the problem, which again was a compromise as time was running out, but it probably wasn’t enough overall to address the issue.

All of this is a perfect storm in the kind of environment were people don’t really have time to learn a whole wacky set of controls when going through and rating 100s of games. And not making the controls intuitive enough is a failing on my part, and a lesson for me to take away from this!

A non-usual mind-warping game starring Carl Sagan.

I’ve done a few Ludum Dareses now, and I have one rule in my brain for getting a game done in time: Don’t try and do something you haven’t done before. You waste far too much time troubleshooting and learning, and not enough time polishing and tweaking. But alas, when the theme was announced I knew I had to break this rule. I knew I had to figure out how to write a raycaster.

The reason was simple: Before the comp I complained about the theme “10 seconds” on IRC. I posited that it too-heavily implied a core mechanic – and avoiding this implication would only lead to novelty or quirky entries. Determined to come up with something different I formulated a plan; a plan that involved fractals, and crazy colourful graphics, and Carl Sagan. A plan that would eventually become Time Flies Straight: a novelty, quirky entry. Ah well.

The post-mortem

The game ended up pretty close to what I had in my head, which I’m really happy about. I had hoped to add some bad guys to stalk you through the labyrinth, And I planned for the little green guys and the related “happiness” and “wellbeing” level to actually mean something – but I had to scale things way back, having wasted so much time trying to do something I hadn’t done before: write a raycaster.

I had written the actually “ray raycasting” part for my last LD game and I thought the rendering part would be easy, especially thanks to this article which I was following closely. Alas, it took me much of Saturday to get a satisfactory texture mapping algorithm working.

After this hiccup, things went much more smoothly. The crazy wobbly time effect was nice and I had made some cool sounds to accompany it. The sounds were supposed to be chopped up and the various arpeggio speeds would relate to your depth into the maze – but, thanks to the time I lost on Saturday – it ended up as a straight looping mp3. Still, the randomness of it is kind of nice… suddenly, for no reason, things start speeding up and lends a strange air of expectation.

I had to work right up to the deadline – and was exhausted by the end. It was a bad time to be trying to do “level design”, especially when I was working with a massive 2D array directly in my text editor. The sea of integers pulsating and wobbling in my brain – made worse from having to playtest the results. It was an odd few hours.

Overall, I’m really happy with the result. I actually made a game that I had in my head – a game that has a “feeling” to it. I’m not going to work on it anymore after the comp… I think it’s just a nice experience more than a game. Now I can’t wait for LD28!

Hijack Humans Hastily was my compo entry for Ludum Dare #27 under the theme “10 seconds”. It was a game developed in pure ActionScript 3 (using Adobe AIR), with the OUYA as its main target but with a web version available (given the platform). Here’s a short gameplay video:

Here’s the mandatory post-mortem, with a few development snapshots scattered around the article.

First physics bodies

What went right

Reusing stuff I already knew about

In my previous Ludum Dare entries, I’ve rarely re-used many systems. I like to build my own stuff. In fact, so far I’ve refused to use full-fledged engines, and while I’ve used Unity previously, it was mostly an excuse to force myself to get acquainted with it.

Particles for thrusters

This time around, I had decided ahead of time that I would be using AS3 and a couple of frameworks for certain features (Nape for physics, Starling for GPU graphics). I had no engine, per se, but I complemented those by developing several additional libraries for game controller input, game looping, and physics level data loading (most of which are open-source and posted on my blog). I was certain I’d spend more time working on a game, rather than working on systems for a game (which, as fun as it is in itself, doesn’t make a good Ludum Dare entry).

Using image assets

The strategy worked pretty well. While I still had to use a pretty amount of time getting basic stuff working (due to my lack of knowledge of some Nape features, for example), I felt I was actually building a game earlier than on my previous entries.

More particles

Art was straightforward

I loved doing the art for the game, even though I hadn’t been drawing in a while. While a bit was dropped and unused (specially background art), I think the simple aesthetic I reached was pretty flawless even if it wasn’t brilliant.

Image assets being added

What went wrong

The idea

Getting a game idea is always the hardest part for me, specially under pressure. I spent the whole first semi-day of the compo (Friday) doing nothing other than dicking around online, or reading, just because I couldn’t figure out an idea. The idea Saturday morning – of a flying UFO capturing humans – was a mechanic I’ve been thinking of for a while, but to be honest I didn’t have the gameplay challenge or the relation to theme figured out for a while.

Making the UFO landable

Features were dropped (surprise)

While I tried having a smaller scope, some features were dropped out of the game. There’s only one level, for example, and while it’s randomized and it’s all based in easily configurable parameters (size, assets, etc), I never had the time to add actual level progression and assets for more levels. The current level used (city-ish) is a mix of my two initial levels ideas, park and city.

Adding human targets and background art

Worst of all, I couldn’t even begin to implement the enemy A.I. In the best Choplifter fashion, the second level of the games was supposed to game enemy tanks that would shoot at you. They would not do any damage, but their projectiles would throw you out of balance and make control a bit more difficult.

Making humans capturable

Not enough time for bug testing/QA

While I didn’t run into any huge problem, my entry still had some issues I had no time to test. Those include some bugs related to web playback (losing 3D context when switching between fullscreen, for example), and some OUYA pitfalls I wasn’t aware of (having the game suspended by the system puts it in an unplayable state when restored). Those are things that are likely easily fixable, but were noticed too late.

Adding building obstacles

Conclusion

I think this was probably my most well-rounded Ludum Dare entry so far. I’m pretty happy with how it turned out, and I spent plenty of time watching my own time-lapse video of the development process. It’s great seeing it slowly transform before your eyes.

Still, the relative smoothness of this Ludum Dare made me realize something. Ludum Dare is a lot more about the content, and I’m not sure I’m very happy with it.

Because of the limited time, it’s better to have a great idea, create a lot of content and gameplay, and test it out until you have something fun. Some of the compo and jam entries I’ve tested were really fun to play, more than just being an interesting concept that could become a game.

In my mind, I like to use Ludum Dares to explore new mechanics – mostly in the form of new code – and almost as an excuse for learning something. And to be sure, I’ve done a lot of that; all Ludum Dares have been a great experience, even the ones where I didn’t have anything very playable in the end. I learned a lot in a short period of time.

Still, having to be forced to spend more time with content and gameplay is something bums me out. Having to ignore bugs unless they’re showstopping, and having to get things to work fast (as opposed to right) is something that, over time, I’ve almost forgot how to do. Nowadays, I like to get a cool system to work as a stepping stone. In a way, it’s almost as if gameplay is secondary to that (in that it comes after that, not that it isn’t important).

Something else made me realize that. Over the past few months, I’ve been slowly developing a game prototype on my free time. It makes me really, really happy. I take my time to get some things right – be it gameplay, animation, or lower-level systems – and it’s very rewarding. I do one thing at a time. Putting a pause in developing that to do Ludum Dare #27 was good in technical terms – I ended up learning several features I plan on adding to my game, such as ray casting in Nape – but I also realized I wanted to get some things right rather than just getting them done. For example, my starling shape utility classes – to transform imported Flash Sprites and MovieClip into Starling textures – is a mess. It works, but there’s a lot of edge cases where it doesn’t work as intended, or where there’s a lot of redundant code. And I’ve used it in 3 projects already, with no actual time for refactoring them and making them elegant.

I know the usual solution for Ludum Dares it to use an engine. Some might say I should have used Flashpunk, Citrus, or any other engine. And they would be right. But the reality is that it wouldn’t have been as much fun for me. As weird as it sounds, to me, Ludum Dare is an excuse to write something from the ground up. Not just to get something done, but to appreciate the journey of development. And I’m sure that, for many people, seeing something done is what motivates them over everything else. It surely motivates me. But I’m starting to realize that I care too much about getting systems right. Maybe it’s an annoying developer thing. My own professional work is always done on tight deadlines, make no mistake, but over time I’ve learned to balance it all and use time well to get something that’s mostly right from the get go. It normally means a better, more stable project in the long run.

I’m very grateful for everything I’ve done and learned. Ludum Dare is an awesome idea. But I’m not sure what I’ll do with the next Ludum Dares. I might do them, but maybe as part of a team, or maybe without submitting anything. I may use it as an excuse to build a “demo” of a system – e.g. my game controller classes, which need a few additional features – rather than an actual game to be played. We’ll see.

Tags: as3, LD27, post-mortem, postmortem

The hyper-advanced V229 prototype battle pod now features an enhanced man/machine interface,  allowing remote pilots to control the vehicle from the safety of their web browsers.

ALERT! ALERT!

V229 power consumption is already beyond 5000% safety threshold.

Use of this module is not OH MY GOD WE’RE UNDER ATTACK~~~~~~~~~~~~~~~~~~~

http://www.ludumdare.com/compo/ludum-dare-27/?action=preview&uid=21279

—–

Ahem.

Forgive the delay getting the web build up guys, real life’s been pretty flat-out since the Jam.

Have fun, let me know what you think!

Uh… Yeah. I don’t really get this formula. Seems like a rather simple subtraction, but still…I’m not sure, if I’m *supposed* to play and rate as many games as possible, or if I rather aim to have more votes on my game than I vote others… There’s something in the legend about a “loser” badge, if you are trying to reach a high coolness rating ( = rate a lot of games by him/herself?) Is “coolness” a bad thing? I mean I played a lot of games, voted approximately for 20 others (as suggested by the LD website) and now, I’m not really sure… am I supposed to vote or not?

As I understood it so far, you shouldn’t vote for others too much, if you don’t have many votes on your own submission. Reason: Submitting 1 star on every other game to downvote these? I would never ever do that, it’s just that while I love playing a lot of games and submitting comments and/or ratings, I don’t want to “hurt” my own ranking, but I don’t want to not rate others at all, since they need a certain count of votes in order to even be taken into account anyway.

I know that there’s another post about this topic, but I still don’t understand. IF the coolness thing is good, then a low default score would make sense, but then what is that “L” thing all about? And if coolness is a bad thing, why would people vote at all?

Thanks in advance!

26.6 hours squeezed into 10mins. happy with the feedback on the game so far.

http://youtu.be/hJ7bpjFbZ1U

http://www.ludumdare.com/compo/ludum-dare-27/?action=preview&uid=19384

First off, I want to say thanks to everyone who has made this my best Ludum Dare experience to date. Shuutshimi has been very well-received thus far and I was even able to learn a couple things post-jam from it. I mentioned earlier that I was considering skipping this one due to other priorities getting in the way of the 72-hour jam, but it was those interruptions that forced us to think smaller and more reasonably than we otherwise would. We had less than 48 hours all-told due to weekend and work commitments which shaped the way we developed the game, and it was a lesson that we – and I feel, myself in particular – desperately needed to learn.

What Went Right

Practically EVERYTHING went right. I know that’s going to kill the suspense of the remainder of the article, but it’s true – once the competition kicked off, Wanyo (artist) and I (coder) threw some ideas back and forth for a while. Once we had a list of ideas, we picked a genre for the game, discussed variants on that genre, and picked whatever would be easiest to develop. From there we culled the list of elements to what was relevant to our game, and then culled the list further on perceived ROI until we had a manageable list. Then we went to work. Once Any Yes (audio) showed up, we gave him a quick explanation, and we were all set to work.

The Coding

In the past I felt my coding to be notoriously sloppy – sure, the end product works, but I tend to refactor my code a lot as my understanding of the requirements grows. I kind of plunge in head-first and fix my mistakes later, or as I go. But with Shuutshimi, apart from extremely minor things (eg making it a one-line change to add more hats into the game from the existing 3) I did just about no refactoring. I guess I’m learning from my mistakes!

The Drawing

I feel bad that we didn’t stream Wanyo’s screen/our development studio, because the visuals are the face of the game and often where our character designs are fleshed out. I find it interesting how our character designs begin and evolve, because they reflect the overall tone of the game which, in this case, was incredibly silly. One of the biggest time-sinks from our last Ludum Dare was the unreasonable amount of spriting involved in the main character – well over 70 sprites. That’s not very achievable in 72 hours, much less 48, especially when other graphics are required. The design of our Cute-Em-Up, however, demanded at most 8 frames of animation per object, allowing way more time for polish and additional assets. We had to cut one of the enemy characters from the jam unfortunately, but what made it into the game looks excellent, in my opinion.

The Composing

I didn’t even consider how Any Yes was going to react when he was greeted with the following words: “We need as many ten second songs as possible!” Any Yes would have to elaborate on his process here, as it’s not something I can really observe. I understand the basics of Famitracker: My own words on it are “You put numbers into the program and it makes beeps and boops based on those numbers” but beyond that – in addition to music theory and composition and all that – are pretty lost on me. I can make a passable stand-in for visuals, but what Any Yes does is beyond my understanding. The shop music was replaced partway through the jam with something a little catchier, and I’m way happier with the change. I didn’t like the first draft of the title theme at first, but it took very little time to grow on me, and once the title screen was in place with scrolling backgrounds, it felt so perfect which is why, when he suggested changing/modifying it further to something way more energetic, I was reluctant. I should just flat-out trust what he’s doing because, as those of you who’ve played the game would agree – what made it into the final product is fantastic.

Hey, I’m allowed to think the game’s soundtrack is awesome, I had nothing to do with it!

What Went Wrong

No screenshots in the Post Mortem (this). I’m at work and supposed to be working, so I’m making this as quick as I can.

The fourth enemy got cut from the game due to graphical time restraints.

The bubble background was originally supposed to move to the left as well, but also bubble upwards. At first the plan was randomly generated, individual bubbles, but time and complexity got in the way. Not enough ROI.

The backgrounds in general were supposed to have their own scrolling rates to give a parallax effect but again, time restraints. In retrospect it’d be really easy to do, but we didn’t have the time.

The 10-second tracks. They’re great, I just wish there were more of them. In a 20 or 30 round game, you’re guaranteed to hear a lot of repeats.

Clarity. We thought it would be interesting to make the upgrades a “learn what they do post-acquisition” thing, which worked great for the most part, but there’s a decent amount of depth to it and a lot of subtle things going on in the background that I don’t expect anyone to know about unless they read the Sourceshimi. Also, the “Press X(B) to go back” style of displaying controls is probably confusing. (B) meant B on the XBox360 controller (the brackets are like, ROUND BUTTON) but I doubt that was clear.

Overall Impressions

Definitely my best Ludum Dare, and I’m sure my teammates agree. Learned a lot, FINISHED A GAME (though we’re still doing post-jam content updates), felt really good about my code, and delighted to see it so well-received that people are writing articles about it. This has been a hell of a learning experience, and an even heller of a motivational drive to keep doing that thing I love doing.

Making games.

(And…scene)

In case my game left you confused and frustrated but still curious, I have added a little video guide.

Also, some technical fixes have been made in the meantime.

Check it out.

Where I got the Idea from:

Mainly I got the Idea from my self after waking up at around 5:30 AM to brainstorm some Ideas. I then Got up at 7:45 to have breakfast and Set up the enviroment. I got the Princess From Mario. The Gameplay from Minicraft(Made by Notch, He made Minecraft!).

Things that went Well:

I managed Time effectively and to the best I could.
Code as it Was well Commented and easy to understand for other programmers.

Things that Sucked….Badly…

Graphics(Completely sucked in many ways…)
Sound… Sounded “Scratchy…” if you know what I mean.

Thanks to all the people for there awesome comments… 😛 thanks for the things I needed to improve on and the things I did well I hope you all enjoyed ludum dare have a great day!!!! 😛 😛 😛

That was One hell of a Ludum hey guys!!!

😛

-James

We’ve added a walk-through video to our entry, as a few of you were getting stuck with puzzles in StepOut. And here’s a gif byproduct of the video.

And if you haven’t yet…

go and play StepOut

Hello guys!

We’re glad to say that we’re now on Google Play with both Precious10 and Precious10 Unleashed (the version we did during postmortem phase).

Precious10 on Google Play

Precious10 Unleashed on Google Play

Regards,

Victor

Hi LD,

Since some people were confused about how to play my game Adventure Company, I did a video gameplay of myself playing and explaining what is going on.

Hope you like it!

~Mark

http://www.ludumdare.com/compo/ludum-dare-27/?action=preview&uid=27070

Our team did it, we finished our first game in time, unfortunatelly the control are really messed up, mainly because of the collision system we created, and the flash events that didn’t worked as we expected them to work =/

Developing for this Jam was really fun, mainly because our team had a lot of fun while developing the game and the traps.

The result was not as we expected, but here is what we learned:

• Next time, we will choose the framework a few days earlier than the Jam.
• Next time we will develop the game in a framework that we’ve already worked before (Really important! Lol)
• Less Facebook, more coding/drawing.
• Pizza party!

You can see the game here. Play and have some fun

http://www.ludumdare.com/compo/ludum-dare-27/?action=preview&uid=27070

Thanks!!

PS: Heeey

We also recorded a video winning the game, because some of our friend said it was impossible.

Watch only after playing, ok?

Here it is: http://www.youtube.com/watch?v=pcyh6fuYcHY

PLAY THE GAME HERE (Thanks!)

Hey all,
this was our 6th Ludum Dare. We almost did not make it this time. Not because we run out of time but because we said that we would not enter this time around due to some other commitments from the team members. However I (Dals) could not stand that our stream would break for a silly thing so I decided to make a small but simple game. We last all Saturday because of this but we actually had time to put like 6-7 hours into a small game in the end. On the sunday I was joined by my friend who helped out with the programming and gameplay.

What went right:

We knew that we had lost a whole day and because of that we made sure that we aimed on a game with a scope so small that we would finish it relativly fast. We stuck to this and that was very important for the success for this project.

Another thing that went right was the use of tools. We were not able to get togheter this time around so Skype and git really saved a lot of problems for us. Git is super great when you learn to use it and this time we really knew how to. We also used Java as a programming language wich we are most comfortable in. The new thing for this Ludum Dare was that we used the awesome LibGDX framework as the backbone of our project. In the weeks before Ludum Dare I had explored GDX and made a small API for it called Simple. That made the development of this small game even faster and it was blazingly fun.

Basically we knew our tech and made clear and structured goals. We also did not have time to suffer from feature creep which was great in the sense that we finished it.

What went wrong:

Apart from not being able to join in from the beginning almost nothing went wrong.
So well all that went wrong was that we did not have time to attend the whole event.

Conclusion:

Ludum Dare is a great way to make games and give out to your creativity. I was very happy with theme 10 seconds, as soon as I saw it in the last round I basically knew that it would win. I had lots of ideas for it but when it turned out that we were not able to attend the whole event I scrapt all of them but when I got a little time to spare I sat down and made the most simple game that come to my mind.

This time around we did not have so much time but we actually made a game anyway. Maybe our most polished and complete game as of what it is. We are proud of what we did and we are already looking forward to the next Ludum Dare when we can join in for the full event.

Cheers guys,
~Dals with team!

DalsGames was this time around:
-David ‘Dals’ Skeppstedt
-Andreas Brommund

PLAY THE GAME HERE (Thanks!)

Tags: dalsgames, jam, LD27, Space-Time

I saw that several people have made “post-mortem” summarizes about LD#27, so I also so it. I’m not the kind of person who follow others like sheeps, but community engagement is surely important – even though no one writes comments. 😀

The beginning

Theme was announced at 3:00 A.M. here. It’s kinda late. I took a smaller break before. When I returned I started checking #ld48 tagline on Twitter instantly – since IRC was a complete chaos for me.

Theme is “10 seconds”. Okay! I started planning and making some basic things immediately. Concept was ready for 3:30 A.M., then I started listening to the great Simcity 4 OST to get inspiration.

I stayed up all night, drawing and coding a bit. First issue: I couldn’t implement procedural “island” generating that would have been significantly important. Okay then, I started implementing a simplier procedural generation. That works but way too ugly.

Then I realised that adding enemies who are moving pixel by pixels are harder than I expected. Then I also realised that they should use projectiles, which would be another nightmare to do. It’s 11:00 A.M. and I’m helluva tired.

The born of Hackfield

Going to sleep for a while. Woke up at 2:00 P.M., and felt myself full of energy! Yeah, I don’t consume much energy – yeah, I’m kinda passive and lazy. Anyway, one hour was enough for me to realise that I’m unable to finish the original plan. Went back to Twitter and pass the time away. Then, I enlightened! Simple game mechanics, based on hacking! I created 9 tiles immediately – it took less than 15 minutes and these tiles mean the whole playground.

Concept was created kinda early, so I started designing tile behaviours almost immediately! Procedural map generation was also kinda easy, but you may even notice it in the same, since it’s not a big stuff.

Main elements of HUD were also made around this time. Everything about behaviour were finished before 4:00 A.M. (the 25th hour of the competition) with some additional bugs and improper level generating.

The final 14

Woke of around 11:00 A.M. on the second day. Yeah, I slept a bit more. I fixed the behaviour of dynamic firewall, created the starting sequence, and created some bsic texts for the main menu. Until afternoon, I created the level generations tested all of them (except sclevel6, that is proven to be annoyingly hard and time-consuming since) for the last 8 hours, I had to create all the texts in the game, the behaviour of the main menu, the ending, and adding sounds.

And that’s where thing have really became a pain in the ass.

 Boredom & deadline

For midnight, I was ready with every texts and HUD elements in the game. Drawing elements that don’t look silly but also don’t take hours to create was a kinda annoying challange. You know, I get that we have only 48 hours, but it doesn’t mean that everywhere should we use Arial font, thrown to the edge of the playground! At least I think, and even Hackfield was made with this philosophy. Writing the story was a different problem. I loved imagining the whole thing, including history, received e-mails and Hackfield Daily articles – but after writing all of them (including the tutorial) my short-term brain cells were totally depleted. It makes me a bit stressful while that, which was proven to be critical after midnight.

When I was finished with everything, and I added intro triggering again, I realised that intro is triggered each time when you leave a level. Nothing, and by this, I mean NOTHING solved this problem. I was there at 2:00 A.M., one hour before the deadline with a game that has no sound effects, and constantly triggers its intro sequence.

For a final solution, I added a new timechecker variable, that was proven to be a right solution, but acts like a bulletproff metal plate connected by bubblegums on an armoured tank. (I fixed it after the deadline anyway) Finally, I added sounds and checked everything  could – with this fact, I was finished at 2:30 A.M. Then I created the .exe from the .love file, but sadly, I screwed it up 2 times. Because I’m dumb.

Fortunately, I could post the game at 2:45 A.M. with links, pics and the description. Small graphical- and bugfix was posted once since.

Overall

The game was created under ~26 hours, but it includes Facebooking, Twittering, etc. Pure coding would be around 20 hours, as I estimate. I was kinda slow, but I also proud of myself since I’ve never done game with so simple gameplay mechanics.

Including the random computer name generator (which is kinda silly, with combinations like “Gas station supercomputer”), source code of Hackfield is 222+24+281+122+294+696=1639 lines long, including embarraing amount of enters and empty lines to make it easier to read. Longest file is the one that contains ending sequnce, intro sequence, menu behaviour and all the displayed texts. Shortest one (after Lua config file) is the name generator, which contains 3 tables of possible words in the name. If they’d have been separated to a custom file, the name generating function may have been put to main.lua.

I got critics for:

– 1280×1024 fullscreen mode that didn’t work properly on some computers
– the not obvious tutorial and consequently the not obvious gameplay
– logblocks which behaviour is not clear
– the tiles which are too similar and hard to notice certain elements between them (it was kinda fixed)
– the difficulty of security level 6
(- I’m surprised that no one mentioned the weird name generator combos yet)

These critics were significant mostly for gameplay issues, and I learnt from them.

After all, I can say proudly that making Hackfield was a great experience! As I mentioned, I’m seriously proud of the final result and that I could participate to one of the biggest game making jams in the world!

Katamori

Tags: post-mortem

Count2Ten is a simple party game for 1 up to 6 players. The goal is to get the best estimate possible about how long do 10 second last.

Each player presses a key and keep it pressed until he/she believes ten seconds have passed. The player with the best guess wins.

While you are waiting for the ten seconds to pass, some distracting sounds are played (a broken metronome for instance).

As there is no game if players look at a watch or other supporting gizmos, they all swear that they won’t use it.

I just received a screenshot from a player of what it looks like as a major high score: 10.081 secs, better than I ever did in playtesting using a watch

Anti-Grav Drive is a game about flying a half-broken spaceship through a planetary system and trying to survive as long as possible. Your thrusters are down and your only method of influencing your movement is through a cobbled-together, overclocked anti-gravity drive which you can turn on and off at will. Along with the long range scanners and a ten-second prediction routine, you aim to slingshot the ship around the planetoids and keep on truckin’.

What went well

My main criteria for the game was that I’d be able to make it in “about 2 hours” and spend the rest of the time polishing. These two hours only really included the basic gameplay, but it meant that I had plenty of room for error and improvement. It ended up taking longer than 2 hours (perhaps 3 or 4), but this meant that I pretty much had something that I could submit very early on, should something disastrous happen.

What didn’t go so well

I over-obsessed on the visuals during the second day. In fact, half of the second day was spent on visuals that never made it to the final product. The green-on-black space horror sci-fi computer look was a fall-back option that I ended up defaulting to.

Overall, my time management was pretty atrocious too. While I had a working prototype after only a few hours, these few hours were after I’d been sitting in the pub all evening. Most of the first day was spent chillin’ out, maxin’, relaxin’ all cool. I think I was quite lucky that I could pull together the music and the game balancing during the last hours of the competition.

Lessons learned

Get it working. Gameplay is the most important part of a game (certainly for the games I like to make). Although I did get a prototype working quickly, I think spending even longer on getting the progression and balancing working from the off could be beneficial.

Set time limits. It’s pretty easy to write down some numbers for the things Wot Your Game Needs. If I’d done this and was half-way through the allotted time for visuals without anything usable, maybe I could’ve stopped myself earlier and had more time for audio and balancing. Adding up a total number of hours also might’ve motivated me to work more during the first day to spread the load.

Don’t worry about it! Yeah, I was pretty chilled throughout the competition. Even though I criticised myself for this and maybe I just got lucky with the idea, I think it came out pretty well without too much stress.

Tags: post-mortem, postmortem

Alright, so my entry, Chrono Escape, is about a scientist kidnapped by the government, and has to escape using his time machine prototype.

You can play it HERE.

The Bad

I’m starting with the things that went badly, and I’ll begin with the big one.

Programming.

The programming is an absolute mess. I used GameMaker8.1, which isn’t fast to begin with, but I also use horrible lazy and inefficient programming practices to create the elements I didn’t know how to make.

For example; the lighting system. For that, I used a while loop to determine the distance from you to the block directly in front of your mouse. Next, repeat this 7 more times for the blocks at angles -20, -15, -10, -5, 5, 10, 15, and 20. Each while loop takes a relatively large amount of CPU, so it’s no wonder that the game lags so badly with 3+ people with lighting on screen. After doing this, it draws triangles between all the points given, then subtracts them from the black square drawn over the entire screen.

But wait; there’s more. Besides being horribly inefficient, the lighting was also inaccurate.
It was only accurate up to 5 degrees, and became very dicey at far distances. Now, to calculate if the guard sees you, it does the same calculating as above, with 8 while loops. And if he’s far enough away, you can still technically be in his site, but he still won’t see you because you “fell between the lines”

Cutscenes

I did all the cutscenes in the last hour of work, and they were, in a word, bad.

I mean, they convey a story well enough, but they don’t really fit with the rest of the graphics, they’re sloppily drawn, and they’re inconsistent between each other.

I really could have done them better, but I don’t see how in that time frame.

The Alright…

Music

The game’s music was an ambient track I recorded live off my keyboard in one take. That is, by far, the easiest way for me to get music, but the ambient style didn’t really mesh with the high-strung style of the game. I wish I’d had enough time to make a proper techno track that really would have done the game justice.

Level Design

I feel the early levels were very good, actually. It seems like I did a good job of guiding beginnings through the first steps under a controlled, yet extremely hard, environment. However, if a player is good enough to get past the first 10 levels or so, they might begin to notice a slow change. After I’m finished introducing the player to everything, my level designs became more and more hacky. I’d just throw a level together, test it to make sure it was possible, then throw it in the game. I’m also disappointed because I don’t think I did the concept justice in terms of complex, paradox based levels that are so clever that you’re astounded for minutes after you beat it.

The Good

Concept

Seriously, this is one of the best concepts I’ve ever come up with in my 7 years as a game designer. It’s really deep with clever puzzles, elements, boss fights, and a whole lot of other wonderful things. I might well continue the game afterwards just because it’s so damn fun to work on.

Graphics

Again, some of the best pixel art I’ve ever made. I think this is one of the first times someone’s ever complimented my graphics, without referring to it as an “interesting” style or somesuch.

So there you have it. My own, overly critical, opinion. I hope I do well in this LD, but I’m not sure I made the game for it.

Ah well. Just don’t forget to play the game HERE!

This was my first time to participate in Ludum Dare and I’ve enjoyed it way more than I thought possible.

Firstly, the experience of making a game was in itself a lot more fun than I’d anticipated. I’ve only worked on games as a writer in the past so getting stuck into the coding and art as well was a daunting task. But I found it really satisfying to have complete control over the game’s direction, even if it quickly headed off on something of a tangent…

My first inspiration was the title (taken from the film ‘Gone in 60 Seconds’) and my  initial plan was to do something of a straight car-theft simulation with the player viewing the dashboard from inside the car and clicking on various elements to steal it. However, I was never entirely sold on this. For one thing, I just don’t like the idea of glamourising car-theft. For another thing, the idea of a ‘master car-thief’ is inherently ridiculous. So after I had a dream in which Nicolas Cage, reprising his role from the film just for me, jumped in through the sun-roof of a car, I knew what I had to do. The result was a much more whimsical and story-based game with a willful disregard for the realities of automotive crime:

Gone in 10 Seconds

I had no idea how it was going to be received but I’ve been really pleased with the feedback so far, especially concerning the dialogue. I’ve even had some nice comments about the C64 styled art. In all, very encouraging!

I’ve also found the process of rating other peoples’ games to be very useful. Just considering and verbalising what makes a game work (or not work)  for me as a player gives me a much clearer idea of what I should be thinking about when making my own games. I’m resolving from now on to give much fuller feedback in comments when I rate games, breaking down exactly what I did and didn’t like about the experience. Hopefully this will be useful for everyone involved.

Finally, a shout out to the game which has most impressed me so far: Bomb Disposer. This one blew me away (pun intended). It has great atmosphere and a really wonderful mechanic which makes the story an integral part of the game. I think that with a few extra gameplay elements and perhaps a more complex system for randomly generating sentences, it could be turned into an awesome full game along the same lines as ‘Papers, Please.’