This has been my first LD ever, and I have to say that it’s been quite a satisfying experience, from which I’ve learned some interesting lessons. To tell the truth, I wasn’t sure that I would end up submitting an entry at all, so I didn’t take it seriously enough and devoted less hours than I would’ve liked to, but still, I am proud that I applied in the end.

What went right

Having a clear objective.

I already had some ideas for games based on evolution, so once the theme was announced I only had to choose between two different approaches to develop it from a common core concept: an evolving ecosystem. Thus, that core concept was always in the horizon, which helped me not to ramble too much.

Focus on simple goals.

Rather than getting lost in architecture details, that frequently lead to a dead end (well, at least that tends to happen to me), I split the steps to reach that goal into small, simple tasks, so that I could iterate quickly and had new things to show (not necessarily in a visual sense) all the time. The feeling of accomplishment is really rewarding, and pushes you further towards the next goal.

What went wrong

Language choice.

I really like programming in C++, and I’m always eager to keep learning and improving at it, so I take advantage of every opportunity that allows me to do that. However, and despite what I previously said about the feeling of successfully reaching some minor milestones, the main objective of the Ludum Dare is to develop a game in a really short time. This means that we should be smart enough to choose wisely the language, tools,etc, that will allow us to optimize that time and, especially, reach a larger number of people.

To code a full game from scratch in 48 hours (well, in fact I would say the actual time devoted to it would be more or less one third of it) using C++ is probably much less time efficient than the other alternatives I’d considered (AS3, Pygame), even if I had the feeling that I was spitting out features at a relatively high speed. Yeah, it is more powerful but, being realistic, a game intended to be finished in less than two days will not probably require that much.

And then, of course, there is the issue of distributing your game.

I only did a Windows release, so that leaves Linux and Mac users out of the equation (even though a port to Linux could be more or less immediate, but I don’t have any distro installed on my laptop). What’s more, even for Windows the probability of errors or crashes due to missing DLLs, incorrect build executables, etc., to appear is relatively high, which puts an additional barrier to your public. To top it all, since I finished quite late, I couldn’t playtest it with friends or family, so I could only trust my computer.

This led to some chaos on Monday, where the initial build submitted was using a debug executable and crashed in several machines, or there were strange frame rate drop issues (about the frame rate, I realized that the main loop implementation I chose left to be desired, too…but the disparity spotted in one case was unreasonable). I submitted a fixed build, but there are still some crash reports.

So, the conclusions are: First, think carefully about what you want to achieve: is it learning? Ok, but then don’t complain if you spend twice or thrice the time and can’t have so many things done; Is it developing a fun game? Then use something that allows you to have a fun game FAST. Is it a mix of both? (Yeah, I’m stubborn) Well, in that case, FFS, USE SOME CODE BASE. A basic game core, functionality for rendering text (which isn’t trivial using SDL_ttf plus OpenGL as I did), sprite drawing, sound, UI components…all of these can really help reducing the time spent developing low-level stuff, leaving you more time to make the game fun and cool-looking, which is what matters.

Second, if your application artifacts are platform-specific, test it, test it and test it once again in as many different computers as possible. And, if you’re making a multiplatform game, test it, test it and test it in as many different platforms, browsers and devices as possible.

Lack of overall focus

This may sound as if it contradicts one of the epigraphs in the “What went right” section, but in reality they’re two different things… Here I mean that my commitment to start coding wasn’t 100%. I would wake up in the morning and debate between overall procrastinating, playing something or developing the game, and when I realised I’d wasted several hours. Yeah, once I launched Visual Studio and started typing I’d enter the “flow state” and I could spend hours coding non-stop, but all that time lost was invaluable. Of course, the final result has resented.

Gameplay? What gameplay?

Being a gameplay programmer myself, this is probably my main grip.

Since I’m interested in genetic algorithms and evolution, I focused too much in having a simulation running with mutations, crossing and selection of the fittest. Once I had that, I would then give the player the ability to interact with the world and give them some challenges. However, on Sunday morning and during most of the afternoon I barely did anything until a couple of hours before the deadline, which means I ran out of time to put on the actual “game”. I just threw a couple of unbalanced or just plain useless actions to alter things such as reproduction rates or…let’s call it “non-organic food”.

