Banish and Polish

Been playing around with this project quite a bit this summer. Here are a few highlights!

Banish Ability

I implemented a new ability, Banish. It targets an entity and teleports it to a random part of the map that is out of the casters vision. This means you can send away dangerous opponents, but you can’t control where they’ll end up. Maybe just behind a pillar right next to you…

Also, since the code don’t deal with “players” or “enemies” or “monsters”, but entities, it means you can banish anything. Like a chest, yourself, or a door.

Just to test it out, I created an enemy that would use the banish against you. Turned out too frustrating as it is potentially very deadly, and almost completely out of control, so needs tweaking.

Sequences re-write - C-style

The back bones of this game is how I can create and chain Sequences together. It was one of the very earliest features I implemented, but some aspects of the implementation has annoyed me for some time now:

• Object oriented C++ with inheritance, not very nice to work with: lots of boiler plate and lots of copy-paste for every new sequence
• Heavy use of new and delete, even though the rest of the game uses my own, custom memory arena allocator
• Lots of copy-paste nonsense between header and cpp-files (even though I thought I managed to keep it fairly simple with a factory)

So I took the bold decision to do a full re-write. No more classes. No more new/delete.

Now we’re using old-school C-style structs, void * for custom data (yeah baby), and function pointers for custom execution. My project, my rules.

Turns out I could simplify things a lot. Better overview of existing sequence-implementation, and fixing a few bugs along the way.

Slot machine polish

One sequence that was very old, and very hacky was the slot machine implementation. While at it, I got to do a re-write, getting rid of some really crazy hax, and adding lots of polish to it too!

• Each real slows down before stopping
• As a reel stops, the result is highlighted by a quick white flash
• Added a bit of shading to the “curves” of the reels
• Reel can support other that plain damage numbers (implemented fire damage as a test)

And here is a video of the new slot machine in motion.

Working on some other, really cool features too. But those’ll get their own post!

Happy ascii!

Holes in the level, and ability hints

Been mostly playing with levels, but have two new things to show.

First, I added descriptions to each ability which is displayed when hovering in your inventory.

And secondly I added “holes” in the level. You can’t walk over a hole (unless you can fly), but you can see over it and ranged attacks work. If you can teleport, then you can also teleport straight to the exit.

That’s all for today.

Asciibrain - Strategic Gameplay!

Sometimes it’s the small things that really stir things up. I decided to spend some time on making a static dungeon, and making it really fun. And the result was fantastic!

Step 1: Add a third character

Only two characters made the game hard. A turn would end too fast. So I quickly added the Thief. This new character has the following interesting characteristics:

1. Weak! Low on hp and don’t hit very hard
2. Has a much shorter walk range, BUT has 3 actions per turn (instead of 2) so the total movement is much greater
3. Has a new default ability Sneak that makes enemies ignore him (or her?) for one round
4. Also starts with the One more thing ability by default, which means she can make up to 4 potential actions!

Step 2: Players can act in any order

The Thief turned out fantastically, but turn order really limited everything. So I quickly re-wrote it to allow you to change to any player controlled character with actions left….

And wow! Now it’s a completly new game!

Where before it was just mindlessly “walk and attack”. Now you can start taking strategic decisions! A simple example:

1. One of your characters is in deep trouble, cut off and surrounded by enemies and low on health.
2. Switch to another character. Loot a nearby chest (chest will give every character a ability-card) and
3. …pray it contains something that will save the day. Maybe your character got a sneak? Change back and apply it to yourself. You’ve just delayed your imminent doom one turn…

Here’s a short video showing heroes and abilities playing together…

Step 3: Adjust health on doors

Another really small, but impactful change, was to lower the health of my doors to match the damage of a Fireball. Now, any door that gets collateral damage from a fireball will be removed and reveal the enemies behind it… now you need to be a bit more careful…

Step 4: Adjust health on chests too…

Even more critical! Chests also gets destroyed from Fireball damage! This might be even more critical!

How to handle it? Change to the Thief character, sneak in and grab the loot, get out of the way and have the Wizard fry the eneimes and the now empty chest…

Asciibrain - Memory Issues

How a simple feature, developed in one afternoon, turned into a memory corruption bug hunt that lasted almost a month… I’ve been so proud of how simple, and easy to use, my custom memory allocator has worked. Then suddenly the memory issues started happening and I had to deep dive into all kind of memory related debugging. And what started as one bug, soon turned out to be three different ones. READ MORE >>

Status of AsciiBrain - end of 2023

