Level up!

Asciilands will be, for many players, an RPG and everybody knows that you can't make an RPG without some kind of character progression. Character progression is handled in many different ways in many RPGs and, to me at least, it's what makes or breaks and it's maybe the single feature that has the biggest clout in shaping the way the game "feels". It operates on many levels and shapes the experience vastly more than it might feel whilst playing the game. For example, the character progression system of a game will dictate:

• Whether you feel like your progress allows you to maintain your status as most powerful character in your environment (Diablo 3) or allows you to continue fighting to keep yourself from falling too far behind (late Diablo 2).
• Whether everyone progresses in the same way (Zelda) or whether everyone progresses differently (Path of Exile).
• Whether the player has the ability to completely ruin their own character's chance of survival (Diablo 2) or whether their choices amount to play-style preference and power is always kept at a level that keeps the game playable (Deus Ex: Human Revolution).
• Whether the player progresses by reaching milestones (Zelda) or whether the player progresses by building experience from any source available (Diablo 3).
• Whether your player is the sum of their gear (Diablo 3) or whether your character is the sum of their stats and skills (Diablo 2).
• Whether you are forced to live with every choice you make forever (Diablo 2 before 1.13) or whether you can respec or explore other paths that you haven't invested in from the start (Diablo 3).
• What happens with you level up?

And even between the alternatives outlined in those points, there's a load of middle-ground that's been explored in varying amounts by the game industry.

In some games, respec takes time and effort (Skyrim) but in others it might be instant and free (Diablo 3). Diablo 2 leaves you in full control of your character progression but some quest rewards are permanent additions to your stats or resistances.

So with all those possible directions, what things are pretty much tried and true?

One thing that is seen time and time again is the gentle encouragement to progress down some kind of path or story by making repetition of tasks increasingly unrewarding. Grinding the same area forever is a good strategy in nearly no game. Certainly none I can think of.

Another thing that's often seen is a situation where an enemy that once caused you significant difficulty becomes something of a "cannon fodder" enemy. This gives you a subtle reminder that you are indeed much more powerful than you were even though your daily challenges feel equally difficult. It's a nice, subtle way of reminding the player that they've progressed despite never really being "out of the woods".

Character level is usually what lets you know how far you should have progressed in the game. Dying one hit from everything you encounter? You rushed. Killing everything easily and gaining barely any experience? Move to the next area. It works well and despite the restriction it puts on players, it usually doesn't feel too restrictive. Maybe because you still feel like you can go anywhere you want it's just that the place they want you to be is the place that feels best for you right now. Contrived? So what; it's fun. Skyrim and similar games do things differently with a "world that levels with you" meaning you can be anywhere at any time and the balance of the game will always feel more or less "right".

Finally, what happens when you level up and what does character progression look like? Usually you see:

• The increase in level being its own reward (e.g., unlocking the use of higher quality gear)
• The ability to increase the value of your player's stats
• The ability to unlock new skills or spells, both passive and active

Interesting combinations of these rewards have emerged as RPGs have evolved as a genre. It's also interesting to see different companies' ideas of where they went right and wrong. Blizzard, for example, gave the players of Diablo 2 partial control over their stats (by influencing most stats with 4 key stats) and full control over their skills. A level-up earned the player 5 stat points to allocate and one skill point to allocate. Different player classes benefited from different stats to varying degrees (e.g., +1 to vitality grants a Barbarian 4 life but grants the Sorceress 2 life). Diablo 3, on the other hand, too a big step backwards and a weird step backwards at that: stats were automatically allocated. It's not the automation that makes it weird, it's the fact that stats are no longer something that you care about. They happen entirely behind the scenes. You don't even need to really understand them because the game simply tells you when a piece of gear is better, in what way and by what percentage. They might as well remove the stat system altogether because you can only look at it; you can't interact with it in any meaningful way. Stats became part of the "behind the scenes" workings of Diablo 3 but they still left them on the surface. I'm still not quite sure why.

So what will Asciilands do?

Firstly, let me reassure you by saying that we have a very strong awareness and respect for how badly you can damage a game by implementing character progression poorly. We know that "poorly" doesn't mean something as simple as "difficult", "easy" or "weird" but that "poorly" is a feeling that you get from interacting the the progression system that usually can't be described in only a few words.

This what what we have so far:

When you level up in Asciilands, you increase your character's level and receive a number of "boons". These boons could be any of the following:

• A boon to stats which increases a few stats by some amount (e.g., +5 to strength, +5 to force and +8 to agility)
• A boon to a skill which will allow you to further develop existing skills or learn new skills (both passive and active)
• A boon to technique which allows the player to tweak which stats contribute to which kinds of attack (e.g., the opportunity to increase the extent to which finesse increases the critical hit chance of a sword attack). Technique boons will probably be late-game fine-tuning stuff and somewhat esoteric but I'm interested to see if people catch onto the whole "technique" system or if they tend to just let it work in the background
• Miscellaneous boons that might sharply increase some stats the cost of a mild decrease of some others or the ability to drop your character level in order to work towards a respec

There are many things we can do with this boon system since we're not tied to a format as rigid as "reward the player with 5 stats and 1 skill"; we're simply going afford the player the ability to change their character in various ways.

Here's a bit more on the actual implementation:

As it stands, leveling up gives you the ability to choose 2 boons from a list that grows by 5 each time you level up (with a maximum of 10). These boons will always be a mixture of different kinds of boons and the boons will be based on the way you play during the level that you've just completed. The technique system has been extended to record the frequency of use of each stat. When the level-up rolls around, the leveling system looks at what stats have been used and makes a series of "decisions". Different kinds of logic are built and and more will be added but at the moment it kind of thinks like this:

• The most frequently used stats will be clumped together in a stat boon and medium increases will be offered. This allows further specialisation in the player's current play style.
• The least used stats are potentially being used for a new style of play that the character is trying to break into. Offer a large upgrade to those stats.
• Offer random increases to random stats that fall in between.
• Offer the larges increases to randomly picked stats in exchange for a decrease to unused stats. This will usually be useless but every now and then it will be a golden opportunity to get ahead in exchange for something you don't use anyway.
• Offer skills that make use of the most frequently used stats.
• Offer skills that build on existing skills.
• Offer strong skill upgrade in exchange for unused skills or stats.

etc, etc. Basically: offer the player the ability to extend their currently play style, extend an emergent play style or trade unused skills and stats for boons more useful to the player.

Other things will be thrown in with boons such as stronger and more traditional respec opportunities or other weird stuff that we haven't thought of yet. It should also reduce the concept of "point sinks" when you just dump left over stat points in a semi-useful place or use left-over skill points to upgrade something you'll use as a back-up. If you don't want to upgrade your skills, upgrade your stats twice or vice versa.

Saving level-ups will also allow the player to have a larger pool to choose from and increase the chances of their being multiple strategically appropriate options for their character. There might also be NPCs that can tweak pending boons or other bonuses that tweak the number of boons in the boon pool or something like that. Possibilities!

That's basically where the skill, stat and level system are at right now and it's feeling pretty good to interact with. The challenge at the moment is to make a whole lot of skills to test how their relationships will be determined (e.g., how it will know that a huge fireball is the natural progression from a small spurt of fire and not the ability to summon a spider's ghost or whatever).

Even though content building has been continuing, I don't have a lot of new looking material to share and I don't like to finish a blog post without any pictures so I'll show you how the minimap looks in a more realistic kind of map (GrubTown):

Those who have watched the gameplay video might recognise the town and cave location.

Unstructured and late post

Today's post will basically be an unstructured collection of words arranged by me to describe recent development activity in the order that it comes to mind.

It's been a while since the last post for two reasons: I spent last month's blog time on making that "gameplay trailer" (viewable on the Asciilands facebook page) and this month's one is kinda late just because I've been trying to make very fundamental changes to some of the base functionality of Asciilands and you know how sometimes when you're working on something that you're passionate about and you're scared you're going to get it wrong and it's a huge amount of work and it stresses you out so you just neglect everything until the project feels stable again?

Well that's why this is late.

Oh, I also rebuilt the editor but it doesn't look much different. I suppose it's still news-worthy though, because I'm hoping to release the editor to the public way before Asciilands is released so that people can have the opportunity to make and submit content that will be available in the game right from the start.

The intention always has been, and still is, to release with a decent amount of gameplay but a lot more in the works and to just keep adding areas as we keep coming up with interesting ideas for places and story-lines. I imagine there'll be a lot of moments that play out like "oh, just walking past this cliff in this familiar area that I have already explored and...oh, I don't remember that cave being there...?" and that cave will NOT have been there previously because NEW CONTENT has been added.

So yeah, the editor will kinda be like our "early access" in that you'll be able to test your own maps as you make them and submit them with the hopes that we'll be able to include them in the world at launch (or maybe soon after).

Other developments in bullet point form:

• Missiles! It had to happen eventually and the current build has missile attacks that set guys on fire or slow them down or whatever else. There's a lot of scope to take the missile system in all kinds of directions so I'm looking forward to experimenting with different missile-based attacks.
• Combat developments! Combat has been a major focus of a lot of development. I'm trying really hard to make it feel "right" when attacking in different ways. Slow but hard-hitting attacks need to feel worth the required focus on timing; weak but fast attacks need to feel varied and not too "spammy" and there need to be sufficient advantages and disadvantages to both so that an actual meaningful decision is made by the player on what kind of combat to employ.
• Level differences! If you're level 14 and you're attacking a dude who's level 20, he'll probably beat you...but why? And what actually changes about the dynamic of the combat? - actually I might give this its own paragraph...

...that's better. Right, so what does level disparity actually mean in a practical sense? For all the experience I had with games that involve enemies of different levels, all I really knew about the paradigm was that if you fight something of a higher level, you will fail. Now there are two kinds of failure in combat because there are two victory conditions: kill your enemies and don't die yourself. This means that failure could be death but that's too obvious and, I find, too frustrating. This is why, at the moment, level disparity will be focused more on making it hard to win instead of making it easy to die. I feel like this is appropriate for Asciilands in a way that it might not be appropriate for other games. Here's why: Asciilands is a grid-based collision-detecting land of peril. You occupy one square but it's a fairly low-resolution grid. For a lot of areas, you won't simply be able to run past guys.

Ok, more context: Borderlands 2 was a most enjoyable game but it handled level disparity in combat with near-certain immediate death and drastically reduced capacity to harm. This made sense for borderlands because it's fairly small enemies in big wide open spaces. If running past enemies was a feasible alternative to combat, you'd be able to just go wherever you want with no consequence.

Asciilands is more crowded and running away will usually be an option but running past? Probably not so much.

What's my point? Well, for how many times I had interacted with a system penalising me for my low level, my awareness of exactly what the numbers were doing (or indeed what they SHOULD be doing) was very superficial and basically came down to "don't fight that, you'll die". When trying to design a fair penalty for under-leveled combat, I didn't really know where to start. I started anyway and all kinds of crazy things happened, there were a lot of one-hit kills and numbers got a whole lot of tweaking but it basically ended up like this:

Fighting something leveled higher than you means...

• Reduced chance to land a hit
• Reduced chance to do your full damage potential
• Reduced chance to dodge their attacks
• Increased chance of your enemy landing a critical hit

Basically, if it's bad it's going to happen more; if it's good, it's going to happen less. Something that I found accidentally good about this system was that it meant that fighting something above your level still felt fair. When I played Borderlands or Diablo II, you get destroyed very quickly and easily by enemies higher than you. You can't hit them and they seem to do tremendous damage and I never understood why or how they did so much extra. With this system, there is extra damage being done but it's done in the form of raised averages for putting incoming attacks up the higher end of the attack-damage bell curve.

Obviously this will be subject to change and we'll have to see how it goes but the plan is to have the world level with you for the most part (with some areas having minimum or maximum levels) so huge disparity should rarely happen.

Also here's the map I use for testing level balancing in combat:

Now this map is special: I didn't actually lay it out. This is the first map to be procedurally generated! For this map to build itself, I just need to put in three things: a list of enemy types, the minimum level and the maximum level. The map then created enemies of every level between the given limits and conveniently imprisons them in their own numbered cell.

It's tricky and good to know it's possible but I don't know where or how procedurally generated maps will fit into Asciilands. Time will tell!

I'll leave you now with one more thing: Autumn is coming to Asciilands for no reason except to test the mass colouring of world assets:

Obviously changes to the tiles would be needed to finish the effect but seasonally altering the world is definitely something we'd like to do and when orange trees are as easy as changing one hex value, I don't see why we wouldn't!

Out on the tiles

There has been an obvious need for a particular feature in Asciilands for some time now and just recently, in my third attempt to add it in, did I manage to actually get it working. The feature is this: objects that occupy more than a single tile.

Needless to say it'd add heaps to the game: enemies of different sizes and shapes, interesting projectile types etc. It's a strongly set gaming paradigm: you're trawling through a dungeon killing spider monsters then you enter the wrong room and a HUGE spider runs at you. You immediately associate the increased size with greatly increased threat and you either slam a potion or run off.

We needed multi-tile objects in Asciilands but I was surprised at how tricky the problem was to solve in a satisfactory way. By "satisfactory" I mean "works efficiently and is easy to implement over and over again as Uli and I build up the amount of content in the game". A working solution that ends up being a paint to apply to the content isn't a satisfactory solution.

So why was it so tricky? What could be so hard about moving two things instead of just one? Why can't you just stick another sprite on the side? Let's revisit exactly what is happening when something moves in the Asciilands grid:

Go experimental comic-style-diagrams!

 This has all been explained before but it'll help to have it in your mind if you want to understand the more complex interactions between multi-tile objects and the environment.

And, of course, collisions between objects:

This was how everything worked until recently. To make bigger objects work, there has to be something in each of the tiles that the big object occupies. These things also have to be "connected". They have to move as one, they have to collide with other objects as one, something that collides with one part of the object must, effectively, collide with all parts of the object. Also if only part of the object collides with something impassable, the other parts of the object have to forego their movements. It was tricky and here's how the successful attempt went:

So then the concept of "object constituents" was born! Constituents are very light-weight objects that aren't capable of the complex interactions that go on between other objects. They can't move, they can't collide, they can't be collided with. All they can do is appear, disappear and refer events to their "owner".

If you collide with a constituent, the constituent acts like a receptionist who then forwards the event to the "owner". The fact that the moving object and the owner object aren't adjacent doesn't matter; the constituent creates the connection and collision can take place in code.

Here's how an object with constituents moves:

Yeah? See how the constituents don't move? They get destroyed and remade. You see, the constituents are stored inside the object and filed away based on the grid co-ordinate offset that the constituent should have in relation to the object. This means that the object can always know where to place a constituent and where to look when it's trying to clean the up before a move. It's also how the object gathers the information on which tiles to collide with when it's doing a collision check for each and every constituent.

If it's not making sense, don't worry. It's hardly making sense to me and I'm writing this thing.

What happens when you collide with a constituent? I'm glad you [didn't] ask!

