About Ithildin

Entries

 
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

Ye auld “I’m in” post

Posted by
Friday, April 21st, 2017 7:41 pm

Been waiting till the last minute to write the post as I didn’t know if I would do it here or on the new site.

Anyway… I’m in (of course!). A wisdom tooth’s killing me tonight, so I might end up using it as a source of inspiration together with the theme 😀

I’ll be going solo as always, and Unity and Haxeflixel are once again the most likely candidates for tech. Then for the rest the usual suspects: Photoshop, Trello, Aseprite, Audacity…

Hope you all have a great time this weekend!

Post-mortem: Roach Escape

Posted by
Sunday, December 18th, 2016 9:58 am

A week has passed and here’s the post-mortem, before this coming week and all the holiday preparations. I want to thank everyone who has played the game so far and given me feedback. I’ve started working on a post-compo version that will hopefully fix some of the issues that most people have reported, and will expand the content with new levels and elements.

screen_00

Play it and rate it here!

Roach Escape is a puzzle game inspired by games like Lemmings, Chu Chu Rocket and the Santa Fe ant trail problem, where you need to take your character (in this case, a cockroach) to the goal. By itself, Roachie can only go straight or turn right when it bumps agains a wall, so it can’t get to the goal on its own. By placing items on the grid you can help it find the way.

And that’s it, in a nutshell.

How it all came to be:

Well, you know how it goes. You wake up on Saturday morning, take a look a the theme, possibly start cursing at the choice (or not) and then you spend some time coming up with ideas, pick one and start working. And that’s what I did, essentially. Except that I had two, and both ran in parallel as I was designing for a loong time.

Roach Escape, early mockup - Back then it was "Kitty escape"

Roach Escape, early mockup – Back then it was “Kitty escape”

In case you’re curious, the other game would have been an odd hybrid between a card game and a decorator sim. I had been thinking of Reigns for the cards part as a first approach to the cards part and then moving to a different mechanic that could involve multiplayer, so there would be a balance between randomness and rewards. I really liked the idea, but after describing the concept to friends and family I decided that it would be too content heavy before it became a fun prototype, as opposed to the more proven “build a path to escape” concept. Another reason why I was reluctant at first to what would become Roach Escape was that I knew for sure (although I couldn’t remember the name at the beginning -_-), that there was a clear reference that I’d played years ago, so it might not feel too original. The game, as I would finally recall hours later, was Chu Chu Rocket.

Good

  • Relatively solid: The submitted version was relatively bug free. Granted that gameplay was quite simple and straightforward, but I still think it turned out okay.
  • Decent emergency art style: I had in mind to rehash most, if not all of the game assets to make it more fitting with the theme, but due to the lack of time I and had to compromise with quick improvements on the original placeholders. Luckily, they didn’t look bad IMHO.
  • Lots of potential: As I’ve kept iterating during the jam and outside it I’ve come up with lots of ideas, from world elements (switches, teleporters,…) to objectives to provide variety to the gameplay and make the player tackle a level in different ways. Also, some friends of mine IRL have made several suggestions about potential new features that can also be interesting.

Bad:

  • Indecision. I think one of the worst mistakes I made this time was to take too long before I started coding. As I said before, I had two ideas and I admit that I kind of preferred the decorator one. However, as the concept sounded riskier I went with this. I don’t regret the choice, but still I lost several hours trying to decide, and even after that I had a slow start because I wasn’t completely focused.
  • Flawed first-time user experience. The game has different states, but it basically comes down to two: the edition mode and the playback mode. From this one you could either pause the game or lose/win when you finish, and you can return to the edition mode pretty much anytime you want. This setup sounds easy enough and it is, but it wasn’t clearly communicated at all on the game. As a result, some people including myself at times would click on a tools and get no visible response because they weren’t aware that they were outside the edition mode. This is one of the first things I’m going to fix.
  • Reducing the walls width: Originally the walls were thicker than on their current incarnation. This implied that either the player was drawn above the walls (and that didn’t only make no sens, but also looked ugly), or that it was below and appear partially covered. Also, because of the way I’d packed and read the sprites originally, and due to the way I calculating collisions, reducing the player sprite size wasn’t an option, so I chose to make walls thinner. The result? Many people have trouble seeing them, and they’re right.
  • Usual Haxeflixel amnesia. The last few weeks before the Ludum Dare up until a couple of days before the theme announcement I had been coding on Unity for a personal project, and on C++ with Cocos2dx at work, which means I was already juggling between both of them. Then I chose to throw a third one into the pot and use Haxeflixel for the game because I’ve become mostly comfortable with it for LD, and it makes super easy deploying builds for a variety of targets. However, I tend to go for months without using it, which means that every time I pick it up again I need context switch, not only in terms of language, but also in the way all those engines and libraries handle coordinate systems or scene entity hierarchies.Because of this, my first two-three hours of coding work I’m generally like this until my brain starts digging for past knowledge and I enter the proper “Haxe is cool! Everything is easy again!” mode

