Category: Uncategorized

The real world continues to rudely intrude upon my 7yrl’ing time, but that hasn’t stopped a slew of updates over the last few weeks. In no particular order:

New landscape & PC/Mac UI

The previous UI is optimized for mobile/small screens. That remains a key target, but I also want a UI that feels more natural on a PC, Mac, or larger tablet. In that vein, here’s the new UI for those devices:

Particle effect improvement

Particles can now have a bloom effect that can be seen in the picture above. I also enabled a number of other effects (e.g. custom blend modes). More impactfully, I also created a particle editor tool which allows me to tweak particle effects on mobs, items, celleffects and more on a very granular level. This will be hugely helpful later on when I focus energy on fleshing out the game’s universe. Here’s a pic of the particle and light editing tools:

Although I haven’t started really leveraging this yet, it’ll make it far quicker to create tons of different effects to help differentiate monsters from each other, items, rarities, and so on.

The particle editor uses the actual game engine to render particles so I can see them as they’ll really look. The editor loads from and saves to both xlsx and dat (serialized binary, read by the game) so that I can still use Excel to do more complex or bulk editing tasks if I wish.

As another nice touch, I tweaked the game itself to watch the definitions file at runtime and reload it if it changes. This way if I’m playing the game and see something that doesn’t look quite right, I can fire up the particle editor, tweak it, save it, and a moment later it updates in the game without having to leave/restore it. Result: much quicker iteration time.

Gibs

For fun I added particle effects for damage-taken effects; now when a mob (or player) is hit, there’s a chance they’ll spew blood. Here’s a small example:

Thanks to the particle system, the blood effect sprays out and even bounces a bit on the ground. The effect isn’t perfect yet, but it’ll do for now.

Vault Editor

I also created a custom editor to allow me to easily create Vaults. Vaults are pre-created rooms that are used to give a bit more variety to dungeon levels; at dungeon generation time I’ll swap out empty square rooms with these prefab rooms randomly. To avoid it seeming incredibly repetitive, I’ll need a ton of these vaults – thus, the editor. Here’s a pic:

As with the particle editor, this is using the actual rendering engine, so I can click a button and see what it’ll look like with the actual lights, particles, etc:

Settings UI & Fidelity settings

There are now multiple fidelity settings to support lower-powered devices. I’ve also added the start of the settings UI along with a few other settings controls (e.g. hide/show blood effects):

160 mobs added

I took the ~200 mobs I had defined and alloted them out between the 20 dungeon levels, moving some out to ‘v2’. I also chose about 120 different mob images from the Oryx set and prep’ed them in the spritesheets so the mobs are now ready for balancing, skill-setting, animating, and adding normals in a few months.

Player XP and Leveling

Players now gain XP from killing mobs and can gain levels. They aren’t given any awards yet however (skills, stats).

Mana

Mana is now a part of the game; all classes have 100 MP – skills have mana cost and mana potions can restore them. No more infinite health skills for you! 🙂

Potions and Scrolls

Potions can now be drunk and scrolls can now be read. The cool part is that in both cases the effects are defined through the Event/Action system which means that very unique effects can be crated without touching code. Here’s the Excel definition for a Renew potion:

Tooltips

Items, mobs, and skills now display info in a tooltip. On the PC/Mac they appear on mouseover; on phone/tablet they’ll appear on press-and-hold. Here’s and example:

Multi-item grid pickup UI

When the user tries to pick up more than one item in a Cell, it now displays a grid with all of the items in it and allows the use to pick up some or all of them. The grid autosizes to the number of items, and has previous/next pagination if there are too many to display on the screen:

The same grid is also used in the character’s inventory display

Character sheet/inventory redone

I’m still iterating on the best way to display the various panes (character info, inventory, stats, tomes, professions, …). As an interim step, I’ve combined character stats, inventory, and skills into one pane, and plan to have all cross-game info (tomes, professions, etc) in another. Here’s the start of the placeholder char/inventory pane:

And lots more…

Tons of bug fixes, quality-of-life coding updates, and tweaks. It’s been a busy few weeks!

Work sent me to CES last week (more exciting than it sounds – valuable but endless partner meetings and an at-best uninteresting show floor) which stole most of my time last week, but I still found an hour or two here and there to work on 7YRL (lest it become the 8YRL).

Vaults