A player would have a toolbox or options to give advantages/disadvantages to the survival of creatures. The goal of a level would be to get to a given number of specimens fulfilling a set of traits in a set number of generations. Since she can’t choose the traits directly, all she  has in her hands is the power toolbox. Thus, she might raise a plague affecting…let’s say “mostly blue” creatures. Or perhaps provoking a flood. In addition to cooldowns, using those powers would use some amount of an undetermined resource.

Another really basic feature that I regret that I couldn’t implement was AI. I don’t mean flocking behaviours or anything like that (at least in the beginning ^_^), but simply giving preys the ability to detect and flee from predators, and make these able to chase them would have been a really interesting thing to do.

In the end, creatures were left with a really limited set of genes: speed, the way they got the energy, how they reproduced, their starting life…and not too much. I regret not having put things such as “sight”, “locomotion”, or “personality”, for example.

Some other, more advanced features that I had in mind included a somewhat hostile environment, and some resource management aside from the living creatures interacting with each other. This would have opened the door to new creature traits (flying creatures, amphibious, temperature…the possibilities are endless), and new ways for the players to alter the world conditions and make thing easier to increase or decrease the odds for the creatures to survive.

As you can see, the whole concept can become too complex really easily, and you have to constrain yourself to something doable in 48 hours. A noob’s mistake =_=

 No polish at all

Again, as a consequence of the lack of time, I couldn’t go past the primitive-based procedural shapes and put something nicer instead (actually, procedural wouldn’t have been that terrible if I could have done something similar to Dawkins’ biomorphs). Some sound or music could have been nice, too.

 Ø——————- Ø——————-Ø——————-Ø——————-Ø

TL;DR: For the next time, I’ll try to start small, with a clear, complete idea. Then, iterate over it, getting incremental, but working and testable functionality, and commit to the jam 100%. Also, I should favour web deployable solutions over C++ unless I had a minimum set of libraries to save some time and focus on gameplay. Last, think of the childr…eeer, of the public (meaning: test it if possible in more than one machine, and try to port it to Unix-based systems it it’s not a web release)

Still thinking about joining. The theme will be a decisive factor, so I’ll try to brainstorm a bit with the final voting list.

Tools:
– If I’m feeling particularly bold, I might use Unity/C#. As that’s unlikely, I’ll probably stick with AS3 + Starling using Flashdevelop, and reuse the core classes from my previous entry, Conquer all the castles!
– Photoshop and, depending on the game, perhaps Tiled and Texturepacker
– sfxr, probably, for sound effects. I’m still undecided about music, though.

The dungeon:

Woke up to check the theme (which happened to be the one I’d thought less about…sigh), and after thinking about the possibilities (graphics, gameplay,…), I may have found an  idea for a puzzle game. This is a quick concept:

…which is more than heavily inspired by a Google Images search that led me to a work by a minimalist painter (incidentally, my primary school books had this as their logo).

Frank Stella, Gran Cairo

I think the idea can work fine by itself, but I have in mind some twists that can add depth to the game concept if I have enough time.

Well, at last I have the basic functionality done.

Yup, it’s a match-3 :D

Short, watermarked video beyond the link

There still might exist some bugs in the match calculations, but I’m having trouble to catch them and they’re rare enough, so I’ll try to sort them out later.

I think that if I submitted it right now it would be 100% fitting with the theme both aesthetically and in terms of gameplay, which is what I was more interested in. Still, I would like to expand a bit more on it, so these are my next steps, after a late lunch:
– Additional visual cues, to make the available options clear.
– Sound.
– Gameplay enhancements (making it time-based, allowing to sacrifice some time to discard a plate of blocks, levels, …).
– Game screens.
– Some more stuff.

I’m still considering my original idea for the theme, which is to take a simple, possibly well known game concept, bloat it with superfluous elements (unnecessary visuals or sounds, metagame/non-social features that no one cares about and detract from the game experience,…) and as the player progresses through the game, strip it from everything non-essential until she gets to the most basic core of the game  (I would use “purest”, but that would make me look pedantic :D).

I’m using HTML to embed the SWF with my game, and I would like to edit it to drop a couple of lines to add  a simple paragraph with the controls. It’s not part of the game per se, but it may affect the perception of the players about it, so I’m not sure if that’s OK or if it would invalidate my submission. I’ve checked the rules and there’s nothing stated in one way or the other.

Does anyone have any idea?

On a related note, would the same apply to “readme” files?

Link to the entry