Thanks to this, the last hours are generally a breeze because it provides a lot of functionality out of the box(or there are lots of addons available) and because it makes painless things such as integrating audio or hacking a quick and dirty but functional UI screen.

  • No music, superbasic sound. Yup, lack of time :/
  • Post-submission caffeine high I can get anxious for any stupid reason easily enough by myself, so I tend to stay away from caffeine except for tea drowned in milk and sugar. That means I’m quite sensitive to sharp increases on my intake, as I haven’t built any tolerance. During the last weekend, though, I had about a couple of cups of coffee (not too black, but still), a couple of energy drinks and a half a litre bottle of cola. The result? Pretty much I went to bed on Sunday night and started tripping balls.

    Graphic depiction (Now seriously, feeling my mind race like a crazy horse even though it was exhausted was kind of unpleasant)

And of course, going to work the next day was a nightmare.

Ugly:

  • Loose connection to the theme. As I mentioned, the emergency art style did the trick of not looking too awful, but that came at the expense of having a game that doesn’t really feel related to One Room. My intention was that each of the levels represented a room (the easiest, laziest kind of connection), but also reinforce that through the graphics. However, that wasn’t possible in the end.
  • Too short. At the moment there are only 5 levels. People haven’t complained about the amount, or the difficulty progression too much, but I still think that the design itself wasn’t particularly good either. I felt like I needed a lot more levels, and that they should show more effort.

Here are some screenshots of some mockups I’ve been sketching for the post-compo version. I’ve just started implementing them today and fixing some other stuff, which means that I’ve broken the game. However, I expect that soon I’ll be able to demonstrate the improvements.

02_mockup_post_compo_landscape_editv2 03_mockup_post_compo_landscape_play 04_mockup_post_compo_landscape_paused 05_mockup_post_compo_landscape_won

Enter Roach Escape

Posted by
Tuesday, December 13th, 2016 6:46 pm

I finally managed to get some sleep last night (Note to future me: always take the Monday after a Ludum Dare off), so before I write the postmortem and consider working on a post-compo version, here’s a shameless plug for Roach Escape, my submission for LD37.


Play it and rate it here!

Play it and rate it here!

 

As many people have reported difficulties understanding the first steps, I’m also going to share a Youtube link to a a playthrough of the first level to help clarify the first steps:

One room, two game ideas, two mockups

Posted by
Saturday, December 10th, 2016 10:39 am

I’ve spent the morning and early afternoon coming up with ideas and so far these two seem to have sticked around. Please take into account that the screenshots below correspond to super rough mockups built from external images only to have a clear picture of how to represent interaction and things like that (I used the tiles from http://opengameart.org/content/simple-duotone-tileset for the first one, plus some quick hue shift)

The first one will be a puzzle game where you need to alter the room to lead the character to the goal (and avoid potential traps)
First idea: build a path to help the character reach the goal

And for the second one you will play the role of an interior decorator. Your customers will arrive with certain demands (and, potentially, a limited budget) and you’ll have to satisfy them the best possible way (and maximise your profit to increase your pool of available furniture). The trick is that you won’t be free to choose any particular piece of furniture. On any turn you’ll be given two cards from your starting deck and you’ll need to choose one of them (heavily inspired by Reigns). Once you’ve placed the piece of furniture inside the room you get to decide if you want to keep rolling for a chance of increased rewards/score (or losing the client because the room is left in an inconsistent state) or to deliver the room in its current state.

mock_idea2

 

So now the problem is…which one to choose?

I’m in! :D

Posted by
Friday, December 9th, 2016 4:17 pm

If everything goes well this will be my 12th submission. I was out on a trip last August and couldn’t enter the compo, so I’m back with a vengeance :)

Toolset:

  • Tech: I’m undecided as always, so it’ll depend on the game idea I come up with. Guess I’ll probably stick to Haxe+Flixel, or Unity/C#.  I’ve spent some time toying around with Game Maker as well, but with the time limit I believe I still need more practice until I can take proper advantage of it instead of fighting it to bend it to my rigid programmer-oriented mindset. I’m also curious about HTML5 development and would have liked to practice a bit with Phaser, but at this point that’s a super risky choice.
  • Art: GraphicsGale or Aseprite + Photoshop + Inkscape + Texture Packer.
  • Audio: [Labchirp|Bfxr|Jfxr] for sound creation,  [Bosca Ceoil | BeepBox.co | Caustic 3] for music and Audacity for general-purpose editing.
  • Level editing (if necessary): Tiled, probably.
  • Planning: Trello. I’m not sure if it would be interesting to track the time I spend on each area (or procrastinating), in which case I can give procrastitracker a try.
  • And, of course, good ‘ol pen & paper.

Good luck to everyone!

Getting schwi…eeer…shifty – Postmortem

Posted by
Tuesday, April 19th, 2016 7:31 pm

ld35_03

Play it and rate it here! :)

