Meet Code Baby

I'm just about to finish my fourth year as a full time professional commercial software programmer and, a bit after that, my second year as a hobbyist game programmer. The code I have worked on professionally can be summed up as "data and document management solutions" - about as far away as possible from the open-world style game that Asciilands is shaping up to be. Before I start: when I talk about "game programming" in this post, I'm referring to story driven, open-world style games; not highly-systematic or linear games or minigames.

Here's how my professional programming goes:

1. Client wants to do X and software does not support this action.
2. X is similar to existing functionality "Y".
3. Extend Y to allow the user to perform X.
4. Or add X as a new piece of capability.
5. Test that X works as expected.
6. Test that X works when used in unexpected ways.
7. Document changes made to allow X (lol).

Asciilands programming works more like this:

1. Friend plays a bit of Asciilands.
2. Player tries to do something that they can't do.
3. Player asks why they can't do that (e.g., "Jared, why can't I pick up the frog I just killed and cook it on the fire to recover my health?").
4. There is no answer; only shame.
5. Works for hours to make that thing possible.
6. Make sure all the other systems that work in harmony with the modified feature still work as expected.
7. It probably doesn't but the new change trumps old stability so make it all fit.

The key difference here is a subtle one and that is the source of the rules and the source of the expectations regarding what rules are in place.

With commercial software, the users have expectations - usually that the software will fit into their "workflow". They have expectations on how certain features will work based on how other software will work but when something isn't supported, there isn't a failed attempt; there is knowledge that that feature isn't supported (e.g., they can't print because there is no print button).

The discovery methods for finding features are totally different in Asciilands. Players try to do things that can be done in real life (like cooking a frog) and the measure of success isn't whether the software is able to support their workflow, rather not in such a specific way as is the case with commercial software. Instead, the player expects that their knowledge of the world will help them discover features of a game. Well, world knowledge and knowledge of existing game tropes.

The point is, my friend didn't want to cook the frog because he felt like he needed to or because he saw in the manual that frogs could be cooked. My friend wanted to cook the frog simply because cooking a frog is possible in the real world.

This is an extraordinary expectation to need to satisfy with code.

See, the unique thing about making a game is that the story needs to make sense in order to be engaging but to be fun, the player needs to be part of telling the story. But hold on...if the player is part of telling the story, what am I writing? What part does software play?

Here's some circles with some words in them to help me make my point. If you're simply telling a story, you don't need to worry yourself with how the person receiving the story thinks the story should go. Their input does not need to be received. You can literally just write your story and your story is complete. Anything you want the audience to see or hear or know about, all you need to do is include it in your story.
Software doesn't work like that. Software is about processing what the user provides. Usually with software the user has a desired outcome and one or two steps of that outcome are difficult to perform without the use of software (e.g., I want to draw a perfect circle). I know how to draw a circle but it's hard. Luckily, software exists that knows all the exact rules behind producing a perfect circle and it accepts my input (dimensions and colours) and it completes that workflow for me.

Games need to strike a balance between the two. Games need to accept input but also force some output (often against the will of the player). A game needs to contain content that many players will never see or handle ideas by players that the developers would never have considered.

During the development of Asciilands, I have come to realise that I am not writing a story with my software, I am writing a story teller.

To achieve what video games can achieve with non-code story telling, you'd need to tell the story verbally and allow the characters to take suggestions from anyone listening. You'd have to change what happens in your story on the fly. You'd have ideas that would be discarded and sometimes you'll have to think quickly to ensure that it all continues to make sense.

Since I won't be having this kind of contact with my audience, I need to program a story teller who can sit on a server and do it for me. This is why I'm creating Asciilands: the Code Baby!

I have to teach the Code Baby how the world works in minute detail so that when it comes time for him to collaborate with the players in creating the story that will be Asciilands, the story will make sense, be highly variable, be engaging and be fun to be a part of.