The theme reveal will find me on a train travelling back home throughout the whole night, so I guess that I’ll use that time for design or (gasp) sleeping.

Tools:

• Language: AS3.
• IDE: FlashDevelop
• Additional libraries: Starling. Depending on the game needs and time, add to the mix the Particles extension  or Box2D.
• Starting codebase: Some utility classes for scrollable maps, animations,…plus the basic application layout, mostly reused from my previous Flash-based entries. (Sources here)
• Art: Photoshop, Flash.
• Sound: bfxr, and I’ve been learning OpenMPT, so I might give it a try if I have the time.

Below follows a first screenshot of my game (still unnamed…Paparazzi Express, perhaps?):

It will basically consist of taking pictures (no surprises here 😀 )

It took me some time before I started coding as I wanted to have some not-too-temporary art (I expect to review it tomorrow, hopefully).
So far, I’ve managed to create the first classes, implement the camera scrolling (I hope to review it as well), and some minimal HUD functionality.

After this, I’ll focus on the picture capture functionality. However, I guess I’ll spend some time defining and refining tasks, to prioritize features and see what I can attain in the remaining time.

Submission complete! Play it behind the click!

I’m reasonably happy this time. I managed to finish the core functionality despite a somewhat “eventful” weekend, but there were many things left behind (features, bugs, sound,…). I’ll probably write a more detailed post-mortem tomorrow.

Good luck to everyone!

After a well-deserved rest, it’s time for the post-mortem of my fourth LD entry, 10s Paparazzi.

I was travelling back home on Friday night when I learned about the chosen theme. I’d been brainstorming a bit with the final list, and for “ten seconds” my main ideas revolved around choice-fate (resulting in more or less convoluted/pretentious concepts such as “your life could change in 10s”, “10s to meet/lose your soulmate”, etc) in addition to more straight approaches (i.e, “you have to do X in 10 seconds”).

After translating some of these concepts into gameplay, I ended up with four main candidates:

• A shooter with waves of enemies appearing every 10s.
• A tower defense with waves appearing every 10s.
• A dungeon crawler, mixing elements of FTL and The Binding of Isaac, where you had 10s to fulfill whatever was required of a dungeon room, and then would have to pick an exit with no possibility to backtrack. I even had a title for it: “No time to explore!” (an obvious reference to the game “No Time to Explain”). I really liked this idea, but sounded as if it could go out of hand quickly.
• Last, a glimpse of the landscape through the window gave me the idea.  A game where you had to scroll through the scene and take a picture of something (rather than hit him as in a Whack-a-Mole game)  seemed approachable, and there were several compelling mechanics that could work fine with it. As you may imagine by now, we had a winner here.

What went right

• Reusing the codebase from previous entries. The less time you devote on setting the application, defining game states and the basic engine functionality, the more you can use to polish, balance and create assets.
• Simple concept. You can just pick the game from scratch and start playing immediately. Unlike my previous entry, where I made the mistake of not providing enough feedback or instructions to get the hang of the game quickly, the controls were intuitive enough for all players to know what they’re doing.
• Backlog. I decided to create an exhaustive list of tasks to help me track my work, plan and prioritize. These are skills I’m working hard to improve (I think that I’ve become better with each Ludum Dare :D), and keeping the backlog updated turned out invaluable. Also, there’s the dopamine shot when you begin to see large areas of green ^_^
• Potential to further develop it.

What went wrong

• Missing features: The opposite to the “dopamine shot” previously mentioned was to see in the backlog how many tasks you still needed to do. While I managed to finish the highest priority ones, there were still lots more, which could have helped immensely with the game experience. Some examples are:

• Better character behaviours
• Camera “skills”: The idea was that some objectives required a bit more than  just “have this little fellow photographed”. For example, we could have a more complex “take a picture of a smiling red ventolin with a blue one next to him”, and to achieve that we might have some “freeze” or “move” skills to manipulate the scene.
• Livelier environments
• Multi-layered scenes, with parallax.
• Photo gallery
• Secondary objectives
• Sound and music
• Etc, etc