The first big addition is Vaults, or prefab rooms. As I mentioned in some post or another many millenia ago, I love DCSS’ vaults – it adds a huge amount of variety and interest to what would otherwise become a somewhat repetitive environment. I’ve added a similar concept to 7YRL. As with other aspects of the system, Vaults are defined in Excel and converted/serialized into a binary stream at design time. Here are a couple of simple test examples:

A bit unwieldy, but for a previous iteration of 7yrl I created a UI to manage creation of Vaults and I’ll eventually port that over to eliminate some of that.

Here’s a more complex VaultDefn:

which in the game looks like this:

For added variety, most vaults can be rotated, and some can be specified as ‘starting vaults’ indicating that the player should enter the level/dungeon in that vault (if present).

Mac demo ready

This took a ton of work, but is done enough to post a demo. That’ll come out shortly. I’ll also update the Windows demo as well.

iPad demo ready

This took even more work, but the iPad build is functioning and up on TestFlight. This wasn’t done to get people to use it (TestFlight’s a bit too much work for folks when it’s just a tech demo), but I instead did it to ensure that I’ve got things set up for when it is demo-worthy. That said if anyone’s interested in checking out the demo, let me know and I’ll figure out the right steps to get it set up this weekend (the process of getting device ids and what not is not yet clear to me).

Torches and player lights

Before, players had a single static light source but the plan was to make light more of a resource; comparable to food in a regular roguelike – something to be hoarded, stressful when without, a blessing when found, and skills which improve it are much sought after. In that vein, players now have a very small amount of “inherent” light. This amount might change based on character or race (imagine some races being weaker but having more inherent light enabling quicker escapes).

Here’s a character with their inherent light:

Players also discover light sources as they play the game – different sized torches, magic weapons, etc – and skills which cast persistent light for them. Here’s the same player with a small torch equipped:

The challenge is that torches slowly run out of light over time. So as your light goes from the above picture to something closer to the one above it, things get more and more desperate because you get almost no warning that something’s going to attack. This’ll also provide an interesting min/max variable as skill and weapon choices will require tradeoffs between more light or more powerful attacks…

Lights Flicker

Lights now flicker randomly which gives a good dungeony feel to things. I’ll upload a video momentarily which will demonstrate the flickering.

Flamepath skill

Another infrastructure test – I’ve added a “flamepath” skill which leaves trails of flame behind you as you move – a great skill when being pursued by a mob. Thanks to the event/action infrastructure this didn’t require any code; I added this to the xlsx to define the skill:

and I added it as one of the warrior’s starting skills:

and now we have this:

There were a bunch of other minor tweaks throughout the code as well – many bug fixes and little features (such as celleffects which when created by a skill only impact friendly (e.g. “area heal”) or enemy (e.g. “poison cloud”) mobs).

Progress has slowed to a more normal pace with the end of the holidays and return to reality – but things are still moving. There’s a short thread about 7YRL up on TouchArcade – it’s amazing how even a few short sentences from folks you don’t know can keep you seriously energized :).

Here’s what’s new:

Skills in the Skill Selector UI

As players advance in the game, they’ll unlock skills across four categories; three active: offense, defense, support, and one passive. They’ll be able to choose one of each of those categories at any point in time, and on the gameplay screen they’ll have buttons to activate the 3 active skills. In previous screenshots those were just placeholder art; now though it’s showing the actual skills and is interactive.