This was a peculiar weekend and, as always, very fun and rewarding. After spending most of Friday on a train which arrived with an hour and a half delay due to most unfortunate reasons, I overslept and had a late start on Saturday. Then, even if I had a clear idea of what I wanted, I ran into some early problems because I’d forgotten about some really basic stuff related to the way Flixel handles positions. Luckily I managed to overcome all that and the end result this time has been more than satisfactory.

The idea came relatively easily. My first inspiration was Altered Beast, but that would have probably been overkill in terms of asset creation, so I discarded that and went for another classical genre with very clear references. Back on LD30 I had wanted to make a shoot-em-up where the “ship” actions in one world would affect interconnected ones, but unfortunately I run into some technical problems and couldn’t participate in the end. Ever since I’ve been wanting to resurrect that project or implement something similar, and the opportunity presented itself this time.

 

(From left to right, Ikaruga, Waves and Geometry Wars)

My references were immediate, too: the main one would be Ikaruga and its colour switching mechanic as key, but I also checked other two shmups I’ve always liked: Geometry wars and Waves. The connection to the theme is obvious (switch shapes for fun, profit and devastation), and decided to go full abstract/geometric instead of my original approach, where you would be some kind of a microscopic drone with Transformer-like abilities and your task would be to defeat viruses and bacteria. It’s a good way to achieve some pleasant visuals without having to spend a lot drawing.

What went well:

  • Controls. Having gameplay just feel right were a must, and this time I think I more or less made it :) I would have liked to add some acceleration to motion and so on, but making that feel right could have been tricky and time consuming, so I aimed for the basics first (orientating the sprites and aiming in particular).
  • Scope: By resorting to a well known genre with simple yet effective mechanics I managed to keep the game scope under control. Of course there are lots of things that didn’t make it, but the current result feels complete.
  • Development speed: As a consequence of the previous bullet point, having a restricted and clear scope and feature set I managed to keep a constant and fast development pace. That’s a huge bonus for motivation.
  • Visuals and effects: At the moment the game is getting some nice comments (thanks!) about the graphic style. They can still be improved, but it is true that they can make a huge impact on the perception of the game.

Now, the ugly:

  • Slightly chaotic process: I wanted to make up for the late start, so I just started coding as soon as I pinned down the basics of the game and completely forgot about planning for several hours on Saturday evening, when I finally decided to create my usual Trello board to keep the tasks and my progress controlled. This wasn’t bad per se, but I also made a risky gamble with version control, and I completely neglected it until it was actually time to submit. Then I created and pushed the sources to Github. I was very lucky, as I didn’t run into any problems or had to roll any feature back, but the next time I should at least be more careful with that just in case.
  • Not directly related to the competition or the game, but…THAT ARTICLE (you probably know what I’m talking about, I’m not going to give it any more publicity). I read it while on the supper break and got incredibly angry.

…and what went wrong:

  • Music and unbalanced volume, and glitchy mute option. The thing I regret the most on this edition is, no doubt, the music. I wanted to make some fast-paced tune with a psychedelic vibe, but I got stuck and, when I realised that there was only one or two hours left before the deadline, I chose to leave music as I had it and moved to UI coding. I need to practice a lot more on composing the game music. Besides, the effects volume was irregular, and muting them was glitchy.
  • Difficulty progression (or lack thereof): The game can feel very hard to some people, but for those who do master it, it gets monotonous. The truth is there was no difficulty balance at all. I managed to hack a “hard mode” in the last ten minutes before the deadline for those who managed to play for more than three minutes, but that’s still not enough. Another option would have been to have more things to do, but of course that would have been more time consuming. At the moment this is probably my main goal for the post-compo version.
  • Remembering Flixel: I hadn’t touched Haxe+Flixel since the last LD, and I regretted that this week. First I had decided to upgrade the pipeline to the last version. This wasn’t particularly problematic during the Ludum itself, but I had some old projects I wanted to check for references and they broke. Additionally, I always forget how anchors, pivots and positioning work on Flixel until I’ve spent a while re-checking it.
  • Performance, esp. HTML5: I wanted to release the main build as HTML5, but it wasn’t consistently performant. At the moment you can experience hiccups on any platformer when you shoot many ships or use the blaster, but playing on Firefox or Edge was veeery slow most of the time compared to Chrome, for instance. Interestingly enough, on another project I’m currently working on on Unity, the WebGL build runs into memory issues on Chrome but not on Firefox or Edge.

Next steps:

I’ve already made some changes to a Post-Compo version (you can also find it on the submission page), but I want to add many other features that couldn’t make it into the main submission. This is a list with some of the most important ones.

  • Different control schemes and gamepad support – DONE
  • Difficulty and player progression – STARTED, still a lot left to do.
  • Decent music, and fix that darned mute.
  • More content: Bullet patterns, enemy types and behaviours, pick ups,…
  • Better movement.
  • Better visual feedback: Put the previous/next hints right on the ship, clearer indications of when you increase your score multiplier or when the blaster becomes available.
  • Better graphics: This fits more as polish, but I would like to change the graphics for almost all elements of the game, make the lines of the ships clearer, replace some UI texts with icons or bars and perhaps add some nice and trippy background effects (like in the video below, but waaay more subtle). And many more particles! ;P
  • Better performance. Of course, to support all that and not burn people’s computers I need to optimize a lot, starting as soon as possible, as I already had some problems in certain moments of gameplay.
  • Tracking scores/times locally on a save file or, even better, keep an online leaderboard system somewhere.

