About Ithildin


Ludum Dare 37
Ludum Dare 35
Ludum Dare 34
Ludum Dare 33
Ludum Dare 32
Ludum Dare 31
Ludum Dare 29
Ludum Dare 28
Ludum Dare 27
Ludum Dare 26
Ludum Dare 25
Ludum Dare 24

Ithildin's Trophies

Ithildin's Archive

End of day 1

Posted by
Saturday, April 18th, 2015 9:59 pm


Not bad for the first day, I guess. The image shows more or less the high-level status of the game so far (I’ve blurred a bit some entries as they might be considered a bit “spoilerish”). To tell the truth, I hoped to get more  done in the art field, but I decided to spend some time implementing a somewhat complex localization system (I’m using insults as the player’s main skill, and Spanish is gloriously rich in that respect, so I felt that I needed to support both languages). If I managed to wake up early enough and finish with a couple of features I hope to spend most of the day generating content.

Here’s a (slightly better than the last one) video showing the more recent progress. Lots of programmer art and awful lightning and effects for now, you’ve been warned :)

Progress so far

Posted by
Saturday, April 18th, 2015 2:43 pm

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?? *_*)

In I am

Posted by
Friday, April 17th, 2015 2:07 pm

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!


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!


Posted by
Sunday, December 7th, 2014 7:37 pm



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! :)

Hopefully in

Posted by
Friday, December 5th, 2014 4:56 pm

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! :)

Counting the days (I’m in!)

Posted by
Monday, August 18th, 2014 3:16 pm

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.

Playbuck – The postmortem nobody was expecting

Posted by
Sunday, May 4th, 2014 10:06 am

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.

Submitted! :)

Posted by
Sunday, April 27th, 2014 6:57 pm

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

Day 1 finished.

Posted by
Saturday, April 26th, 2014 8:50 pm

I’m reasonably satisfied with the progress so far.

Haxe + flixel + Tiled has proven a very powerful combination, despite some minor gripes regarding flip statuses and data formats in the parsers.

At the moment I have a very basic tileset (I hope to improve it tomorrow, but there are lots of stuff to do), an even more basic gameplay, an idle animation and some sort of an end condition. Incredibly empty and generic for now but tomorrow I’ll try to bring it to life and implement a couple of mechanics.


Rabbit burrow

Rabbit burrow


I’m also pretty happy with the main character sprite. Maybe it’s because I’ve had a wonderful model.


Casual rabbit

Casual rabbit

And this is it for today. Good luck to everyone!

I’m in (I hope)!

Posted by
Tuesday, April 22nd, 2014 4:10 pm

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

Just one more turn (please!) – Postmortem

Posted by
Tuesday, December 17th, 2013 8:16 am

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.

Screen Shot 2013-12-17 at 3.44.02 PM

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.

You have my sword!

Posted by
Tuesday, December 10th, 2013 7:26 am

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!

10s Paparazzi: Postmortem

Posted by
Monday, August 26th, 2013 7:28 pm

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! 😀


So it ends…

Posted by
Sunday, August 25th, 2013 6:53 pm

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! :)

So it begins…

Posted by
Saturday, August 24th, 2013 11:12 am

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.

[cache: storing page]