Archive for January, 2014
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).
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 now flicker randomly which gives a good dungeony feel to things. I’ll upload a video momentarily which will demonstrate the flickering.
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).
All in all, a fun week or two!
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:
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…
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.
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
- 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:
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:
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:
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).
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.