• A series of unfortunate events: As I’ve said, I ran out of time for features, testing and polishing. I could blame my poor planning skills, but this time I ran into a couple of handicaps in real life that made me waste some hours, too. First, as I said, I was travelling by train. It was supposed to arrive in Barcelona at 9:00, but due to some forest fire in the northwest, it arrived with a delay of almost three hours. Secondly…I had lots (I’ve counted around 50 between legs and arms) of mosquito bites which seemed almost cured by Friday, but then started to itch again like crazy and swelled insanely the next day, reaching the point that I was starting to feel pain and/or numbness in some areas (this freaked me out). They still look pretty terrible today, but it’s nothing compared to Sunday, when I had to leave my desk 4 hours before the deadline to find an emergency centre, covered with large patches of burning red skin. >_<
• Dat scroll bug. I wasted several hours trying to smooth the camera movement. I improved it a bit, but introduced new bugs, some of them resulting in nasty camera shakes. As I’d got stuck and still had some high-priority tasks, I decided to start working on those first, think about something else and then go back later to polish the scroll. This, sadly, never happened.
• Character art: Most backgrounds look quite nice in my opinion, but I can’t say the same of the characters. I’d hoped that I could add more animations, and give different appearances to each creature, rather than just changing colours, but once again time had its way.
• Way too easy: The first screen is meant as a tutorial, so the creature appears close to the camera to teach the player. As for the other ones, the implemented behaviours were insufficient to pose any challenge, so the game can be completed in less than a minute.

In the end, I’m left with a bittersweet feeling. The game looks nice and shows promise but the compo version is way too simple. Still, I’ve learned a lot, as it’s been the case with my previous entries. As always, I love the experience! 😀

Tags: LD27, postmortem

I’ll join the compo this time, too. The theme reveal will probably find me coming back from my company’s Christmas supper, which means a surge of enhanced creativity just before going to bed (and a potential hangover on Saturday morning) 😀

I’m still undecided about the language/engine to use. I would like to use Unity2D + C# this time, but I may end up using Actionscript 3 again, I guess it’ll depend on the theme and my own mood, of course. In the latter case I’ll probably reuse the starting codebase from my previous entry (Sources here). Other than that, for graphics and sound I’ll resort to the usual suspects:

• Art: Photoshop, possibly TexturePacker.
• Sound: bfxr, Audacity, and if I manage to add music this time, I guess that OpenMPT will join the team as well.

PS: Pleasepleaseplease, NOT Bieber! If I have to sacrifice The Hobbit’s opening weekend, it should be for a better theme than that!

Tags: LD28

Just one more turn (please!) – Postmortem

I’m back to life again, so it only feels appropriate to write a postmortem. Just one more turn (please!) is my fifth LD game, and this has probably been the one that I’ve had a hardest time with so far, to the point that I considered quitting in some occasions.

Play and rate it here!

The game came to be after I failed shaping some fun mechanics (or even plot) for the main idea I had been thinking about: something abstract about choices in life and how you only get one chance for each of them. As I was getting stuck I decided to throw it to the rubbish bin and come up with a better idea. I ruled out another one partially inspired by Battle Royale and the random weapon that is assigned to each of the students, too. Luckily, memories of games such as Civilization, Heroes of Might and Magic, X-Com or Fire Emblem came to the rescue, and together with the theme I managed to combine both things to create a turn-based strategy game where each unit only had one turn (which actually makes the game a bit more of a puzzle). It sounded feasible, it sounded interesting, and it had potential to be fun. How did it turn out, then?

What went wrong

• Physical/Mental exhaustion: I came home late at night after a Christmas party with the people from work (and before that I’d been exercising, too), and I woke up on Saturday after 4 hours of sleep, hangover and really tired. This is definitely not the best situation to work , and as time piled up it only got worse: now put into the mix some unrelated personal issues and obsessions of mine, together with my perception of how development was progressing, and the final result was not one nor two but three panic attacks throughout Sunday. By the third one the pot was boiling and I seriously thought that I should leave it there. I have some anxiety-related issues (AvPD, to be specific), but panic is almost news for me, so I was feeling worn out from both the long hours and all that other crap, even a bit scared and quite demotivated, all of which had a very negative impact in the game end result.
• No Planning: On the last LD I decided to keep a detailed backlog of features to do, which really helped define priorities and keep things on focus. This time I had nothing like that, just some scribbles on a notebook, and then I would work in whatever I would feel like at the moment. I paid for it.
• Insufficient gameplay: Lots of features related to the core gameplay were only partially designed (for example, how would the turn play out, if enemies should counter, if all the ally units should move before the enemies, if the player and AI would alternate,…), and many more (unit stats,  more unit types,… the list is way too long)  got left out because of lack of time. Also, the number of levels is really short and easy, but I didn’t have time to do much more.
• Lackluster graphics: While I like the character designs (if few, and with only one simple animation), and the backgrounds on their own aren’t completely terrible, they don’t really blend with each other, so the result is quite subpar.
• Sound: I’d hoped to compose some music this time, choose or create some fitting sounds and help with polish to help with immersion. In the end I just used Autotracker and randomly clicked for a couple of minutes on Bfxr. :/