In my highschool psychology text book there was short section that sticks in my head when I'm working on Asciilands sometimes. It was about how children learn about gravity by playing with blocks. They learn that if you want to stack them high, you need to keep them centered on one-another. Tipping towers fall over after only a few blocks. Also if you take a block from the bottom, the whole tower falls down.

To program an interactive experience that is designed to reflect reality, you need to teach the code about reality in terms every bit as detailed as the lessons those children are learning from their blocks. Because of this, I often feel like Asciilands is a baby to whom I must teach the ways of the world well enough that it can feign an understanding that would convince a player that the world of Asciilands can be engaged with in all the meaningful ways that they might expect based on their interactions with the real world.

The mistakes that the code makes on account of incomplete information is also sometimes almost charmingly child-like. For example, when I was writing the code that handles monetary value of items and trading, I "taught" the code a few basic rules:

• Items have different that can be added to or reduced depending on the presence of certain properties.
• Shopkeepers can give you currency for items and can give you items for currency.
• Shop keepers will charge 30% more currency for items.

Three fairly simply rules about how to value, buy and sell items. There's a fatal flaw in there that surfaced one day that isn't obvious at all. It is this: Suppose you have an item worth 5 gold and it has bad properties on it that reduce its value into negative numbers, it might end up being worth -10 gold. If you sell this time to the shop keeper, you have to pay him to take it. Fine. Buy it back and the markup is applied meaning he'll pay you 13 gold to take it back. This means you can buy and sell the same items to the same shopkeeper to get infinite gold.

See how a simple oversight and get totally out of control? Additional rules needed to be added; rules that we might seem so obvious to us that we don't even know how to articulate them.

Think back to your childhood, when you were learning about the world and think of mistakes you made because of systems you only partially understood. I remember being confused about hearing people say they need money. Any time my mum wanted money, she just went up to the ATM and got more. To me the rules were as simple as this:

• Money is needed to buy things.
• If you need more money to buy more things, take some out of the ATM.

It's easy, in the context of the previously described bug, to think of this lack of understanding as a "bug" in my unfinished programming. I needed to learn more about the rules of the world so that I would have a better understanding of these situations. Having that understanding is what allows me to tell meaningful and convincing stories about the world now.

Obviously Code Baby only needs to learn facts about the world that make sense in the world of Asciilands but even that is a huge amount of world rules when you consider that the mere concept of "things being in locations" and "things moving by changing locations" are totally foreign to a computer and need to be taught from the ground up.

The scenario shown in the comics was a true bug however when I was teaching Code Baby how to handle those situations, the lesson looked more like this:

...and that might actually be the largest portion of Asciilands code ever made public.

Last comments:

On the development side of things, here's a brief list of what's been going on:

• Huge structural changes to the code to make the game centered on the map instead of the player (i.e., the code now sees the player as a resident of the map instead of the map as the place that holds the player). This change is necessary for things like map-continuity and multiplayer.
• Fine-tuning various aspects of combat.
• Working out how different damage types will interact (e.g., a frozen enemy will have increased fire resistance and a wet player will have decreased electric resistance).
• Making sure that different damage types actually support different strategies rather than all being a means to the same end (e.g., frozen enemies get frozen in place which is good for melee but enemies on fire run around setting other things on fire so you might want to stand back).
• General balancing and working out ways to make it self-balancing without being stupid.
• SOUND! Asciilands now has sound effects. They're basic and currently only selectively applied but the challenge wasn't adding them in, the challenge was adding them in in a way that makes it easy to add them in for everything.
• Making logical tweaks to behaviours to just make everything feel more realistic (enemies used to chase you always from any distance. They now wander around aimlessly until they "see" or "hear" you whereupon they'll chase you until you get far enough away that they lose interest. Complexity is the spice of life).
• Accidentally added a cool new feature to the editor: you can now play test your map without saving it.
• This happened in the huge structural changes at the top of the list. I guess it's just a consequence of the whole map-continuity thing.

Thanks for reading and stay tuned for more #shitCodeBabySays!

Oh my god, I ate a whole packet of instant pudding while I was writing this entry.

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.