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!