Submitted!

Posted by
Sunday, April 17th, 2016 11:39 pm

ld35_02
Play it and rate it here


I spent around 30h working on the game and in hindsight I think that I could have really used a few of those other hours to improve the audio and, more importantly, finish/redo the music track.
Except for that, (and even then I still think it’s better to have something audible…as long as you can also mute it), I’m quite happy with the end result: Enemies aren’t so terrible as in past entries (there’s still room for improvement) and I’ve improved a bit at adding visual feedback.

If I give a few more hours tomorrow for a post-compo I might add gamepad support, debug that stupid mute glitch (I’m not sure if it’s due to Haxeflixel itself or if, more likely, it’s on this side of the computer), and create a decent music track. Of course, my TODO list on Trello has several interesting gameplay ideas and improvements that could be worth to check in order to expand the game, but I may leave that for a postmortem.

Well done and good luck to everyone! I’ve already seen some very interesting entries 😀

‘Course I’m in!

Posted by
Friday, April 15th, 2016 5:49 pm

I’ll probably be taking part in the 48h category, as usual.

Not too many changes in the toolset compared to my previous entries:

  • Complimentary pen, paper and brains (slightly worn down, but brains nonetheless)
  • Language/IDE: Haxe + flixel on FlashDevelop or C#/Unity. I’ve been checking pico-8 and it seems very promising and intuitive, but I’d rather use something I’m more used to.
  • GraphicsGale/Aseprite + Photoshop for graphics, potentially using TexturePacker to create atlases.
  • Labchirp  + Bfxr + Audacity for sounds/sound editing.
  • Either Bosca Ceoil or Caustic 3 for music.
  • (Optional) Tiled, for tile-based level authoring.
  • Trello/Google Docs for keeping track of tasks.

    Good luck to everyone!

Fun with post mortems!

Posted by
Friday, December 25th, 2015 7:34 am

It’s been more than a week now since LD34 finished, and finally I have some free time to write the post mortem for my compo entry, “Fun with magnets!”

When I learned about the themes this time I didn’t give much thought to the idea of creating a game that used both of them. For “growing”, I’d mostly considered farming or greedy corporations expanding out of control ideas, which were risky because of the potential to be out of scope for two days, and incorporating the two button-based mechanics would have been challenging.
Attraction/repulsion mechanics, on the other hand, had crossed my mind during the pre-ludum brainstorming I do before the theme announcement to prepare, and I felt that mixing the idea with the two button controls had some potential and was feasible. In hindsight, there are easy ways to incorporate “growing” there as well, but I preferred to go for a simpler approach instead.

I’ve seen lots of awesome entries this time (seriously, this LD34 has an insane proportion of cool games!) proving me wrong about mixing both, but I’m satisfied enough with my entry for once to not regret it.

If you decide to stop reading here, have a merry Christmas/Winter Solstice/Whatever rocks your boat! ;DD

Play it and rate it here

What went right

  • Tight idea. Sticking to a clear idea and vision this time helped me a lot towards having a more or less complete “vertical slice” of a game.
  • Reasonably adjusted level design: One of my key objectives this time was to close core feature coding soon enough so that I had time to define some semi-decent level design. This time I think I managed to do that to some degree.
  • Colour palette: I went for a set colour theme from the start and I believe the game graphics really benefited from it, as it gave the whole game a more consistent look (more on that later)
  • Haxeflixel: This is my third LD entry where I’ve used the Haxe+Flixel combo and it’s nice to notice how you become more familiar with it. Even if I experienced some hiccups at the beginning flipping the Unity switch, it’s easy and powerful to use. This time I’m particularly happy with some experimentation I did with Haxe abstracts, enums and anonymous types for level loading, which is something I’d attempted some time ago on my free time for another project with little success.
  • Web version was functional on Android! A more than welcome side effect of having used HaxeFlixel was that I saw the game working perfectly on Chrome on my Nexus and other devices. In fact, controlling the game through the visual controls “feels” better there (some thresholds aside) than using the mouse.

