Saturday 24 May 2014

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.

Thursday 15 May 2014

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.

Friday 9 May 2014

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.