Fujo – Lessons Learned

Fujo

For the 28th Ludum Dare contest, I made a game titled Fujo about a temple maiden kidnapped by monsters, who has to fight her way back to the surface.
This article is documenting my decisions and the design process, and reviewing what went well and what went wrong. I hope that it will prove useful not only to me.

The Idea

I knew from the start that I wanted to make a game inspired by the immortal classic game Rogue. I wanted it to be a dungeon exploration game, with tactical combat and resource and risk management. From my previous attempts at making such games, I had some idea what makes them tick:

  • procedurally generated levels,
  • random loot distribution,
  • food clock,
  • item identification,
  • at least two ways of using every item, some good and some harmful.

That is all that I knew before the theme has been announced. I also had a rough plan for the overall architecture of the code – again based on my precious attempts.

The Roadmap

I didn’t really have a very detailed plan, but I knew what needs to be done, and which parts depend on each other. One thing that I considered important was to have a menu system relatively early in the game – I knew that it will make adding a lot of features easier later. In the end, the roadmap looked something like this:

  • blank screen,
  • empty level displayed with graphical tiles,
  • predefined level displayed with tiles, proper tiling of the walls,
  • a data structure for the level,
  • level generator,
  • displaying message windows,
  • displaying menus,
  • a player character sprite,
  • moving around the map, in jumps,
  • proper graphics for the level,
  • monster sprites, predefined monsters,
  • sprites properly obstructed by walls,
  • sprite animation,
  • shadows,
  • randomly placed monsters,
  • attacking monsters by walking into them,
  • monsters walking around randomly,`
  • monsters attacking,
  • the sleeping/angry states for the monsters,
  • object sprites, such as bushes and ladders,
  • item sprites, randomly placed items,
  • numbers and messages floating above monsters,
  • item pickup animation,
  • player character and monster stats,
  • displaying of player character stats,
  • player character inventory,
  • varying item kinds,
  • displaying of player inventory,
  • using items (food),
  • equipping items,
  • item stats, different item kinds,
  • actual combat mechanics,
  • metabolism (food, death),
  • item throwing and discarding,
  • spells and spell effects,
  • level generation adjusted by depth,
  • boss level,
  • title screen.

Tiles

tiling

For the wall tiles, I used a clever trick that I have learned recently. The thing is, if you just use normal tiles, with all combinations of all possible bends and corners, you end up with a very large number of tiles to draw, and quite a complex algorithm for choosing which one to draw. But if you instead shift your wall tiles by half a tile down and right, so that every wall tile is actually at the connection of the floor tiles, then you suddenly only need a few different tiles and a very simple algorithm for placing them. The price you pay for it is that it’s now hard to have different kinds of walls, but fortunately I didn’t need it here.

Graphics

I initially used the graphics from my previous games and demos, just to see if my ideas have any legs. I then went and re-drawn all of them, both to make them fit better and to comply with Ludum Dare rules. This really let me concentrate on having a working game first, and to work on the graphics as I had time.

Level Generator

I wasn’t very creative with this one. I used the algorithm that I described in an article at Rogue Basin some time ago.
I just had to tweak it a little to fit the dimensions of my map, and to keep a list of empty tiles, so that I can place stuff on them later.

Menus

Creating a menu display system early on really paid. Thanks to it I could easily implement the inventory, and later add different actions for the items.

Throwing

All items can either be used/equipped, or thrown at the monsters. That means that you always have an option, and that there are no useless items. Even the spells that have a bad effect can be thrown at the monster to your advantage.
Not to mention all the extra weapons that you find. One thing that I didn’t have time to implement is the throwing animation – I just show when a monster has been hit.

What is missing

I didn’t have time to make everything. There is no sound or music. Joanna Piechowiak composed original music for it, and it’s included in the post-compo version, but I couldn’t come up with anything by myself during the competition.
There are only two kinds of monsters, a normal one and a boss, which really makes all those different kinds of weapons pretty useless – you just want the strongest one. There is no “fog of war” – I added it in the post-compo version, and it makes the exploration of the level much more interesting in my opinion. There are no traps or hidden passages, even though I initially wanted to have them. There are no status effects for the player character – I would really need these if I wanted different monsters with special attacks, but since there is only one monster, it somehow works. No magical equipment too – amulets just increase your defense. It would be nice to have them grant invulnerabilities or other bonuses than defense. And of course you can keep adding stuff to a roguelike game and never stop.

Play and rate it.

Source: ludumdare.com archive

Found a bug?
Tell us on Discord