What went right

• Submitted: Despite all the problems, and even though I’m not particularly happy with the results (I can’t thank @Zener enough for putting up with all my whining via chat), I managed to submit a more or less defined game. The fact that I didn’t just give up makes me a bit prouder of myself.
• Unity3D: This is the first game I’ve coded on Unity (besides a 2.5D prototype I’d done at work some months ago), and I’m really glad with it. It’s very usable and lets you build content and functionality really fast. As a counterpart it takes some control away from you (which is somewhat important for me as a programmer), but for this project I didn’t actually need that much.
• Idea: Again, the final result is not exactly what I had in mind, but the idea has potential. I would like to  try to think a bit more about it and then extend it.
• Despite what I mentioned on the first point on the “What went wrong” list, the moments when I managed to get in the “zone” coding helped me get distracted from everything else. I tend to see programming  as puzzles waiting to be solved, and that “game” aspect of it is one of the reasons why I love it.

I’ll probably join the compo again this time. An artist friend of mine was interested as well, so we might go for a jam entry in the end if she’s finally in the mood.

I’m still undecided about the tech, and it’ll probably remain that way until the last moment. If I can devote some time to research, that will help on the final choice.

For now, Actionscript 3 and Unity 4.3 sit at the top of my ranking as the most likely options (I’ve already submitted entries using them after all), but I’m really curious about Haxe-OpenFL. C++ is also an option (I wanted to maybe try Cocos2D-x, SFML or SDL 2), but since it’s slightly harder to distribute the game across several platforms (specially web) it has a lower priority.

Other than that, I suppose that the remaining tools will be the usual:

• Art: Photoshop, Texture packer, Inkscape?
• Audio: Bfxr, audacity.
• Music: I’d like to finally make some music myself. If I manage to gather the time to do so, then I guess the main candidate would be OpenMPT. Famitracker is also around.
• Level editing (if needed): Tiled

LD#48 has finally finished and, as usual, I’m happy to have submitted and a bit sad that it’s over. This time, for a change, I’m mostly satisfied with the end result compared to my previous entries, which probably explains that I still haven’t gone to bed even though in 5 hours I’ll be bumping my head against my desk at work.

Play Playbuck!

The sexy lad next to me is Trompin, the real Playbuck

A week has passed, I’m more or less rested and it’s time for the customary wall of text some people call it postmortem.

During the week before the theme announcement I like to prepare for it by making a little brainstorming. Most of the time the final idea has absolutely nothing to do with any of the concepts, and this was no exception, but it’s still fun and you never know if THE BIG IDEA is just around the corner waiting to be found. This edition the concept of the game itself changed from the initial design to the final implementation as I was running out of time to implement the mechanic.

While discarding roots, submarines and caves as I feared everyone would use variations of this, I took a look at Trompin, my pet rabbit. Half joking with a friend it hit me that I could do a game dealing with rabbits, burrows and the likes. And mating.

You can play and rate Playbuck here

I then thought of a Metroidvania game borrowing the concept of generations from Rogue Legacy: you would get to an available partner (buck or doe, you wouldn’t be tied to a gender), mate and then pick one of your children as the new main character. It would carry around the parent’s skills plus one more, and replace it as the main character. To make this work well, I would have needed a lot longer to focus on level design, rabbit skills and craft a balanced experience.

With this in mind, at some point during Sunday the mating mechanic became a goal in itself. Since gameplay was pretty bland at the moment and the clock was ticking I thought it would add a somewhat original silly touch. It’s a bit too silly for my taste, but everybody enjoys a fart joke here and there, so hey…

What went well

