Tania Anta's gamedev portfolio

I’ve neglected the blog once again, so to make up for it I’ll try to write not one, but hopefully three postmortems over the next week explaining what I’ve been doing these past months besides gaming.

I’ll start with the most recent: Fairy Bomb, my entry for last week’s #7DRL challenge.

Play it here

In case you don’t know, the challenge involves creating a roguelike game in seven days, with completeness being the main objective.

You may remember Rob-like, my first foray into roguelike development, which has been canned for quite a while now (I keep fooling myself saying I might resume it, but then I say the same about most of my game jam projects and...ahem). Then, late last year I went for a second attempt with Sacrifice-like. That would have been my entry for the 43th Ludum Dare if I’d managed to submit it. Unfortunately, I both miscalculated the scope and burnt out from yet another game jam that had taken place the week before. Since that will hopefully be the second post-mortem I will not spoil more.

Back to Fairy Bomb, I went for a relatively straightforward idea for a game, with some twists: The map would be hexagonal rather than a square-based grid, and the combat would be fully based in bombing like in classic Bomberman (At first I’d considered that monsters could also use melee andI even implemented a basic pass or projectile-based ranged combat, but cut it out because it didn’t feel right at the time).

Last, I decided to make the bombs paint the ground conferring side effects to entities occupying those tiles.Those side effects would range from status changes to healing or other crazier stuff, and could even become the game objective in itself if I had decided to pivot to territory control instead of your usual “escape a dungeon” goal.

I’m pretty happy with the idea and somewhat satisfied with the result.

What went well

Code reuse. This time I was able to benefit from some bits of code from past projects.For example, I ported the BSP generator from a procedural generation demo I’d done a couple of years ago (and before that I’d used a similar implementation I did for Rob-like, but had to scrap it). Other areas where I could use existing code were the battle logic, back when I was thinking of using normal combat for the AI and the “play contexts”, which determine the context the player interacts with the game under certain circumstances (normal interactions, multiple-input interactions, etc).

Learned new things. In particular, I had to do some research about hex maps. Unity’s Tilemap functionality already helps a lot, and for the missing bit I can’t help but recommending strongly Red Blob Games’ Hexagonal Grids article.

Code architecture ideas + Data driven game logic. If/when I develop the game a bit further and can clean it up, I might share some tech design docs or code. If you’re masochistic, though, you can check the repo on Github.

Feature scoping and adaptations. As time crept in, I decided to scrap several of the features listed on the backlog. For example, instead of adding normal consumable items, like potions, I decided to exploit the terrain paint’s side effects. Also, doing without melee combat resulted in more symmetric gameplay, which would make easier to playtest the core bombing mechanic and reduce the number of interactions available.

What went wrong

No art.  I could only rush some tile and bomb art and ended up using the character graphics I’d used during development. I have a very clear idea for the main character and some hints for the enemies, and I would like to try to take this a bit further.

Barebones content design => Bland experience. I did have a number of systems in place that I believe are really promising, but in its current state I think I’m not exploiting them to their full potential. Map generation, monster spawning and loot rules are there, but they don’t offer anything interesting right now, and the terrain painting is not super useful at the moment. I need to rebalance everything, create more content and try to structure everything into a fun whole.

Juggling a game jam with a work week is exhausting. While this time I did manage to submit my days reduced to work-jam-work-jam, except for Friday, when I took some time off for the IWD. Needless to say, this is not healthy and I should not do this again (especially when my last LD failed for similar reasons -although not exclusively)

Code architecture misuse. Because of the rush some good ideas I had about how to structure the code ended up twisted. Also, I probably overcomplicated things in some areas.

In the end, I overscoped once again.

Learnings

Simple can be better. Reduce scope as much as you can, and then try to reduce a bit more.

REST.

Phew... seems like I skipped one full #LDJAM edition with no new posts, so I’ll try to combine everything here :D Sourcetree tells me that the last update on the RTS took place a couple of weeks before #LD41, so I probably changed my focus to continuing the jam project (in a way, another RTS, more on that right now) and then life got in the way. Shame! The theme for the 41st Ludum Dare was “Combine two incompatible genres”, which spawned lots of interesting ideas. Mine was a hybrid of a rhythm game with RTS mechanics.