Haven’t posted in a while, so let’s do something about it! Big time!

Here’s a summary of all that’s happened to asciibrain (that I haven’t yet posted about) during at least the past 1,5 years. Quite a lot, this is still very much a live passion project for me.

READ MORE >>

Asciibrain running on Linux

Migrated the project to CMake and tried compiling it on my ancient linux netbook. Had to shrink the window, other than that it worked fine!

Here you’ll also see a glimpse of my ascii smoke and text layout code…

White laptop to the left is running Lubuntu and the laptop to the right is running Windows 11.

Ascii particle mockup

I love particles in ascii, and started prototyping on a first-look on a fire/explosion type of effect. So far it’s hard coded to explore the kind of style I’m after and see what the requirements are… Here’s the process it went through!

First try. Yellow to black. Delay per cell based on distance from center with a small offset to not have it ’too symmetric'.

Second try. Red to yellow to black.

Third try. Kick up the offset and make it longer.

Fourth try. LoL, explosion should start with yellow then fade to red (doh). Added in smoke and lowered that offset again.

Fifth try. Minor changes and tweaking. I really liked this one!

Here it is together with a fire-trail and damage implementation, how it currently looks in the game.

AsciiBrain, UI mockup

In order to proceed with all features, I figured I need to know how my UI should look and behave. Sat down and tried to do a mockup. Damn design is hard and time consuming (I just want to code). Well, I’m happy enough with how this turned out.

Although it is a bit too much Demeo rip-off right now. Don’t worry too much about it, I’ll move away from that soon enough =)

Asciibrain, rendering glitch

I needed to refactor my rendering pipeline for improved flexibility (adding a speed improvement in the process). But sometthing went a little wrong resulting in the following images…

This might be one of the coolest bug of my entire career!!

Multiple characters and perf stats

Tiny update this time.

TICK is the number of milliseconds for main update loop

BUFF is when we process our graphics buffer and create the SDL commands to draw it

REND is when SDL actually renders to screen (it’s so high because of VSYNC)

The first value is actually quite high right now, because I’m very wasteful and calculate shadowcasting and A* every frame even when nothing changes.

Ascii rougelike progress

Haven’t written about this in a while, but there is a ton of new stuff going on…

• Multiple states (start screen, main game) in a classic old fashioned FSM
• Multiple entities in a turn queue
• Simple sequence pattern for animations and commands
• Heatmap generation to calculate moverange
• A* pathfinding
• Color pallette adjustments (oh, this needs to be worked on)

(oh, and those red dudes are not ascii… did some experimentation but did not really like it)

…more to come, I promise =D

Recursive Shadowcasting

Been a while since I worked on this one. But I have some very intriguing ideas, so I wanted to pick this up again. New features since last time:

• Recursive Shadowcasting
• Support for custom FG/BG colors
• Mouse input
• Text output

More to come…

Adding a light source

Took a first step towards implementing shadowcasting, the ability to show a tile as lit/unlit/hidden.

Very first implementation is just distance based. Next step: recursive shadowcasting! =D

To be totally honest, this setup of the generated dungeon doesn’t feel very interesting to explore. But that’s not my main concern right now. I’m just trying to get the very basic systems to work before moving on with the gameplay parts.

Generating a BSP dungeon

All right, in order to start doing something cool I need a to navigate in. RougeBasin to the rescue! They have a really cool tutorial on a BSP dungeon (Binary Space Partitioning, simply put: a node tree where every node has two child nodes). Link here

First step: Create a child node of the entire area. Then randomly split it vertically or horisonatlly (offset the split by a random amount) and add the two inner segments as childnodes. Then repeat for each child node.

Second step: Take all the leaf nodes, shrink them a bit and move them around by some random amount.

Third step: Draw a corridor between every sibling node. Then move up to the parent node and draw a corridor between those siblings. This picture only has corridors on it’s outmost leafs.

Fourth step (cheat): Turns out that connecting the parent nodes are a real hassle! In order to keep any kind of speed I did a cheat and drew corridors through the center of each sibling node. As long as I don’t offset any room beyond the center coordinate the corridor will pass through a room.

This was fun, but getting step 4 up and running took way too much time. You don’t want to lose too much momentum when dealing with hobby projects like these, and this is good enough for me to continue with the next exciting step!

Scrolling camera

Got a scrolling camera to work in tonights short session, showing a part of a bigger underlying map. Next up:

1. Generate Dungeon
2. Shadow casting/field of view