See this is that referring behaviour I was talking about. The constituent is just a bridge.

All of this happens seamlessly with there being no way to know which part of an object is the actual object or which part is the constituent*.

* Not entirely true; if a large enemy is chasing you, you might notice that it prefers to align one side of its body with you over the other. This is a bit of a giveaway since it will always try to align the owner object with you.

So yeah! That's how it ended up working. The possibilities for enemies has really opened up and it's nice to have a bigger canvas than 2*3 characters to draw a sprite.

If you've actually finished this post, you've done well and deserve a reward. All I have for you is this screenshot of a big object in action and a first look at the now-fully-functional Asciilands quest system!

The quest system is actually far more exciting and easy to understand than all this object collision nonsense. It will also take a lot less explaining. Maybe another post on that soon.

As ever, thanks for reading!

The dreaded stat system

As anyone who has played an RPG knows, the stat system is crucial and a minor flaw in an RPG's stat system often leads to catastrophic game imbalances, exploits or can render the game unplayable when the extremes play themselves out.
While developing Asciilands, we will be making sure that the stat system is well developed and treated to be as crucial as it is to the entire in-game experience. That said, we want a stat system that's unique. I've been trying out a few things and tweaking the resulting systems and we now have something that we're fairly happy with as a foundation and that we're keen to build on so I'll take you through what we've got both as a "have a look if you're curious" type thing and also to invite feedback from anyone with a thought on it.

What not to do

The stat system reached its current state not by coding it down a certain path but rather by coding it away from other stat systems that I've seen in other games that I just think don't work very well.

Here are the things that need to be avoided:

• Too complex
  There are people out there who love a hardcore stat system. They get into a new game, see a screen full of numbers and look forward to a time when they'll understand them all. I am not one of these people and I intend to cater for others who are not like this. That said, these people will also be catered for (if they build their characters that way).
• Too simple
  Diablo 2 had a pretty good stat system; you could control four variables directly, about 10 (?) variables indirectly (via gear or skills) and the rest happened behind the scenes. This was ok but people managed to massively screw it up and with no way to change your past decisions, you could render your character unplayable. Diablo 3 learned from this (sort of); they abolished giving players direct control over stats. This is what I mean by "too simple". Diablo 2 was about balance but Diablo 3 is about massing one of two variable: one to help you survive and one to help you kill faster. The choices are always made obvious to you and you can change them whenever.