• Planning. Last time I almost screwed the submission for a number of reasons, one of them was poor planning. This time I managed to determine what should I focus on pretty quick and, most important, stick to that and handle changes with common sense.
• Haxe/Flixel.  I’ve done quite a bit of AS3 coding, but Haxe was a first, and I’d never used Flixel either. I’ve been gladly surprised at the almost flat learning curve from switching to Haxe + OpenFL, and how many built-in functionality already comes with Flixel. I like to experiment a bit with technology from time to time and I think this time I’ve found something really interesting 😀
• Music! This is the first edition where I can create some music (I used autotracker for LD28, but I think it doesn’t count. Also, I didn’t like the result at all), and although short and repetitive in the long term, it was a funny little tune to listen for 30s.
• Rabbits! I’m not the one to judge, but still I believe the rabbit visuals turned out pretty well. Yes, there aren’t too many frames per animation (and some of them shamelessly reuse  frames from other animation states, in fact), and yes, the does are just reskins of the main character. My focus is on programming and art assets for me always take up quite a bit of time (and don’t look particularly good), but amazingly enough I managed to draw some cool sprites in a manageable time frame. I probably had a nice model

  
  Sketches for rabbit actions

  

  …and here’s the original

What went wrong

• Change of objective. As I explained before, this is not per se a bad thing, but the game became a different thing, much simpler both in terms of gameplay and “concept” than what I had in mind.
• Music! Yeah, even though this time I’ve managed to get music in the game, it tends to get a bit irritating, as the melody is pretty short and it gets repetitive soon. I guess it’s not too bad for a first try. At some point I’d like to take advantage of my keyboard and use something a bit more complex, but Famitracker seems like a reasonable program to start.
• Lack of visual feedback and eye candy. Hearts, dust clouds…I ran out of time to add some visual effects that would have enhanced the appearance of the game and probably give some clues. Next time, I suppose.
• Collisions/Sh*tty digging controls. They’re not terrible, at least, but as gameplay is pretty simple both should have been smoother, specially the digging controls. I wanted it took some time since the point when you start pressing the key and when a tile of dirt is actually removed, but I messed it when I thought about how it should behave.
• A couple of issues with map loading. Even though Haxeflixel had an addon to support Tiled maps there were some things that I couldn’t manage to map well into the game. Next time I think I’ll probably code my own parser class (I can probably reuse some code from Conquer all the castles!), but despite this it saved me a lot of time.

Overall, this time I’m quite happy with the overall result, but as always there are lots of room for improvement.

I’m a bit of a lone wolf, so I’ll take part in the compo as always

Since the theme voting started I’ve been brainstorming possible game concepts and how they can blend with the currently revealed theme candidates. This time I would like to make a somewhat narrative driven game, but I must come up with some fitting mechanics first (of course, considering the time limit and theme constraints). Also, I should start toying around with sprites to learn how to be more efficient at creating content.

As for the development tools:

• Graphics: Photoshop, Aseprite, TexturePacker.
• Map creation: Tiled, possibly. It will depend on the implementation language.
• Audio: Probably Bosca Ceoil or Famitracker for music, then some good old friends for effects and editing: Bfxr and Audacity.
• Coding: I sort of fell in love with Haxe the last entry, so that’s my first candidate at the moment, using OpenFL and probably Flixel as well. The final decision is not set in stone, and I’ve also been experimenting these days with Unity and Cocos 2dx, so I can change my mind eventually (even Actionscript3 could be an option). The IDE will be FlashDevelop in that case.
• Moral support: Pet.

I couldn’t submit anything last LD30 due to technical issues at home, so now it’s time for revenge! (Well, technically it’s time to go and get some sleep before the theme announcement, but you get the point)

My development choices:
* Unity + Visual Studio or Haxe/Haxeflixel for code. I’m still undecided on this, and  the choice will probably be taken once I know what kind of game I’ll make.
* Art: Photoshop almost for sure, then Aseprite or maybe even Inkscape.
* Audio: Bfxr and Bosca Ceoil  are likely candidates, with some Audacity magic here and there.
* Dwarf rabbit for moral support.

Good luck to everyone and, most important, have fun!

Play and/or rate here

I was forced to skip LD30, unable to focus after finding out that my router and my laptop’s power source had both broke down (I had a spare power source, but the internet outage freaked me out), so I was really looking forward for this edition. The theme this time…well, it wasn’t one of my favourites, but I find it interesting how said “bad” themes usually help me think outside the box. I’ll try to talk about this with more detail in the postmortem.

This time I couldn’t get animations, music or a decent set of levels, but I’m quite happy with the amount of work I got done and the potential the game concept can have. And now…time to get some sleep! Good luck everyone, and congratulations to all participants!

Play (and rate) it here!