Enter Beatcraft!

On the video is a losing playthrough:

I didn’t have time to focus on a more relatable RTS flow (for example, exploration, choice, different units or more sophisticated combat) and there were issues with feedback, so it rated poorly, but I liked the concept. Fast forward 4 months with no energy to code after work and hey, it’s Ludum Dare time again!

These days the 42nd is on the rating phase. The theme this time is “Running out of space”, a bit similar to the 39th “Running out of power”, and I took the inspiration from a trial in Takeshi Castle and another from Indiana Jones and the Last Crusade to create a Stepping Stones, a dungeon crawler where you need cross a pillar-filled chasm.

Here’s a fragment of a run:

After the jam I’ve tried to focus on improving the dungeon graphics into something that resembles a dungeon and a couple music tracks.

Once I do those improvements (or get bored of it) I wanted to focus on learning new stuff. Right now the top candidates are:

Continuing with a UE4 online course I’d started.

Experiment with Unity’s new 2D tools.

Refreshing what I learned about 3D modelling on a Blender course, and hopefully apply them into a game.

Deep diving into music theory with a special focus on composition and probably learning an instrument.

I haven’t posted since Christmas for the mandatory Ludum Dare spam, but that doesn’t mean I’ve been idle. On the one hand, I joined a project at work using Cocos-2dX, so I started a smaller project at home to implement a first pass on RTS mechanics using a top-down 2D view using that library. My reference is Castle Fight, a relatively well known mod for Warcraft 3 (Fun fact: if you think about it some of the most successful games right now both on mobile or PC (most MOBAs, Clash Royale, etc) can be traced to a mod of WC3/SC, or a variation). Progress is slow because life (and to be honest, Arena of Valor -_-). I’m trying to keep over-engineering under control, and I’ve started coding some construction logic. Hopefully soon I’ll be able to show something better than this.

Besides, this week began the #7DRL challenge. I’ve used the opportunity to check TDL, a Python-3 upgrade of sorts to libtcod, a c++/python library that has lots of useful functionality to code a roguelike. However, I don’t have any clear idea for a game that could use it, so for the time being I’m basically refactoring a tutorial. Hopefully I’ll come up with something. On the gif you can see how the player moves around on a map. FOV is provided  almost for free by TDL.

I can't bring myself to re-format the whole thing a second time, so I'll just post the link to the postmortem on the #LDJAM site.

It’s been a while since my last update. I must admit that I haven’t been doing much with code because I’ve developed a severe case of addiction to Arena of Valor, a MOBA for mob..ile devices. Also, lots of Nintendo-related games. I did try to build a simple shader displayer program on DirectX11 to refresh some knowledge, but little more than that. It’s still too underdeveloped to share anything, to tell the truth. However, this past weekend was Ludum Dare time! I managed to overcome my hiccup from #LD39 and this time I went for a smaller scope, which proved a way better choice, even if I still had some mean bugs and lots of features to implement. I introduce you to Mountain diver :D

After some months soft launched in a small number of countries it seems that the world release date has arrived, and I can finally share the game I worked in during my time in Outplay: 

First things first, the non-submission link: TnL @ Ldjam.com

I'm currently on a train back to my hometown and I should be taking the opportunity to get some rest. Instead I'm reflecting on the weekend.

This is the fist edition that I don't get to submit. Maybe the second if I count LD30, when I had to quit pretty soon after my router broke down following, interestingly enough, a storm. I couldn't bend what i had into a submission-worthy entry, and in the end I just decided to publish the entry as “Unfinished” so it doesn't feel like wasted time (Great new feature, by the way!). I'm a bit frustrated, and immensely tired, but at the same time I feel proud of the game.

The game

Thunderbolt and lightning: extreme blackout family survival simulator! (I’ll use the shortened forms TnL or just the more common Thunderbolt and lightning) puts you in charge of a household experiencing a prolonged power outage with a limited amount of supplies and the help of a backup power generator. Your goal is to keep track of the family members' needs so they won't suffer a mental breakdown...or worse.