What went wrong

  • Haxeflixel. Even if I was familiar, it had been some time since the last time and I had to fight a bit at the beginning with the basic cinematic physics support it provides. Once I solved that, my overall experience with it went back to the “What went right” category.
  • Confusing control scheme. Initially I experimented with the idea of being able to switch the movement direction as well by cycling in a similar way to the magnets, but that resulted in a clusterf*ck to control, so I capped it so that the only way to change direction was to bump against a border. Still a bit tricky, but an improvement over the initial iteration. Also, controlling in multi-touch devices or with the keyboard only is more or less simple, but on a PC you can also add some mouse to the mix. Last, I think that there are some issues with swipe detection, specially on mobile devices, which make controlling through the visual wheel not fully responsive.
  • Glitchy attraction mechanics. Even if it’s functional, the magnet behaviour is far from perfect. I need to adjust the thresholds and angles to make it more responsive than it currently is.
  • Graphics. The set colour theme helps disguise this a lot, but as I was creating art assets when I needed them, each of them was drawn using a different style, so the final result leaves a bit to be desired.
  • Neglected audio. As always, audio is left for the final hours, which is probably a mistake, as it can help a lot in terms of feedback and immersion. In this case my main concern was that I left the music track half-done to keep adding the final touches.
  • Very simple levels. There are 9 levels in the game, which can be considered as a tutorial for something larger, because the goals are really easy. The only challenge at the moment that goes beyond the glitchy mechanics resides on the wheel in the last level, and even if you can consider it as a “To be continued
” sort of cliffhanger, it really makes no sense if you consider the compo entry as a full game.

Next steps

This time I’d like to keep working on a post-compo version (but I always say the same and then I don’t, so take this with a grain of salt), for which I’d need to apply all the things I’ve learned on this edition:

  • Fix all the things!
  • Improve controls and restrict control schemes. I’ve had some really good feedback about ways to make the controls better, and at first I’d thought about completely scraping the two button restriction and turning to a lever-like system for a post-compo version, but perhaps it’s interesting to keep it and evolve it instead.
  • Make all the levels! Either levels need to be more complex or I need to make (a lot) more of it. Also, I had several ideas for additional elements that didn’t make it into the game and could be interesting to make it more fun and difficult.
  • Improve graphics. I need to make all the assets a lot more cohesive in terms of drawing style and shading. Also, visual effects.
  • Improve sound.
  • Dedicated mobile port. Instead of taking advantage of the web version, deploy a native Android one.

 

Submitted!

Posted by
Sunday, December 13th, 2015 10:12 pm

This was a productive weekend, even if there are still lots of things that I would tweak or add. I’ll leave the details for the post-mortem, but I’m quite happy with the result, I can actually play the web version on my phone! I know this sounds really stupid, but I was surprised at how well it worked considering that I wasn’t thinking of mobile platforms at all

Behold “Fun with magnets!”
ld34_main

Day 2 starts

Posted by
Sunday, December 13th, 2015 4:53 am

This is my progress as of yesterday, when I went to bed (yes, I’m awful playing):

Today will be devoted to content: removing placeholder art, even if I’ve grown attached to those pokeballs, and defining levels. Also, I’ll probably perform some more experiments and tweaks to the controls. I’ve realised that, while keyboard controls work fine (and I hope that the same applies to gamepad), mouse-only is unfeasible. However, multitouch is also a possibility, and the game is actually playable on Android, so depending on the time I might even build for that target platform. We’ll see how it goes.

Good luck to everyone! :)

I’m in! :D

Posted by
Friday, December 11th, 2015 6:28 pm

Mandatory “I’m in” before candidate themes brainstorming and even more mandatory bedtime.

Goals for this LD: 
1: Less is more. Aim at something simpler and feasible.
2: Don’t look at the game through programmer lenses. Having a cool experience for players is more important here than code structure, architecture and whatnot.
3: Make a fun game and, of course, have fun making it.

Tools of the trade:
TECH: Either Haxe+[OpenFL|Flixel|]+FlashDevelop, or Unity5/C# + Visual Studio. Unlikely candidates: Game Maker, Pygame. Just in case, here’s the link to some old setup code built on top of Haxeflixel, plus some tilemap experiments that I’d done for Unity. Find them here.

Special guests:
ART: [GraphicsGale|Photoshop|Inkscape] + Texture Packer.
AUDIO: Bfxr + Audacity + [Famitracker |Bosca Ceoil] for sound and music.
LEVELS: Tiled for level editing depending on the game needs and the coding choice I end up making.
PLANNING: Trello for bookkeeping.

Good luck to everyone!

I’m still recovering from the stretch (plus two work days), but I felt the need to start writing the postmortem.

Play it here!

 

When the theme came out I was ambivalent. On the one hand, it was very similar to You are the Villain from LD25, if I’m correct. On the other, that was a very cool concept. This meant that most of the game ideas that were suitable back then would fit in here as well, with some interesting additional connotations due to the change from “villain” to “monster”. I decided to go with an ambitious idea that would tie game mechanics AND the game’s narrative AND the jam theme. Now that the jam’s finished, I consider it a failed attempt, but still I’m happy with the lessons learned for future games or a hypothetical post-jam version (I would really like to try to make this work, but from past experiences I’m afraid that it’s not likely to happen. Procrastination is strong in this one, and I have recently started coding a small roguelike during my free time). To avoid spoilers, I’ll split the post mortem in two halves. Skip the second half until after giving the game one try or two, please.

 

 