Here are the hunter and mage skills (the skills themselves are temporary placeholders – this just shows infrastructure functioning:

I’m really looking forward to playing around a ton with creating skills. I’ve defined 10 skills for each of the 4 categories for each of the 4 classes (so 160 skills) and the majority of them fit within the existing event/action system so should be fairly straightforward to add. For example, here are the Warrior skills:

Some of those will change (e.g. I’m probably going to remove the concept of ‘speed’), and I still need to convert those into XML-based Event/Action triggers. And, of course, then comes the balancing act. But that’s all fun stuff to do…

Death

The game prototype is currently harder than intended, so death comes quickly. The previous demo just dropped the player back to the choosegameslot state which was bad for two reasons; (1) it seems like a crash when it happens and (2) it should instead go to the mainmenu state for the player to create a new character. That’s all fixed now with an interim screen that tells the player what happened:

That screen sits there for a few seconds before jumping to the mainmenu state; eventually this screen will do more, including showing stats/progress, and possibly global rankings and whatnot.

Up next:

The above were fairly quick to do – the real effort over the past few days has been getting an installable Mac demo up and running. Between purchasing the Xamarin.Mac license (wuff), the Apple dev license (wuff), dealing with a ton of linker and cert/profile issues, and trying to coerce the Xamarin.mac installer to obey me, it’s been a bit of a slog. But I’m very close now and am the last stage of verification (but alas even that is more painful than it should be). Still: I’m hoping to have the Mac demo up on indiedb (et al) by the end of the weekend. Then I’ll take a look at TestFlight and start figuring out what’s involved in making an iOS demo available more publicly.

I paid a bit of technical debt last night, plowing through a set of bug fixes that I’d previously been avoiding. 7YRL is getting close to the end of Phase 0.3, which as mentioned in an earlier post means that more of what I need to do is the stuff I put off at at the start of the phase; on the plus side, it also means I’m getting close to the start of the next Phase and a slew of new fun stuff to code there (crafting, professions, more class skills, vaults, and more).

In the process of paying down technical debt. I also had a bit of fun with a few new feature additions:

Health bars

Mobs now display health underneath them when under 100%:

Rest action added

Strategy in a number of roguelikes often involves waiting for a mob to come to you so that you get the first hit – 7YRL now supports Resting; it’s visible in the secondary CAB action here:

Hunter, Rogue, and Mage Tile animation sets added

So far all of the screenshots I’ve taken have shown the warrior; that’s because I hadn’t added any other animation sets yet. It takes me about an hour to adapt an existing animation tileset (e.g. from the Warrior) for another mob’s visual for a variety of reasons:

1) I have to create the color tiles for all animations; each Mob currently has 32 animation frames for walking, idling, etc – and that will grow over time)

2) I have to create normal maps for each of those 32 tiles so that mobs are lit correctly. It’s a subtle but impactful aspect of the shadowing system

3) I have to create occlusion maps for each of those 32 tiles so that mobs can be projected into the shadows correctly. This is necessary since I’m using an orthographic projection (you can see the front of the walls but not the other sides), but also so that I can have a more realistic casting of shadows onto mobs. Not that anyone will notice it, but the shadows correctly cast “up” mobs like this:

Above the player you can see a warrior that’s partially shadowed – the shadow casts up from the base of the mob as you’d expect; but that doesn’t come for free…

4) And last but not least, it takes an hour because my artistic skills are limited to technical proficiency with Photoshop :P. Thank God for Oryx, Ails, and others…

Here’s what the current Spritesheets look like for mobs; there are similar ones for items, walls, stairwells, etc:

Color:

Normals:

Occlusion:

side note: the occlusion map is more complex than it looks; each channel is used in the GL shaders for a variety of purposes:

red: 1.0 = don’t cast dynamic shadows on this texel (avoids self-shadowing on mobs at the cost of mobs don’t shadow other mobs)

green: 1.0 = is a front-facing texel (used for ‘upwards’ light projection onto walls/mobs). 0.5 = is a top of a wall (used for lighting tile walls, which is totally different than other lighting)

blue: height from base. Used for orthographic projection of shadows “up” the mob/tile. This saves me a good bit of code in the shader since it becomes a lookup.

So in the yellow blobs above, the blue component is different on each line.

For comparison, here are the color, normal, and occlusion maps for the floor/wall/stair tiles:

Player Death

Players can now die; currently it just blows away the current gameslot and takes the user back to the choose gameslot state, but eventually it’ll give stats etc, and take the user to the mainmenu (since only the dungeon/player should be blown away, not the full gameslot which also stores progression data like skills learned).

Next up

The remainder of my coding time today will go to making an updated video and packaging up a new demo. Tomorrow it’s back to work so updates will likely slow from their recent frenetic (and fun!) pace.

Good progress on more core infrastructure work; it’s almost a playable game now! Here’s what’s new:

Full attack/defend flow

I’ve fully implemented the meleeAttack action, which support dodging, parrying, blocking, and (if none of those happen) dealing damage. All of those are hooked into the event/action system, so they fully support buffs (increase to dodge, reduction to parry, etc) and ItemPowers (which are essentially buffs under the covers). Damage dealt takes the attacker’s wielded weapon into account, and Damage reduction takes the target’s armor into account to determine what %gets through.

The function itself is a bit long; as an example, here’s how Dodging chance is calculated (including Buffs et al)

Actor Emotes are in

I’d like to avoid the typical message log found in many roguelikes; one of the challenges is conveying what’s going on without words. I’m attempting to tackle that in-part with Emotes which appear over Actors. These are either numbers or bubbled-icons; numbers are used to display damage dealt or healed, and bubbled-icons show a variety of information about the Actor; e.g. they’ve just aggro’ed:

or Blocked:

Parried and dodged have similar icons. I’ve opted to not put the emote bubble around attack actions, but may change that. I’m not a huge fan of the visual, but am mostly working to get the infrastructure working right now. The emote have a nice little bounce effect as well and also fade in/out.

When an actor takes damage or gets healed, a number emote animates over their head:

Basic monster AI

Monsters now have aggro state (binary), and when they see the player they chase and attack. The mobs’ visibility is correct (e.g. they can’t see the player through walls), and they move intelligently (using A* to get to the player rather than just moving in a straight line). They aren’t yet smart enough to move around other mobs (just need to figure out how to work that into the algorithm). The code is prepped for future more intelligent AI as well (using skills to attack, pack AI, etc).

Level-appropriate items

Loot items that are dropped are now level appropriate. Each ItemDefn defines a min/max level range for the item to drop at; I now precreate a list of items (by rarity) for each level, and choose from that when picking an item to drop.

Classes now start with equipment

I extended the PlayerClassDefn object to include starting equipment. I can now specify a comma delimited list of items (by itemId) and they’re automatically given to the player on creation; e.g. this:

Good progress on more infrastructure work; it’s almost at the point where there’s a playable game in there..

Here’s what’s newly implemented:

Item Powers

Weapons and Armor can now have up to 3 ItemPowers associated with them. These powers are activated when the item is equipped and deactivated when the item is unequipped. Here’s an example of some ItemPowers:

Those are specified in an ItemDefn using the now-familiar Event/Action XML definition. The first heals ItemPower heals the wielder/wearer every time they hit a target, the second burns the equipper whenever they move, and the third gives a 2.5x damage multiplier when the equipper damages a target. While these examples aren’t very real-worldy, they do demonstrate the flexibility with which I can now create unique/special weapons and armor (without touching code). My current thinking is that there will be many items with ‘standard’ powers (e.g. damage multipliers, stats modifiers, etc), a smaller number of items with ‘special’ powers (e.g. named “Vampiric” swords with buffs that drain life on hit), and later on I’ll also add in the concept of “Item Augmentation”, where a player can add practically any power they want (once unlocked) to any item they want.

Passive Skills

As the player plays the game, they will unlock Skills. Skills fall into one of four categories; Offensive, Defensive, Support, and Passive. The player will unlock numerous skills in each of those categories, but will only be able to “activate” one of them from each category at a time. The first categories are active and triggered when a Skill button is clicked by the player. The 4th category is always active whenever the skill is selected. I’ve added in support for Passive skills, which primarily involved adding Action_ActivateSkill and Action_DeactivateSkill functions. Thanks to the Event/Action architecture, I just add an action to fire the Skill’s Action when a “HasBeenActivated” event is fired on it, and the active skill is now a passive one.

Damage Modifier Passive Skills

These took a bit of work to hook up. The third ItemPower above demonstrates a Damage Modifier buff; they can now also be added as Passive skills. Many of the skills in the Passive category will be Damage Modifiers.

Data-driven class definitions

Character classes (warrior, rogue, …) were previously hardcoded in the code; they’re now defined in the XLS as PlayerClassDefns along with all the other defns.Here’s what that looks like with some test data:

Items of interest:

Each class will start with three starting skills from the aforementioned Skill categories. These are defined by id and automatically hooked up when the character player is instantiated

You can point at any tileset for the character; it doesn’t require anything custom. One of the cool things about that is that it’ll allow me to create classes leveraging existing art for other mobs, and to support things like changing the player’s appearance with little code.

Adding new classes will be very easy now from a coding POV (requiring practically none) – they’ll be a balancing and art exercise.

Over time, I can also easily add the ability to choose the player’s Race if I wish; it’ll largely match the above, with “racial traits” (damage modifiers and other events) replacing StartingSkills.

Here’s what it looks like (for now) when you create a warrior, which per the picture above is now using the skeletonwarrior1 tileset:

All the animations and everything work, which is pretty cool.

Up Next

Up next: I’m going to jump ahead a bit and add in the Attack/Defend flow along with weapons, armor, damage reduction, modifiers, etc; then I’ll ensure items and mobs are added in a level-appropriate way. After that it’ll be implementing some basic monster AI and I’ll have a basically playable game. I’m hoping to get there by the end of the coming weekend (maybe sooner!)