Incep…I mean conception phase

On Friday evening I started brainstorming for the possible themes, paying some special attention to the now forgotten ☃. I wasn’t particularly keen on it, but judging from people’s reactions on the internet there was a high probability of it being selected. It also felt  particularly appropriate, as by the time I was scribbling possible game concepts I was freezing in the cold waiting for a gig.

I regret nothing!

That hour and a half yielded red fingers and around 3 notebook pages of quick and more or less bizarre thoughts, references and ideas. “Entire game…”, as you can see, didn’t get too much love back then (In case you’re curious, I’d just written  something like “taking advantage of the UI elements as parts of the gameplay”).

Flash forward to Saturday morning. At that point I learn about the chosen theme, curse for around 30s and put my mind to work. While it wasn’t among my favourites by a league, I generally don’t make a big drama about the theme as I can’t fully understand it (the drama) either. I’ve read many complaints about it not being a real theme but a technical constraint, too restrictive, too generic, etc, etc. Even though some of these can be valid points, to me they don’t carry enough weight as to get angry over it. In fact, I feel that restrictions more often than not enhance creativity rather than hinder it, as they force you to get out of your comfort zone, think in a different way and try out unknown routes that can end up in interesting, original takes (as a proof, I’ve already played several today. I’m amazed at what people can accomplish). In this specific case I thought that the theme might work in several ways: as a technical restriction (no scrolling, no separate levels,…) or as…well, a theme (surveillance,…). Waves of stuff coming at you (a reverse beat ‘em up, for instance), monitoring some action through a display, shooting ranges, fighting, multiple levels crammed into a single view, puzzle games or single-screen arcade games, etc, etc… All of them seemed like some viable approaches. At some point I seriously even considered to make a TV broadcast programming simulator, but luckily discarded it when I realised that it would probably go way out of scope. In the end I decided to follow the arcade approach and started looking for references.

A couple of screenshots of good old Arabian, some helpful advice and references from Zener pointing me in the right direction, and thus the main concept for Dungeon of Jest was born: A single-screen platformer with a single level where sections of it change as you progress around the game, giving the impression that the dungeon is trolling our hero, giving her a more difficult time.

Arabian and King’s Valley 2

What went right

• Level design on paper first. Other times I’ve focused on building the systems first and then building some crappy, nonsensical maps at the end, which just doesn’t work. This time I tried the other way around, and while the game can still use A LOT more level design work in terms of progression, pacing and more levels (obviously!) having paper designs helped me focus on what I needed done, and create a more fun experience than in previous editions.
• Well-defined scope. Following from the references and the layouts for the levels, the scope of what I had to do became a lot clearer and easier to achieve. I had to give up lots of polish-related stuff (tweaking gameplay, better assets, animations, visual effects, music, better audio…), but most of the core experience made it to the game.
• Dynamic level transformation. Implementing the section changes was easier than I expected. I kept separate level files, and then computed lists of changes in tiles and entities to move from one to the next. I could have made it more general (it could be interesting for a hypothetical future), but the first implementation worked well enough for the compo scope.
• Last-minute dialogue text. Since the beginning I had wanted to make the character speak when key events happened to provide a bit of humour, guidance and context to the narrative (well, the game has no narrative at all, but it was in the backlog), but I left that for the final stretch. Luckily I could add it and I think that it was worth it.
• Language/Library choice: This is the second game I build on Haxeflixel, and I’m very happy with it. It frees you from a lot of the groundwork and building for several targets is absurdly easy. This time I even managed to build an Html5 version.
• Knowledge from past games.

What could have gone better

• Knowledge from past games. Wait, what? Wasn’t this on the “good“ side? Well, yes. However, even if I mentioned that I applied some of the ideas learned in previous editions, the lack of a code base made me reinvent the wheel in some areas that I shouldn’t have had to. Entity and map management was the main example, especially since I used the exact same technology (Haxeflixel + Tiled) from the last game. D’oh!!
• Belated technology choice. I wasn’t sure if I would use Unity or Haxe until I had most of the design work done, and I think that gave me a late start.
• Lack of levels and gameplay polish. 3 levels are just too few and several people have already told me so. What’s worse, it is detrimental to the whole “What the…? The dungeon changed again!” feeling I wanted to convey.
  A better idea given the time constraints would have probably been to define a smaller level layout (with 25×20 there were lots of empty space) and create more of them.