• Too unforgiving
  Diablo 2 not letting you alter your stats meant you could build your character into an unfixable and unplayable corner if you screwed it up. This is too unforgiving.
• So many calculations behind the scenes that the stats themselves don't mean much of anything
  When I'm playing a game, I want to see a number and know what that number will mean while I'm actually playing. I want the formulas to be simple and consistent. I don't necessarily want to be able to do all the maths in my head but I want to know for sure what I'm looking at without having to test the changes. In Diablo 2 there was a stat that was affected by dexterity called "attack rating" and it was basically the stat that controlled your chance to hit. I, to this day, don't know how it worked. I could probably find out but that's not the point; it was crucial to gameplay for characters that needed chance to hit but it was never fully explained or at all self-explanatory. All I knew was that you needed as much of it as possible. Fine, but when did I have enough? Can I focus on my other stats now? It annoyed me and partly because I was too lazy to research it but I don't think I should have had to. I played caster characters.
• Ability to create wildly unbalanced stat monsters
  As soon as you stick a multiplication symbol in one of your algorithms (or, if you're feeling particularly crazy, indices), you run the risk of certain numbers reaching great heights, possibly in ways you hadn't anticipated. One thing I was trying to ensure was built in from the start is a "diminishing returns" system (which I'll go into more later).

What then?

Where do you start with that? Here's where I started: Working out what actually needed to be measured and match those things up to a human-applicable kind of stat name. We're all very used to "Strength, Agility and Intelligence" systems and we all know what to expect from that but I wanted Asciilands to be a bit more complex than that to allow for higher character build diversity.

They're a good starting point and in more recent RPGs have been treated more like categories than stand-alone stats. Asciilands will be using them that way along with two others: "Social" and "Magic". Although Intelligence generally control's a player's magical ability in RPGs, in this case it will be a more multi-purpose stat. Intelligence will help you pretty much every other stat if you build your character around it. After all, it makes sense that a more intelligent fighter will do more damage by knowing where to hit, dodge more attacks by identifying where strikes are likely to come from etc.

Social will be more handy for people wanting to play more with the game's economy than the game's world.

What have we got then? Well under those headers, I threw a bunch of sub-stats together. Here's the [ever-changing] list as it is at time of writing:

Woah! Too many? Too complex? Maybe at first but we'll probably go down that well-establish road of only exposing a few to the player at first so as to not overwhelm them. We'll also we working hard to ensure that the game's balance is geared to challenge a character who doesn't care much about the stat system. Someone who does will have an easier time but they will have earned that advantage.

What do they all do?

There's a question with a possibly unexpected answer: most of them won't have concrete functions. The usage of the various stats will be controlled by a system called "techniques". A technique is a method used to determine which stats are used in what parts of the calculations to determine which outcome transpires during whatever event. Different creatures and weapons will have different techniques and techniques are basically a list of stat purposes. At the moment, there are six types of technique: damage, hit chance, crit damage, crit chance, defence and dodge chance.

Let's run over a rudimentary example of a guy using a sword:

Suppose this is what we have:

In this example, the dude will only be using his own base stats and the sword will act only as the technique carrier. In reality, the sword will be adding to stats and the dude would be adding extra variables into the technique but that's too messy for a quick example.

Right so the sword does 80 damage but to determine how much damage actually gets through, we need the dude to be able to amp it up using his stats. The sword's technique variables are a list of which of the dude's stats to aggregate in order to get a "Bias Variable". Also attached to each stat in the technique list is a percentage. This percentage tells us what percentage of the stat is added to the Bias Variable.

In this case, the sword uses Strength, Inertia and Finesse to determine damage. This is how the Bias Variable is calculated:

Now what's a bias variable? Well, in combat, for every calculation there is another calculation to resist it (e.g., damage and defence, hit chance and dodge chance etc.) so the Bias Variables are used to dilute the calculations that they oppose. It's difficult to explain, work with me and it should (might) make sense at the end.

The result here is calculating the dude's ability to deal damage with a sword and the result is "231.9". That means that the Bias Variable for this dude's damage is 231.9 as a result of adding the given percentages of his stats as listed in his weapon's technique list.

For the rest of the example, we'll assume that the target that this dude is attacking has undergone a similar calculation process (but for defence instead of damage) and ended up with a defence Bias Variable of "77".
The two competing Bias Variables are added together and the percentage formed by the attacking compared to the total is then applied to the original damage to determine the total damage delivered.

So the two combined Bias Variables (231.9 + 77) is 308.9 in total. The attacker's damage Bias Variable (231.9) is 75.1% of that total so 75.1% is then applied to the sword's damage taking it down to 60.1 total delivered damage.

If you got a bit lost, that doesn't matter. The best part of this is that once you understand this calculation, you'll understand how pretty much everything is calculated! Chance to hit or dodge and percentage increases and reductions to things are all obtained using this method and all affected by the technique variables dictated by the equipment in use at the time.

Why it's done this way

The key advantages of this system are these:

• Simple
  One calculation is used to modify or determine the outcome and magnitude of all combat related events (and even more stuff down the track [like economic stuff etc.]).
  The formula is actually really simple and only needs to be understood once.
• Diminishing returns
  Since one variable only dilutes the other (instead of directly reducing it or something), the advantages received from adding more and more to a single stat are reduced with each addition. Diminishing returns were a design goal from the start because they're the best way to ensure that:
• You can't just mass one stat and see a linear improvement up and into over-poweredness.
• When you have a stat that's letting you down and requires a bit of quick boosting, the first boost will give you the biggest improvement and the rest can be used for tuning. This means that if you're in a tight spot, you can quickly solve most of the problem and totally seal it off with only a little more effort.
• Diversity
  With the ability to make different stats mean different things according to gear type and character build, the possibilities are endless for how people get the most out of their gear and builds. I'm always frustrated but RPGs that railroad you into specialising and then make it impossible to deviate from that specialisation. Surely if a character is strong enough to use a giant stone hammer, they'd have enough strength to draw a very high damage bow! With this stat system, strength could (and most likely will) contribute to hammer damage and contribute to bow range. It also means we can make the stats make sense to the player without just repeating familiar RPG paradigms.
  In short, it will finally make sense to use a bow and an axe without spreading yourself thin with your stats.

I'm keen to continue to implement this system across more enemy types and weapons. I feel like it'll be an interesting extra layer of challenge to not only keep your stats at appropriate heights but to make your stats applicable to your style of fighting (since techniques will be able to be extended to include more stat types and higher percentages).

Giving the players the ability to specialise in a way that feels right to them, and in a way that helps them create a clever or innovative way to keep their combat strong is something we're keen to do.

So yeah, that's the stat system! Be sure to leave any questions or comments below or on the facebook page!

One year of Asciilands development!

Asciilands is one year old and has just tipped over the 10,000 lines of code mark!

From the very first function written (an AJAX function that renders an array of coloured dots in the browser) to the most recent function written (a function that makes follower NPCs determine whether or not you have enough "personal space" before taking another step towards you) and all the functions that have be re-written in between (probably pretty much all of them), Asciilands has been by far the most fun I've ever had with coding and I think Uli's had an ok time, too.

I just thought I'd briefly sum up what's in those 10,000 lines (in rough development order) and what the next few thousand will contain.

So far we have a grid based ascii ARPG game where you can walk around environments rendered exclusively in coloured text with a combination of tiles and scenery. The maps can feature a variety of objects including pushable blocks, portals to take you between locations or between maps, openable doors, readable signs, talking and wandering NPCs, follower NPCs who follow for you or wait for you at a given location, zombies which can attack and infect the other NPCs, other enemies (e.g., golems and skeletons), collectible items and containers to put the items in. NPCs can also buy your stuff or sell you new stuff for one of any in-game currencies or sometimes they'll just give you stuff for free if they happen to find something in grass as they wander around. Items can boost your characters defence, damage or any number of other stats. They can also set enemies on fire, freeze them, make them run away, explode into a short-range lightning splash damage, have a chance to amp your damage, let you steal live from your attacks or maybe you'll find less complex items like a potion that will restore your health a little bit of a book that has a bunch of text in it. Items can be hand made or generated randomly and their stats are based on the materials from which they are made meaning that you should be able to keep your eye out for useful things based on the materials that best suit your play style.

Soon to come in Asciilands are features like characters's skills and abilities, more robust use of follower NPCs (giving orders or formations), objects that occupy more than one tile at a time (for some bigger enemies), a proper death system, a better economic system, multiplayer, real estate ownership and property development, farming, long distance travel (by boat or cart), time-based events (like day and night / seasons) and of course content, content and more content.

As ever, the blog will be here to keep anyone who's interested up to date on what's going on when major development milestones are reached or something pretty is added.

Thanks for your interest so far in what was year one of Asciilands development!

Token screenshot? I'm working on a new map. I call it "aquecuct.map". Here's a preview taking from maximap.php (that thing that renders the whole map).

I can't promise that we won't do a quest that starts with an NPC saying "Hero, please help us! Our water has gone fetid and..." etc.

Return to The North

The North was a region I first started working on about a year ago, back when Asciilands was still in its infancy. I wrote some code for some tiles and sprites and diligently typed the maps, character by character, into blank text documents.

Shortly afterwards, Jared completely revamped the engine and the map became completely broken. Some elements of the map - like the more muted colour palette and the approach to incorporating caves - went on to influence our approach to Asciilands generally. The map itself, however, was abandoned.

Until now.

I've included some screenshots of my latest attempt at making a snowy region. Some things I'm happy with (the overall feel, the colour scheme), and some things I'm not so sure about (my attempts to soften the border between snow and grass in the bottom screenshot).

In other news, Jared and I have started roughly mapping out the main continent of Asciilands, complete with snowy plains, ragged coastlines, deserts both arid and cold, open fields, forested swamps, waterlogged mountains, and strange hidden red-tinged forests of decaying wood and rotting cloth. One of our primary aims is to make exploration feel rewarding; with any luck the variety of environments will help us achieve this.

The tools behind the development of Asciilands

Although the title of this post might be appropriate for a biographical piece of Julian and myself, this post will instead be about the other little web-apps or scraps of code that I've written to assist with the development of Asciilands.


Consolation prize

The first tool was the Asciilands Console:

It's basically a separate web page that you run in a separate tab or window and it hooks up to the same session as Asciilands is using but instead of displaying the actual game data, it displays a separate lot of data that is put to one side while the code is running.

PHP can be a tricky code to debug. There are debugging tools available but they can be annoying to set up or a bit over-kill so I just wrote my own. The console lets me litter the code with things like "console_echo('some rubbish');" and then that info will be sent to the console in a colour of my choosing.
The screenshot there shows information about behaviours being registered to objects and the map engine placing objects into the map (showing their class, their name and their coordinates) among other things.

Each frame is separated into its own section so you can easily see exactly what information was yielded from each individual frame (given alternating backgrounds in different shades of grey).

As development has continued, the console has had heaps of features added to it:

Pinning a frame

To prevent the console overflowing and causing the browser to crash, the console self-prunes down to 200 frames automatically. That's about 40 seconds worth of frames if you're being chased by ascii zombies. Since the early frames of a map being loaded have most info in them, we needed a way of making sure some frames don't get pruned out so you can right-click on a frame and have it sit neatly at the top of the console. Hovering over the top banner with the mouse causes it to pop down to later inspection and comparison to the current frame.

Net graph

While the server is processing a frame, it times itself and sends the time data to the console for display in the net graph. Each bar in the histogram represents the render time of a single frame.
Red frames are frames with unhandled errors and the blue frame is the frame that is currently pinned.
Clicking on a bar will scroll the data from that frame into view and right-clicking will pin the frame's data to the top.

The benefits of this kind of information is pretty obvious. Helps to identify bottle-necks or unreasonably long-to-process tasks that might need optimisation.

Commands

Console commands let you make quick and easy changes to the data on the fly.
Before console commands, I used to have to weigh up the time it would take to walk across the map vs the time it would take to re-code the starting location and reset the map data.
Console commands meant I could just type in "go 20 16" and be teleported where ever I like, even between maps.
Every time I found myself wanting to do something repeatedly for testing purposes, a console command was added to prevent needing to chop up the code for testing little things.
"sv_cheats 1" anyone?

Build scrips

As part of the optimisation process - to minimise slow PHP inclusions - there is a build script that basically does the following:

• Load each map in the background.
• Listen to what the map is trying to load (often upwards to 50 files).
• Run through each of these files, strip out the contents and put them all in a single file.
• Save the new concatenated file as (map name).req along with the map data.

That way, when the map is loaded (e.g., testIsland), it only needs to load its .req file (e.g., testIsland.req) and it can get all the code it needs from a single include instead of doing 50 or so.

This instantly cut server lag by about 30% and slowed its growth by about 90%.

There are also a bunch of other build scripts that get run afterwards to keep files up to date that I don't want to have to keep up to date by hand.

You can also choose to strip all the console and debug related lines of code out of the files while they're being processed; no need to worry about leaving debug code behind!

So yeah, that's the console. A watered down version of the console might be left in the game on release and be made accessible as the reward fro some quest or as the special effect on some item or something. I think that'd be a cool way to kinda break the 4th wall and let players have a look behind the curtain if the numbers behind the game capture their curiosity.

Spritely little guy

Sprites were getting somewhat tedious to make and tweak so I quickly wrote this ugly-as-all-hell little tool:

It was just to help me make and modify sprites quickly with a live preview on various backgrounds.

How do you like my flower?

Character map (with 200% more character!)

Character map was my best friend for a while but the more I had to use it, the more its flaws were annoying me. Obvious solution: make a new, better web-based character map!

I call it "CharacterMapTE" (for "Turbo Edition").

First most obvious advantage: you can maximise this one and see them all at once!

This one take the while to load, strangely enough, but here's why: I made it really poorly and lazily but I didn't want to waste any more time on it once it was doing its job.

It basically runs though all possible hex combinations and tries to yield a Unicode character out of each combination in the browser.

If it works, great. If not, fine...it just doesn't work.

That's what the PHP does.

Once that's loaded, the javaScript measures the size of the letter "A" then runs over each and every character and deletes it if the box holding that character doesn't have the exact same pixel dimensions as the box containing "A".

Why do I need to do this?

Turns out there are heaps of characters from a whole lot of languages that web browsers kinda shoehorn into other fonts to make the web more multi-lingual. The bad news is, some of these don't comply with the whole fixed-width font thing and if I used those characters, the grid would get all skews in the rows where those characters are used.

This is how the grid looks before the non-compliant characters have been harvested out:

Gross, right?

Editorial

I made a post about the Editor when I first made it but I think more has been added to it since.

Basically it lets you edit the map without having to mess around with text documents (which is how the maps are stored).

I won't go on about it since there are previous posts about it but it was exciting when making maps went from time-consuming, laborious drudgery to something a bit more fun, efficient and visually rewarding in real time.

I wrote this and really only used it in a testing capacity before handing it over to Julian to mess around with and he went and built desneForest (that map in previous posts with the giant mushrooms etc.).

Hew is now insanely fast and skillful in the use of the editor, it's kinda weird to watch; he could teach me how to better use the tool I wrote.

Call it, friendo

OddsTest.php does one thing: tests the "luck" variable.

Luck, in Asciilands, will be a little variable that you character will have that you never get to see; you'll only ever know whether it's good or bad. It'll come into play whenever something happens that uses random chance with a "measurably good or bad outcome". When this happens, your luck variable will get in there and skew the results in or out of your favor depending on your luck.

If you're going head to head with someone else, their luck will skew it, too.

Odds test is a series of graphs that randomise numbers in groups of thousands while spiking the odds with different amounts of good and bad luck.

It's basically a balancing tool to make sure luck give a balanced advantage or disadvantage to players who wish to try to make the most of it.

Living in a material world

For those who read about how the material system works, here is a nice data grid with all the information you'll ever need about the materials:

As more and more materials are added to the game, this grid will fill up nicely.

It's there to give all the information needed to compare the materials in a meaningful way and to keep them balanced.

It lists the materials along with their type (e.g., Iron is a type of Metal).

It then shows all the stats that materials can have and multiplier to that stat that will be applied by the presence of the material.

The coloured cells are used to compare materials to other materials of the same type:

• Numbers in blue cells are numbers that are taken from the material type; not the material itself (e.g., all fabrics add to agility therefore canvas adds to agility).
• Numbers in yellow are assigned to the material itself (e.g., golds adds to magic but other metals don't).
• Numbers in red and green cells are numbers that are present on the type of material but different for that specific material (e.g., gold offers less resilience than other metals). This makes it easy to balance materials against other comparable materials rather than in an absolute sense.
• Numbers with red glowing borders will be forced onto an item (e.g., metals will always add resilience to an item).

Going forward, this will be a crucial page to keep items balanced. All stats on all items are affected by the materials in the items so that players can decide what to keep or what to discard based on what it's made out of. This means material balance will underlie the game's balance as a whole.

This chart will probably be made available on release, too. There's a lot of useful information in here for the number-crunchers.

Well that's them! I'm sure more will get added to the list as more features get implemented but these have seen us through development so far.

Interface interference

I'm here to talk about the recent rework of the interface - specifically the two side wings that report all the information about the game.

More and more information was being generated and reported so naturally it had to be expanded to cope. I knew a time would come when the wings would have to be swapped out entirely with a more flexible system and that change has now been made. For context, here's a before and after:

Before

After

Most noticeable at first is that the new interface is black and dark. Then you might notice that style-wise, it looks like more of a step backwards; the brick effect is gone and there's no real attempt to decorate it in any way - it's purely utilitarian. Then you might notice the fact that the new interface not only has collapsible panels but tabs. It's the tabs that were most vital to the change. It allows information to be spaced out and separated in ways that make a lot more sense.

So why did I go with all black? Let me show you something:

Diablo 2

Grim Dawn

Path of Exile

Here with have three screenshots from three great ARPGs and they're all currently showing details about items. There's a lot to look at so they chunk information by colour. I didn't notice until I was working on Asciilands but the backgrounds are always either darkened or made black before presenting text where colour is an important part of the communication. As soon as I did notice, howver, the reason became very obvious.

Here's something:

That's a quick little chart of how the same colours of text look on the old background and the new. As you can see, the reds and blues start to look much darker much sooner than the greens and yellows and this difference is very apparent on the lighter background. It's also just unpleasant on the eyes.

Sure, it's always nicer to read black text on a white background but this isn't like reading text. Colour matters and colour pops much better on a dark background.

The other point that I touched on but didn't elaborate on is the backward step in style.

Asciilands has a rudimentary text style so to keep it looking and feeling consistent with itself, I have to take care not to make things look too good. I think it looks better when it looks more thrown together within the limitations of DOS or something. Feels more like an old style game with newer style ideas. Slight future modification won't be out of the question...maybe even skins? I don't know.

Anyway, that's the new interface and the reasons behind it!

Building and Polishing the Jungle-forest-swamp

denseForest began as an attempt to make a swampy area. When that didn't progress particularly well - travelling big wet fields isn't actually very exciting - I started working on a woodlands area instead. When the woodlands ended up looking fairly bland, I mixed in some of my work from the swamp with some jungle vines and Mayan-style temples, and the area started to feel like a place worth exploring.

I think there's a lesson here: mixing together common tropes in uncommon ways can create things that feel greater than the sum of their parts. Many of my favourite films and TV shows did just that. Firefly combined science fiction with a Wild West feel, Awake combined a police procedural with an exploration of grief and travel between alternate realities, and Cube combined the genres of low-budget sci-fi and horror with maths puzzles, philosophical musings and an extraordinarily poor script. The rule seems true of videogames, too; Dead Space earns its unique atmosphere through combining sci-fi and horror clichés. To me, the Asciilands jungle-forest-swamp feels much more interesting (and unexpectedly cohesive) than any of my attempts at making a jungle, forest or swamp.

The first problem came up when somebody with an uncommon form of red-green colourblindness tried to play the map.

The map is primarily made up of grass, trees and water. While I could easily tell apart the shade of green used on the grass from the shade of green used by the forest, they differed only in hue. Take away the ability to distinguish between this subtle difference, and the map ends up looking like this:

To say the least, this makes the forest tricky to navigate. This is especially obvious at the top of the image, where it's nearly impossible to tell at a glance where the grass ends and the treeline begins.

Of course, there's a quick fix - just make the grass darker and reduce the strength of the filter used to make the map look darker and murkier. In the long term, we will have to keep the darkness of different tiles in mind to make sure that Asciilands is playable even with colour vision deficiency.

The revised tileset

This wasn't, however, the only problem.

The layout of denseForest started out looking like this:

The Original denseForest layout

You would begin on the part at the top right corner. The various temples all ended up in the same chamber, allowing for quick travel between locations in the area.

Naturally, there is a secret passage behind the waterfall.

Yet even though the layout of the map was fairly simple, playtesters would spend a lot of time backtracking, getting lost, and having difficulty realising exactly where on the map they were and where they had or hadn't visited. The problem was that most parts of the map looked the same as most of the other parts. You walk by similar rivers, through similar swamps and between similar trees, occasionally coming across similar temples.

One particular problem players had was a sense of disorientation on exiting the temple; each of the temples and surrounding areas looked very similar. To fix this, the next draft of the map was bigger and more complex, but also adjusted to make each area and each temple feel a bit more unique:

The updated denseForest layout

You still spend a lot of time walking by rivers and through forests, but there are more points of interest than before. There are overgrown, ruined temples, more variety in how temples are built, more variation in elevation, and more routes to quickly navigate the map. The water at the south of the map has been set below the grass, helping distinguish it from the rivers further to the north:

The temples have been reworked to make each a little more distinguishable from the others:

To make it obvious that the waterlogged swamp tiles can be traversed, you are forced to walk over some near the beginning of the map to access the rest of the area:

Finally, there's a new cave that you can pass through to access an area that would otherwise have been blocked off:

Of course, much remains to be done. The area as it exists in the moment is just a blank template to be tweaked, adjusted and populated with NPC's, enemies and loot when we begin putting together the full game. But in the meantime, the Asciilands world has become a little bit bigger and a little more varied.  

Items: material posessions

This is what I've been working on since the last post: Items with a focus on equipable items (aka., equipment). The work being done at the moment will be the foundation of the Asciilands loot system.

What do you mean "loot system"?
Pretty much all RPG games and most story-driven action games have items and some kind of loot system. Items can work in one of two general ways:

Focus on consumable items
Games like Half Life have about 10 - 15 guns (which are by far the most exciting items to find) so they need to be spaced out over the course of the game. Every time you play you get the same guns and every who plays will have the same experience using them. Most of the items you collect in the game are consumable items like ammunition or restorative items.

Focus on boundless loot
Games in this category tend to be referred to as "loot games", probably because the experience of gaining access to, and finding additional, better loot is what keeps the game's momentum going in a big way.
This describes games more like Diablo where instead of having about 15 weapons, there are literally millions. This is because the stats are procedurally generated, usually within tiers.
A strong example of this, and the one I've been keeping in my mind while I work on the Asciilands item system, is Diablo 2. There are countless possible gloves that you might find in the game but that doesn't mean you need to inspect each kind. They are neatly tiered so you can know which are worth looking at and which are not even worth picking up. Although there are only five different "types" of gloves, once you factor in all the different properties they can have as well as all the different values that those properties can hold, you begin to understand how a game can be so strongly driven by something that can inject so much variety from what is relatively little content.

Needless to say, Asciilands will have more of a "boundless loot" system. Tiers are important to any loot system so let's take a look at that.

Dropping items in tiers...or...tier drops
Diablo 2 had a clear and basic item tier system: fifteen types of gloves with sequentially increasing stats, countless variants within the tiers but still bound by the limits of the tier to which they belong. Path of Exile, however, has a slightly more complex tiering system: their is an entire set of tiers geared to the needs of each specific class. You are by no means rail-roaded into using gear that the PoE developers think you should use but when you get a feel for the kind of gear that your character get the most out of, you tend to continue looking for gear inside the continuums of your most useful items.
Makes sense? Probably not. For get it then, here's the meat:

This is how we do it
I've been experimenting with a new method in Asciilands; items will be spawned with stats conducive to particular types of characters (with enough variation that you'll find weird items useful for weird builds) however, there will be no sequential tier system behind the items. Instead, there will be a large array of materials that the items can be made out of and the properties of the materials will affect the extent to which the stats rolled on the items will help (or in some cases, hinder) you.

Woah, what? Yeah, it's weird and hard to explain and I haven't seen it done before.
Suppose you were a warrior class. You want an item that adds to your strength and your damage. Some defence would be nice, too. Naturally, you'll be looking for some gloves that add to all these things but if you want to get the best possible gloves for your build, you want them to be made out of materials that are conducive to supporting these stats.

The material system in Asciilands is one that kinda evolved accidentally. Materials will have most of the same properties that items can have but their values will act as multipliers to the items that are made out of them. I'll walk you through an example:

First off, the itemisation engine decides it want to create an item. In this case, a pair of gloves:

Gloves, like any item, can have all sorts of useful properties to improve your little ascii dude in all sorts of ways. The list of properties is rather expansive so I've reduced the list for the sake of illustration.

First thing we need to do is procedurally decide which properties will be affected by this item. This process is not completely random and is designed to boost complimentary properties rather than just scatter-gunning over the entire property list but we're only working with a few properties in the example so that doesn't matter much right now.

In these diagrams, the dice represent where random chance plays a part and the grey blocks are "concrete" or unchanging decisions. In this example, the itemisation engine has chosen the ticked properties to be featured on this pair of gloves.

The stats are rolled and applied to the item before the item even know what it will made out of. The next step is to choose the materials. The materials, like the stats, are not completely random. They need to make sense. Gloves, at the moment, are made of two materials: one for the lining, one for the outer layer. Materials are also categorised in many different ways but gloves look for a few kinds of materials depending on the type of glove. Lining might be light or heavy fabric, outer might be fabric or metal.

Here are the materials for our gloves:

As you can see, the choice of material is random but the properties of each material are unchanging. Also noticeable is the fact that material properties are much lower than the properties on the gloves themselves. This is because material properties act as multipliers*, not increments to the base property.

Also, they sometimes diminish the value or even make it negative. This is used sparingly but appropriately and in ways that make sense. Iron will have very high defensive stats but will reduce agility because of its weight. Gold will have high value but negative electrical defence because of its conductivity etc.

* When I say "multiplier" what I means is "a number that gets messed with a a bit and works with a bunch of other numbers that eventually produce a number that multiplies the base value.

Right, so now we have our item with its base properties and the materials from which it will be made which will make changes to those properties. Iron has strong damage and wolf pelt is good for freedom of movement and protection from the cold. Let's take a look at how the numbers are actually decided:

Right! What? Ok, the only stats that are even evaluated are the ones that are on the item. Iron reduces agility but the wolf pelt boosts it up again, just not as much. Agility ends up taking a negative hit. Fire defence, on the other hand, is supported by both materials and just happened to roll highly on the gloves. This kind of line-up of complimentary conditions will be what makes some items stand out for certain classes.

Ok! So what did we end up with?

A pair of gloves that hoped to be agile and fire proof. Sadly, the materials used were too heavy to be agile but both materials are fairly fire resistant to that part came through well.

Both materials are worth a bit of money, though, so that's nice.

This would be a fairly middle-of-the-road item and probably either sold or discarded unless it was fulfilling a certain need. A lot of loot hunting will be about getting just the right stats rolling with just the right materials to boost them up.

Wait, what about those tiers?
Tiers, as explained earlier, are important when it comes to deciding which gear to even consider using. In Asciilands the full tier system hasn't been worked out yet but at this stage, it looks like a large part of it would be knowing which materials boost the properties that help your build and trying to find gear made from those materials. Base level item will have to be communicated some other way but I feel the material system (And the many, many combinations of item tiers that it affords) is an interesting way to communicate and item's likely properties.

Materials also have colours (which are used in the sprite) and "collector" properties (like "aesthetics" and "mystique") which will make items worth more to some vendors than others. I'll post more about this as those particular systems develop a bit more.

That's it for now! Hope you enj...oh right...screenshot. Let me see...

testIsland.map started getting a bit bloated with a whole lot of test awfulness so I made a new map for testing new features. Goodbye, testIsland; hello, debugMenagerie! It's more organised and conducive to the kind of testing required at this stage of development. The northwest corner of testIsland was created while movement was still being tested and we're a bit past that now.

This is the item room where we can test the things items can do. There's a chest to put them in, a vendor to sell them to and tables to stuff to pick up and test. They'll fill up as more item types emerge and I have no doubt that this room will require many extensions.