What went right

  • The idea was pretty solid from the start, driving the whole development process forward.
  • Faster, better art than in previous entries. I’m not experienced at all at pixel art, and the last times I tried it it took me a lot of time. This time I changed the approach and went for a more natural drawing style. I’m way more comfortable with it, so I’m way faster and I even think that it turns out better, but I’m not one to judge.
  • Basic gameplay slowwwwly getting better with new entries. Still not good enough, though.
  • Familiarity with the engine (Unity) and tools.
  • Interestingly, the music. Several people have praised it, which I found surprising because I made it in the very last few minutes before the submission period started. I did try to make something that fit the mood, but it’s a very simple repeating pattern with some small variations to give it a sense of progression. Still, I’m very glad that people like it. Thank you!
  • Take advantage of disadvantages. Just an example: due to the way enemies flock together (not a bug per se, but not correct either) I decided to enable the “piercing” switch on weapons. That gave the player the ability to target multiple enemies at once, which feels a lot more rewarding (and useful). Sometimes, specially on such tight schedules, it’s best to come up with different approaches to a problem instead of trying to make the proper fix. Of course, this doesn’t apply in all situations.


What went wrong

  • An alternative title to this post-mortem might very well be: “The excess of ambition produces incomplete games”.
  • Shitty, incomplete AI behaviours. It didn’t help that I approached the implementation of character behaviour by replicating a lot of code, which eventually began to cause problems and I decided to refactor that as soon as I woke up on Sunday. That refactor made me lose 5h of Sunday morning that I should have used to create and fix existing behaviours for AI-controlled characters (so some NPCs could run away from enemies, others might turn hostile, etc). I also wanted to define different “personality” types so that not all enemies or NPCs reacted in the same ways to events, but…no time.
  • No time for one of the core game mechanics. I wanted to add an “irrationality” mechanic that would have been key to my attempt of blending story and gameplay, but it had to be left out.
  • No time for decent level design. I ended up with some props put hastily with no proper sense of space or plot progression.
  • No time for animations or visual feedback.
  • Insufficient sound effects.
  • Tell, don’t show…or was it the other way around? See the narrative postmortem below.
  • No proper testing on release builds: because of this I ended up releasing the web version with a bug on spawn times, making enemy creatures appear a lot later than they should. I have to take a look at this, but I’m still too tired for that.