• Lack of visual/sound polish. I’ve estimated that I worked on the game about 30h, of which I prioritized basic gameplay over production values (which take me longer to create that I’d like to). This becomes evident on the lackluster graphics, no music, animations or any visual effect, plus the crappy sounds (added in the last half hour before submission). This area is definitely something that I need to, and want to improve in the future.
• No narrative. The “take the orb to win” goal is simple, but void of any context. I wanted to have some background story and have it reflected in the gameplay, but that would’ve forced me to devote more time to asset creation (GOTO previous epigraph). Again, this is something I want to tackle in future games.

Conclusion and ideas for the future

I came out pretty happy with the game this time, even though there are lots of room for improvement. To everything that I’ve already mentioned there are lots of things that could make DoJ more interesting (or bloat it :D). For example, just to name a few:

• More “levels”, obviously. I’ve said this already, but I can’t stress enough how vital this would be.
• Having more than one “orb” at a single time, each of them triggering different section changes, for enhanced depth and all-new level design balancing headaches.
• Procedural generation <3
• More classic platforming features: Traps, puzzles, swings…you name it!
• More enemies and more complex AI
• More work on existing gameplay elements: better jumps, ladder docking…
• Final bosses and new gameplay mechanics incorporated as you progress around the game, a la Castlevania.

I don’t know if I’ll make a post-compo version with some of these changes (I always say that I will and then don’t do anything, so I’m not going to fool myself this time), but for the next time I definitely hope to at least come better prepared in terms of code (have the language choice clear from the start, ffs!), and become faster (and better!) at asset creation. Well, and probably synthesize a bit more on the postmortem. If you’ve managed to read all the way until here, thank you!

Tags: haXe, HaXeFlixel, postmortem

Weather is really nice these days around here, so what better way to celebrate than shutting myself at home for two days of game making? 😀

I’m undecided about the language/development tools. I’m torn between two options (and “luckily” I haven’t had enough time to become comfortable with UE4 for 2D).

If I go with Haxeflixel (+FlashDevelop), I’ll probably use a small framework I built on top that relies on the loader from flixel-addons. You can find the source code for the tiny framework here: https://github.com/wildrabbit/wildrabbit_ld

In case I go with Unity 5 (+Visual Studio), depending on the game I might use some C# scripts I’ve done as part of a (work in progress) library I want to make to support tile maps. I haven’t had the time to put all the stuff together, so for now I’m just providing the source as a *.7z file. I apologise in advance for the lack of documentation and general mess, the scripts actually belong to two separate projects, and I’m basically sharing them now to comply with the compo rules, I can’ even guarantee that it’s functional without assets or a proper test scene. Get it here: https://db.tt/fSSO0StL

One of the two archives contained inside has functionality to load a *.tmx map and converts it to a custom Unity-native format -but it doesn’t build a map yet- plus some simpler, older logic to load that same map format file and build a mesh composed of textured quads for a map layer, and the other one has some code to render a tile map using a single quad plus some editor functionality, but the main intention for the editor tool when I started it was to generate a path finding grid, so both things are more or less independent. A last note: the TMX reader relies on Unity.IO.Compression (https://github.com/Hitcents/Unity.IO.Compression) to parse data compressed in gzip or zlib formats. If you are going to encode your tile layers as CSV or pure XML element lists you can comment the code and go without the additional library.

For art I’ll probably go with Photoshop and/or Graphics Gale, plus TexturePacker to build sprite sheets, and on the sound side, I’ll rely on Bfxr for sound effects and Audacity for additional editing. I’d like to make some music with Famitracker or Bosca Ceoil, but that’ll depend a lot on the time.

And depending on the game needs I will use Tiled as a level editor.

Good luck to everyone!

Tags: LD #32

 
I’m sorry about the crappy video quality, I’ve been fighting for a while with OBS, and for the time being I’ve given up, as this is a early semi-playable build.

The video shows a WebGL build of my game, still untitled (Something in the line of “Words >> Cybernetic fists”, perhaps). The foundations for gameplay are finally shaping up, but I still have to add a couple more features before I start working on art and visual feedback (where the connections with the theme will become clear).
If I manage to have all that when I go to bed tonight, hopefully tomorrow I’ll have enough time for further polish, level design, narrative, sound and music…and more features. Stealth! Dialogues! C&C!!! (No way, but can’t a girl dream?? *_*)

Tags: ld32