Latest Entries »

Tons of updates

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:

newUI

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:

Screen Shot 2014-02-14 at 9.15.04 PM

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:

gibs

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:

Screen Shot 2014-02-14 at 9.44.14 PM

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:

Screen Shot 2014-02-14 at 9.44.47 PM

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):

Screen Shot 2014-02-14 at 9.46.30 PM

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:

Screen Shot 2014-02-14 at 10.09.25 PM


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:

Screen Shot 2014-02-14 at 10.13.28 PM

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:

Screen Shot 2014-02-14 at 10.15.21 PM

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:

Screen Shot 2014-02-14 at 10.18.19 PM

And lots more…

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

New WIP Video!

Enjoy:

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:

VaultDefns

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:

throneVault

which in the game looks like this:

vault

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:

smalllight

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:

fulllight

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:

flmaepathskill

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

skills

and now we have this:

flamepath

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).

All in all, a fun week or two!

Updates: Skills and death

Oh real life, why must you impose on my precious coding time?  Oh right: the mortgage.

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:

age

 

hunter

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:

war

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:

death

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.

 

With four years to go, 7YRL may have peaked too early ;-).

I guess I correctly gauged the massive latent demand for roguelikes with soft shadows.

New features since the last video include:

  • Attack/Defend flow
  • Actor Emotes
  • Monster AI
  • Item Powers (onequip buffs)
  • Player classes
  • data driven player skills
  • health bars
  • rogue/mage/hunter tiles
  • resting
  • and tons of bug fixes

 

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%:

health

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:

rest

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:

Shadow casting

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:

color

Normals:

normal

Occlusion:

occl

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:

tilesCOlor

 

 

tilesNormal

 

tlesOccl

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)


// First, determine if the target dodges the attack
float dodgeChance = target.Dex * target.Defn.DodgeContributionFromDex / 100f;

// Give the target's dodge modifiers a chance to modify the dodge chance
if (attacker.Events.ContainsKey(EventType.CalculatingDodgeChance))
{
foreach (EventModel evt in attacker.Events[EventType.CalculatingDodgeChance])
{
// The CalculatingDodgeChance Modifier event will modify DodgeChance
evt.ActionInfo.DodgeChance = dodgeChance;
EventMgr.FireEvent(EventType.CalculatingDodgeChance, attacker, attacker, target);
dodgeChance = evt.ActionInfo.DamageAmount;
}
}

// See if the target dodges
if (GameStateRand.Current.NextSingle() < dodgeChance)
{
// Target dodged
target.SetEmote(ObjectEmote.Dodged);
return EventResult.Cancelled;
}

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:

aggro

or Blocked:

block

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:

num

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:

startingEquip

… translates into this in the game:

char

All in all, a good day!

 

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:

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:

classes

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:

warrioor

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!)