You can take a look at it here: Thunderbolt and Lightning @ Itch.io

Tools and credits:

Unity and VS2017. Aside from some time to tweak the rain drops particle system, I didn't find any significant issues.

Draw.io for the floor plan.

Inkscape + Photoshop for graphics.

TexturePacker to build atlases, and for the first time I used Codeandweb's own Unity exporter plugin to save me some time from cutting the sprites manually.

myNoise’s  thunder sound generator + Labchirp. Audacity for tweaks.

Credits-wise, I used Mike Koenig’s Thunder Strike 1 once in jam mode, for the occasional lightnin effect.

What went right:

The mood, I think (vfx + audio)

The art style, even if it was rough and the techniques inconsistent.

Having the game level out relatively soon. It gives you some focus in terms of how characters can interact on it, and also give.

Work throughput. The extra day probably played a part here, for sure.

This is debatable, but not giving up. Even as it became apparent that the progress wasn't enough and I had no backup submission plan as in past occasions, I refused to throw the towel (I did consider that over Monday afternoon, though),  and kept pushing forward.

What went wrong:

SCOPE. This was a consequence of two other huge interdependent mistakes, because of which I vastly underestimated the amount of work required and also, how would the elements interact to create an emergent and fun experience:

I neglected a key intermediate design abstraction layer between the core idea and some more specific requirements, or how systems would interact together, and how all of that should reinforce the player experience.

Because of this I didn't really have a decent planning. I kept a Trello board, but was basically adding and removing new tasks to it as I went.

No backup plan for the deadlines. During the second day my progression hinted to miss the compo limit. Back then I should have stopped for a while, taken a look at the project's status and make some compromises or changes so that, even if I wouldn't be in time for compo, I'd definitely have a concrete, manageable goal for the jam. I didn't. I just naively assumed that by continuing work I would just make it somehow.

Crappy art pipeline / asset conditioning process.

Going solo for the compo can be hard, but once you take part into a couple of entries it is manageable. Likewise, solo-ing for the jam can reduce the time pressure and give you some buffer to get some proper rest and take care of yourself if you plan beforehand. As for myself, I just used the jam mode as an extension of the deadline and kept crunching for almost the whole day (with the predictable result of exhaustion).

Lessons learned

Don't just become enamoured with the idea, a bunch of secondary ideas and incorrectly assume that it all constitutes a proper design. I hope this time was an exception compared to more recent entries where I had a more down-to-earth vision.

Specially don't assume that it also works as a task list. Prepare properly.

Even then, try to reduce scope even further.

The plan should clearly state the main steps for a potential submission candidate, and some risk assessment points to determine if changes/cuts are required. At any of those points prepare a plan B.

This has been repeating for a while on my previous postmortems, but I need to practice art.

As the project has grown a bit, I thought it would be best to add it to Github, so here is the URL to the repo.

https://github.com/wildrabbit/cavegen

I’m using the following external dependencies and building using the platform toolset for VS 2017. It should probably build without any problem on VS 2015, too.

SFML v2.4.2

Ocornut’s ImGui

I’ve been playing around a bit with map generation, and as a result here’s a cellular-automata based generator I’ve cranked quickly (this could bring some inspiration back to resume work on Roblike, who knows?). The shapes are not so fancy as in the resources I’ve been following yet, but I still have to tune the algorithm, and perhaps increase the size of the map.

The current implementation is pretty straightforward for the time being.

First we initialise the map with some random noise, using a set probability of a wall spawning.

Then we run a number of simulation steps. For each of them, we examine the neighbours of a given cell in the map (on the previous iteration) and count how many of them are wall cells. If the number exceeds a set threshold, it’ll become/stay a wall. Otherwise, it’ll be an empty cell. Further simulation steps help smoothing the shapes.

As I mentioned, the open areas still don’t feel nice enough, and I’m not ensuring connectedness between areas yet, so I need to work on that.

Almost recovered from the rush of the weekend, here is the post-mortem of Tooth Decay, my entry for the 38th Ludum Dare. As always, I participated in the compo mode, and as always, I had a lot of fun.