Lessons learned

  • For the next LD, develop a basic but solid player control + 2D movement/steering behaviours + game entities framework or GTFO. I’ve been reinventing the wheel for several entries now regarding these core features, writing them from scratch instead of reusing and improving on past knowledge. Even if I didn’t use it this time, the same applies to tile maps.

    Not tackling this has been proving a stupid mistake jam after jam. The refactor problem and shitty controls/collisions that I mentioned before are direct consequences of it, and so are all the “no time for XXX” rants. By now I should already have that functionality engraved in stone and keep a code base that takes care of all this across every similar game (even across languages, most of the ideas behind the way I tackle characters in C# for Unity can easily carry through Haxe + Flixel, C++ or even Python), it absolutely makes no sense to keep doing the same from the start (yes, I hardly ever look at old code (facepalm)). Even if I feel that I’m improving over time on those features, improving the code that I’ve already done instead of starting from scratch all over again every single time would be infinitely more productive and would yield better results to the core of a game, its gameplay. With only 48h I can’t afford the luxury of wasting up to a whole day doing something that I’ve already done lots of times in a similar way.
  • Use sounds as debugging aids. Also, start giving sound (and music!) a bit more love.
  • Keep improving at the art process.
  • Need to test more on final builds.
  • BETTER SCOPE!!

And now on to the story woes.


SPOILERS AHEAD

SPOILERS AHEAD. SERIOUSLY!

SPOILERS AHEAD. I’M NOT GOING TO REPEAT THIS

SPOILERS AH…WELL, HERE WE GO

 

The game borrows the title from an etching from the renowned painter Francisco de Goya, and I didn’t just choose it out of a coincidence, or because it sounded haunting (which it does, I love it!). Goya was a strong Enlightenment advocate in contrast with the absolutist, old-fashioned rulers and the majority of the population of Spain by the end of the 18th century, and the picture is a satire on the superstition and irrationality rampant at the time (we haven’t advanced much in that regard, sadly). I took it as a reference because it was a perfect match for my original idea: I wanted to depict how prejudice, fear, irrationality or peer pressure can make monsters out of ourselves.

The etching in question. “El sueño de la razĂłn produce monstruos”

With this in mind, I wanted to make a game where through your actions you could end up becoming a monster (metaphorically speaking), but I didn’t want it to feel preachy or just give it all away from the start. I’m a huge fan of games like Papers, Please (btw, I recommend Lucas Pope’s submission for this very compo, Unsolicited ), Little Inferno, Darkest Dungeons or The Swapper, all of which manage to blend gameplay and narrative amazingly, and I wanted to do exactly this. Also, I wanted to offer the player a choice. However, I’m afraid that the idea was too ambitious to fit in 48 hours doing everything by myself (even if I didn’t need to improve in the development process, which I definitely do), and I had to make some dubious decisions to at least wrap things up a little bit.

For example, the intro text is a poor workaround to set the mood and immerse the players into the story. I tried hard to follow the classic “show, don’t tell” rule from writing lessons but that should have really been a part of the gameplay. As you may be guessing, I lacked the time to create some in-game dialogue display functionality (or a full fledged dialogue system for added choice and consequence, of course :D) or some basic cutscene-like sequencing, so we jump straight from a wall of text to a somewhat empty game world. To make things worse, the web version has a bug that adds some insane delay on the first creatures spawns, putting some more distance between the intro and your first seconds in the world that shatters the atmosphere built by the intro. However, this also ends up supporting the core idea in a retorted, accidental way: most of my friends who’ve played the game just start and see a couple of clumsy Corgi NPCs with no other creatures in sight, and immediately start shooting.

Another very important problem was the lack of incentives for non-violent gameplay on the submitted version. Having a richer world, with more and more varied types of computer-controlled characters or items to help unfold the plot and acquire knowledge about the creatures would have been awesome. Also, this would impact the mechanic that I mentioned before that I wasn’t able to add: an “irrationality” measure, a bit similar to the stress system in Darkest Dungeons. The point of it was that your own perception and feeling of control would be altered depending on your actions.  For example: seeing or engaging in violent acts or feeling threatened, or conversely helping someone or discovering more things about the game world, etc. Also, reaching critical thresholds in a variety of stats might probably trigger some no return points leading to game-changing situations (such as pissing enemies off enough to turn them indefinitely hostile from that moment on). I do have a limited set of them, but they’re very simplistic.

Having explicit counters visible in the HUD was also a last-minute hack. A better approach to the countdown (because I wanted to have a limited play time) would add a night-day cycle (or other kind of time frame), for instance, that made creatures flee at dawn, and instead of the deaths counters something more appropriate would have been to see changes on the world entities behaviour reacting to, for example, a massive killing spree hitting a no-return point that made enemies remain hostile indefinitely. Factoring all the possibilities and possibly emergent behaviour changs would have probably been a nightmare to properly test, though.

Last, there are the ending slides (I think there are 5 of them, depending on your behaviour or if you die before the countdown expires, but it’s only text). They’re way shorter than the intro, but again…they should belong in a muse…I mean, in the game world.

And this is it. Thanks a lot if you’ve read this far 😀

Game idea incoming!

Posted by
Saturday, August 22nd, 2015 3:42 am

I woke up like an hour ago and have come up with an interesting idea, so time to get working!

The theme feels a bit too similar to “You are the villain” from a previous LD, but it comes with some subtle, interesting connotations, so I’m looking forward to seeing what everyone else will do. My source of inspiration for the game’s controlling idea blends the compo theme with the title and intention of the following sketch by the famous painter, Francisco de Goya. Let’s see how it turns out.

Goya – The Sleep of Reason Produces Monsters

I’m in :D

Posted by
Friday, August 21st, 2015 6:01 pm

With almost everything ready, here is  my usual “I’m in” post. Then, a bit of brainstorming with the candidate themes to estimulate the brain just before bed (lots of dark themes, I love them!)

As always, I’m still undecided about the language and development aspects. The main candidates are once again Haxe (plus OpenFL or Flixel)  on FlashDevelop or Unity 5/C# + Visual Studio. On my free time I’ve become interested in roguelike development, so using libtcod with Python or C++ has also crossed my mind but I should have devoted more time to do some research on that. (I even started a small project on my free time on top on PDCurses, too, but it’s too soon for it to be useful),

In case that I use them, on my last “I’m in” post for #LD32 I linked to some setup code built on top of Haxeflixel, plus some tilemap experiments that I’d done for Unity. Find them beyond the link, I’m afraid they haven’t changed at all since then.

Other than that:
GraphicsGale+Photoshop+Inkscape and Texture Packer if need be for art (I’d like to test Spriter, but not on such a short notice).
Bfxr + Audacity + Famitracker or Bosca Ceoil for sound and music.
Tiled for level editing depending on the game needs and the coding choice I end up making.
Trello for bookkeeeping

Good luck to everyone!

Kids these days: post mortem

Posted by
Friday, April 24th, 2015 3:49 pm

This edition I’ve had a lot of fun, and I’m proud of the amount of work done, even if the game could use a lot of improvements. My unconventional weapon of choice was words, either to hurt or stun foes.


Play it and rate it here 😉

 

Tools

  • Engine: Unity3D
  • Coding: Visual Studio 2013 community edition
  • Art: Graphics Gale, Photoshop
  • Audio/Music: Bosca Ceoil, Audacity

What went right

Early start

This time I chose to wake up earlier in the morning in order to earn some more hours than in other jams. As a result (in addition to the obvious: increased time), it helped me come up with a core idea and decide on the technology really soon. The tradeoff was that I chose to do the same on Sunday, although I’d gone to bed awfully late. I’ve paid for that during the week at work, but here comes the weekend again to relax a bit :)

Clear tasks

This helped a lot with development and, to a lesser, more painful, extent, to cutting out features once the “LAST HOURS” bell rang.

Familiarity with the engine

I’m currently using Unity3D at work, so I’m pretty used to it these days for 2D. Visual Studio in its Community Ed. is also an amazing tool for coding, so both programs helped me develop a more or less solid code base quicker than I’d expected.

Improvements on art

I’ve tried to pay more attention to art in terms of colour, character and environment art plus animations, and I think the end result is better than in earlier compos. There’s still a lot of improvement on this area, but feeling that you’re becoming better with time feels immensely rewarding.

Late hour change in setting

The game was born with a sci-fi setting in mind. Rather than a grumpy teacher in a high school, I first had an agent infiltrating a building where the main antagonist, a Blade Runner’s replicant-alike character, was taking hostages with the help of some buggy androids. Her demand was for the Government / Big corporation to completely disable a module that made it possible to entirely shut an AI down with a special word or passphrase.

As for the bugs on the enemy AIs, they made them extremely faulty in the Language Processing modules, thus the “damage” and stun effects taken from the speech-related protagonist skills.

Quite different from the final result, isn’t it? I gave up on the idea while I was drawing the enemy sprites. I realised that I had no clear, consistent art style on how the rooms or characters should look like, so they were coming off as very generic, and the deadline was too close for a complete overhaul. As a consequence, I decided to ditch all this and go with a way simpler plot and theme.

Initially I’d put this in the “what went wrong” section, as in a way it feels a bit like sacrificing the original idea which in my mind was very promising. However, I’ve realised that the high-school setting may be better fitting to the current art style and tone than the original idea, even more so considering that the MacGuffin feature (the “death passphrase”) for the original plot, plus a couple of interesting gameplay features that would have complemented a shocky-but-unoriginal revelation, was never close to reaching implementation stage.

What went wrong

No level progression / design

In LD31 I had defined in paper the basic level layout, and I found that pretty useful back then. Here, however, it was way more vague, which was damaging in terms of scoping, art and a tiny little detail…FUN.

Still more effort on art required

Although the graphics look better IMHO this time than in previous editions that I’ve participated in, they’re still average at best. For example, I should have given some early thoughts to the art style in terms of colours, lighting, drawing style, etc, etc (and this is heavily dependent on having a better defined level design).

And, of course, the game is lacking a lot of animations. I created basic sprite templates for the four walking directions, but only the frontal one is showing up in the submitted entry. Also, there’s no feedback on when characters are using their skills or receiving their effects other than a text that shows up too fast. The “boring speech” skill text effect could help some more polish as well in terms of timing, spacing and so on.

Asset creation time badly scoped

Again, I underestimated the time it would take me to prepare a set of animated characters, plus several backgrounds, plus the HUD/UI (I’m not too concerned with the latter, though, as I can get some functional UI graphics pretty quick, but that’s still larger than 0). This was also a result of not having the general visual style or levels defined beforehand.

Last, my lack of experience using Graphics Gale also contributed to the sluggish pace at the beginning.

Unclear / buggy combat

Some glitches in detection ranges, timing and so on, coupled with the lack of art, made disabling enemies bland, which is an awful mistake when the player’s skills were the core of the game. This, again, took away points from…how was that called? oh, yes…FUN

Having a tutorial (even better, embedding it into the game itself) could have helped, but as always…Time.

Music / audio

4 hours before submission I was close to exhausted and lacked all the menu and game over functionality. Still I decided to get some music in. While I don’t think this is a mistake at all, I devoted too little time to get only some bass and percussion sequence which didn’t even properly loop. Also, I decided to cut on sound effects if I only had time to randomly pick a barely fitting sound on Bfxr.

What I learned

  • Prepare stubs for basic animations & different visual styles.
  • Clearer level/goal design: focusing 100% on feature development is all nice when you’re under no time constraints or working with other people. With so little time as 48h it’s probably best to have in mind the whole set of features to have a more iterative development cycle, and this includes having a vision of where the game entities will be, how they’re expected to interact in a basic playthrough and so on.
  • Art: Practise, practise, practise.
  • Improvements in tasking have helped especially in the coding area, but I still need to incorporate the remaining fields into the equation. A generic “animations” task card in Trello is worthless if you don’t know if you’re going to need 10 10-frame animations for each character or 4 frames to cover all movement and that’s it.
  • Don’t fall too much in love with your idea and don’t fear cutting stuff out or even sacrificing things such as the plot if it’ll help you finish your game or have it more fun.
  • Keep working on some set of useful code toolbox. This time I haven’t had the opportunity to use the libraries I’d prepared to support tile mapping, but I did reuse some tiny progress bar script for the health and eloquence bars. Not much, but


[cache: storing page]