Play it here!

Background

As usual, I tried to brainstorm some ideas with the final theme selection. This time I couldn’t spend long doing this but still managed to fill some pages of my notebook with ideas.

Eventually the theme was announced. I wasn’t particularly excited with it: I felt it might lead to a relatively narrow range of mechanics and/or settings (I’m guilty of this myself :D). However, there’s always an interesting idea you can come up (or any kind of idea, really), and if there’s anything sure is that people will surprise you with their own, so in the end it’s fine.

I kept brainstorming for a while, now focusing only on the final theme. One set of contradicting concepts I would have liked to explore was how communications and technology have managed to vastly expand a relatively small world (a tribe in prehistory, or a small town not so long ago…), but at the same time they have contributed to shrink it sometimes, reducing it to isolated bubbles of like-minded people. I wasn’t able to come up with interesting mechanics for either of the two, so I went for something more conventional. Below, more ideas for “a small world” :

By that time, one of my wisdom teeth started to hurt “BIGLY” -and has continued to do so without fault. That reminded me of an episode of one of my favourite cartoons when I was a kid, Once Upon a Time…Life (Fun Fact: if I hadn’t discovered video games I would have probably studied to become a doctor because of it). The episode in particular was about a bacterial colony excavating a cavity on a tooth.

I think my streptococci are way cuter.

The setting was perfect, and an obvious game mechanic immediately joined: drilling. Because of the time and constraints I went for something relatively simple and fun, and I remembered Mr Driller, a game by Namco where you…well, drill. I decided to use the same concept, and incorporate some base building mechanics (which unfortunately didn’t make it onto the game in the end), a la Steamworld Dig or a Flash game I found while looking for references: Motherload.

I had a solid idea, and it wasn’t even noon! I immediately opened FlashDevelop, created a new Haxeflixel project and started prototyping.

What went well

Clear vision.

Fast paced gameplay.

Modular design. Thanks to this compromising was easy and at the same time there’s a lot of room to expand it in different ways while staying loyal to the vision.

Main mechanics working relatively early.

Cluster-finding algorithm. To detect groups of tiles of the same type that can be drilled in one go and drop to the ground I used a two pass labelling algorithm, as depicted here and here. It was surprisingly easy to implement, and it worked like a charm (or almost, I think I’ve spotted an occasional bug).

Haxeflixel debugging console. This time I took a bit of time to research how to the in-game watch window and the command console quite a bit and I have to say it is quite powerful and helpful.

What went wrong

Art bottleneck. I spent more time than I should have coming up with an art style (pixel art? vector? what about “none of them”!?) and a decent set of concept references for the in-game screen and the overworld. I also added some animations to the main character, and even if it doesn’t have too many frames I’m still super slow at doing that.

Collision resolution + Camera management woes. I had to fight a bit with Haxeflixel, first to sort out some glitches handling player-tile collisions, and then to get my two cameras (one for the HUD, one for the board) to render properly. I could have probably been able to work with a single camera setup, but as the map had an X-offset and applying it to the whole scene isn’t trivial I’ve found that using a camera works fine…once you manage to set them up correctly. I lost a good couple of hours with this.

Dropped working-ish feature. On Saturday night, right after I implemented the clustering algorithm, I quickly hacked tile shaking and dropping once a tile’s cluster becomes disconnected from the ground. It was working, but drove performance to the ground and it was quite late at night, so I decided to. In hindsight this was probably a good decision, but I would have liked to see it in the submitted entry.

No resource management / upgrade system. What can I say here…good old lack of time.

No time for sounds. Eeer….the same.

Lessons learned

Keep a stock of Nolotil pills available on my cabinet for emergencies. Paracetamol just doesn’t cut it T_T

Improve the art pipeline! Practice, practice, practice.

Start exploring alternatives to Haxeflixel: While the framework is simple and powerful, from time to time I keep finding some issues with relatively straightforward features that have me fighting against it more than they help me save time. To tell the truth, most engines and frameworks have their own peculiarities, so eventually you’re bound to bump against something that works in a different way than you expected regardless of which technology you choose.