#flatui

TL;DR - We’ve been play testing and iterating a lot this week, crushed a whole nest of bugs, added gameplay enhancing UX features, and you can play soon.

This Week

We made a lot of headway this week - as will always be the case from here on out, we started off the week with a full play through. With multiplayer, the current play time is around an hour, which is great for such a small amount of content. It’s obviously not perfect, but it was super helpful in bringing together a big list of useful fixes and features that were inspired by ACTUALLY PLAYING! Below is a list of these types of fixes that we tackled this week. I know its a bit in-depth, but pretty soon when you all can play, these kinds of lists will be a lot more relevant. In a few weeks, we will have our online development hub community set up, and we’ll start opening up the development - play sessions multiple times a week, discussion forum for everyone’s ideas and questions, and of course, bug reporting.

Previews

Construction

Quit Job on Clickaway brought back

Farms

Die from hunger

Rebalanced hunger/food intake

Bugs

Pink Material Bug Fixed

Underground Spawning Bug Fixed

Hover On Destroyed Bug Fixed

Attack Bug Fixed

Direct Command While In Combat Bug

Building menu / aspect ratio issues fixed

Construction/Settlement Capture

Destroyed building light on fire and are rebuildable

Settlements don’t get destroyed, they get captured and the town is ceded to the aggressing player

Construction is a 1-off task now

Permanently assign builders to town center to automate construction

Hunger bar on characters

Next Week

This next week has a lot more important gameplay features in store. The primary goal for us right now is getting this thing to a playable core - once we have that, you can play, hang out with us in Avalon, and we can collectively move this project forward! Specifically this to-do-before-opendev list is as follows:

Chat

Talk to everyone!

Notifications for attention-needing Avalonians

Starving

New Avalonian

Attacked

Out of Resource

Selection helpers

Select all idle

Select workers at a building

Idle Actions

Walking around town

Defense and town capture balancing

Archer towers

Stronger buildings

Incremental Warfare (destroy archer towers and farms before town capture is feasible by balancing combat numbers)

Fix latency issues when scrolling medium-large distances

This week we are aiming to tackle mostly everything except the defense balancing. If we have time we may get some of that done as well. We’re scheduled to get some tech-talk-time with Improbable this week to work out the latency-fixing-strategy. 

We’re getting super excited about inviting everyone into the development process SUPER SOON - I know it’s hard to wait, but hang in there - we’ll be playing together soon enough!

See you next week!

You didn’t think we’d leave you without a new picture!?

TL;DR - This week’s UI updates gave the game a whole new life - using resource trend stats and chat notifications, the current feature set is finally manageable - it’s now fun and challenging to stabilize and expand your population. We’re moving into combat, and have a lot of design to tell you about :D

This Week

This week we pretty much did what we said we were going to do - UI/UX stuff. The game was hard to manage - the mechanics were all there but it was impossible to tell who was doing what, who was starving, who needed a job, etc etc. We had a large list of possible fixes for these issues, but in the end, we didn’t actually need all of them. Below is a list of features we finished this week.

Grouping Help

Select all workers of a building (left click)

Select idle (i)

Construction sites show percentage on enable

Settlement health increased

Selection across the world

District Stats

Resources

Resource trends

Population

Beds

Chat

Colored Usernames

Notifications in chat

With grouping help, chat notifications, and district stats, the towns became much more manageable and even fun to manage. Using the stats, you can analyze your current output, and move small amounts of workers around to maximize production of certain resources over others.

Design Interlude

Before we go into next week’s agenda, it might help to get some background on our thinking. So as many of you know, Avalon is a city-builder / RTS hybrid living in a huge persistent world. As many of you also may happen to know, this is a genre of game that has been theorized for some time now, boasts a slew of failed projects, and even suffers from existential design problems. How could anything go wrong? Create a giant sandbox world where people can build and go to war (imagine RTS style mechanics) - 2 major issues arise:

More frequently online players out-pace and beat less frequent players

New players are easily decimated by veteran players

This is all falling on top of the fact that even RTS in its current form has a mountain of design failings - there are so many degenerate tactics that hold the game back from real organized strategic war in the first place. The reason I’m bringing this up is for anyone doing your homework, I want to lay out our plan to fix these giant issues. Among games who have attempted this there are 2 major camps

Nerf and slow down combat so much that players have time to react even when not frequently online and make some safe zone for new players

Fuck it (These are just hardcore wasteland games with learning curves worse than DF, no complex emergent systems, and huge amounts of required play time)

We aren’t doing either of those things - #1 is boring, #2 is basically not even an answer. We have a small tweak we think can fix it all: cooperation. Take that MMORTS wasteland you were just imagining and change one simple mechanic - players can start towns together / join others towns / form alliances with other towns (nations). So how do our issues above dissolve? For issue #1, in a world where the sides of a potential battle are not single players but large groups of players in many towns, an interesting phenomena occurs. At a certain nation size, the mixture of hardcore, midcore, and software players start to normalize to the same ratio for all nations. This fixes the frequency issue, and given that the marginal utility of total group size is also capped in some simple way (just make groups unwieldy after a certain point) there will be a fairly leveled playing field for all nations. As for issue #2, in an alliance based world, new players would not only be welcomed but begged to join different nations - they offer more player power, more production power, and fill necessary roles in more advanced player’s skill trees. Say advanced players needed lower level resources in mass quantities to fuel their productions - now huge amounts of new players can be supported in the ecosystem. So what about war? With large, equally matched nations, the sandbox stops degenerating to the classic RTS issues. Imagine a real world scenario where two towns existed for the sole purpose of destroying the other - the strategies you see in RTS wouldn’t be so uncommon. Since the Avalon sandbox is emulating a more realistic scenario - the ongoing existence of large allied bodies - war becomes much more realistic. You aren’t going to war to destroy other players, you’re going to war for resources, for strategic reasons. You have huge alliances that could swing in or out of your favor based on your decisions. When alliances do go to war, it’s not over in 15 minutes - there’s many towns in a large world to attack, occupy, stabilize, and integrate into an ongoing nation. With all these added balances, Avalon becomes free of a lot of issues traditionally seen with these games.

Next Week

Our plan this week is to get combat more balanced, stabilized, and less chaotic. Towns need more protection - so we are going to add archer towers. One of the most unwieldy parts of combat is that your entire workforce suits their job to fight right now. By adding trainable melee units and dipping the health of the normal villagers, we are hoping to fix this issue. Melee units will auto attack, villagers will run inside and hide. Melee units stay at a post, villagers wander around. Attacks will be comprised of melee units and defenses will be comprised of archer towers and other melee units - no one will leave their jobs, and the defense has a fighting chance now. This is the last thing we are planning on adding before open development - so I hope you’re getting pumped to start playing!

Weekly ToDo

Repopulation

Purchase new villagers from town center with resources

We are changing this to tend slightly more towards RTS and keep units manageable

Archery - man workers at posts to fire ranged attacks

Sentry Towers

Archery from Town Center

Melee Training

Barracks - uses resources and guys working there slowly train up their melee skill (stars) and you can take them out whenever

These are the only guys that will auto-attack, they can’t be put in normal work sites (you can still attack with villagers, it’s just not auto)

Essentially, these are our first real RTS units

Weekly Fancy Stuff

In other news, we finally dropped some of those new building models in and fixed the lighting and shadows. Below is a before and after of just the lighting changes - pretty sweet huh?

Then we added the new buildings

Then we made construction models for all of that so no ore white boxes on the ground!

Discovering a golden feature is hard, especially when you are building a genre from the ground up, and there’s not a lot to reference.

Basic Weekly Updates

Happy Saturday everyone! We did get stockpiles in, but they kind of opened an unforeseen skill-tree if you know what I mean. To hear more about that issue, head over to the next section. We’ve been working a lot on media-kit type stuff, and doing some art stuff as well - making some moves, trying to ramp up our model production a bit, blah blah. Basically we’re still on track! Now let’s dig in.

Automata Conundum

We say that our dev cycle is longer than it really is - in reality we are always playing our game, iterating on recently built features, and tweaking along the way. Sometimes this is minimal (in the cases where our first guess is pretty good), other times, a mechanics nightmare starts to unfold we would have never expected. So here’s the situation we had.

In your normal RTS, city sim thing, all your AI’s have some centralized register of where this or that resource is stored and how to get it. Using this they can easily route themselves around the town, efficiently using and restocking resources. This doesn’t work in Avalon - you need global and shared automation-spaces. AI’s need to automate inter-player trade, what’s more, one player may have 2 groups of AI’s in different parts of the world - you wouldn’t want your settlers walking all the way back to your capital for a piece of wood. So we needed an intuitive analog to shared resource indexing that worked inter-player and in a decentralized way. 

Our first stab at this was that every AI simply looked in its immediate surroundings for stockpiles every time it needed something. It was simple, seemingly could be emergent - what could possibly go wrong??? It was a nightmare. You could place a construction site down outside of the range of your wood stockpile - wood is right over there, but now you need to automate a who supply chain just to build the building. You could make these survey areas larger, but at scale, this was gunna cost a lot. We had to make an efficiency decision to avoid massive, frequent queries to spatial.

Where we ended with feels natural for Avalon, and it actually solves other mechanics issues that it wasn’t contrived for, so I’m really excited about it. 

Town-Tile Claiming

So in the new system, to automate anything permanent (that can persist and automate while you are offline) you need to place your buildings in a town/district/settlement/whatever you want to call it. You can found a town/settlement by building a settlement/town center building, which automatically claims a certain amount of tiles around it. From here you can only build in the claimed tiles, each building you build further increases land claim. For every building in this district, a local index of storage, etc. exists and AI’s can automate within them. Using stockpiles, you can set AI’s to transfer resources between these districts. Additionally, players within the same town/district can setup automated purchases between each other.

At the same time, this system begins a conception of war and empire building mechanics. The town centers control town automation and basically the AI in them, so capturing a town center is a natural mechanic for conquest. We’ll talk more on these implications later as we unfold exactly how to use them.

So What’s Next

We had to make one of those really serious design decisions this week. When faced with how we are going to handle terrain, we picked isometric pseudo-voxel, and we payed the piper.

The Options

So we had a few options/iterations of ideas for how to handle terrain diversity and height maps in Avalon. We really wanted to avoid thinking about it as long as possible and focus on gameplay stuff, but at a certain point we knew a decision in now is better than a decision later. Here’s some of the ideas we had:

After a lot of toiling, we tried out this last one - the isometric perspective. It clicked with the art style immediately, and became one of those “either we do this or we don’t have terrain at all” ideas. 

Implementing Isometric

Avalon is in 2D - to implement isometric in 2D means to craft up some nasty collision box tricks that let the characters pretend the “cliffs” are actually giant obstacles. This in itself wasn’t terribly difficult. What was difficult was procedurally drawing this at runtime from chucks loading in from SpatialOS. This compounded with the collision trick workaround, a few mesh drawing workarounds, and the fact that we are basically just alluding to height rather than actually having it in the game started adding up. 

Then it was obvious.

In 3D everything would be easier. The isometric terrain could be real, we set the cam to orthographic, and billboard the 2D sprites. In the long run it would be nicer to have physically real 3D terrain - people could rotate perspectives, we wouldn’t be stuck in a corner. However - if we planned eventually to switch our 2D project to a billboard-3D project, we should do it ASAP before the assets cause massive growing pains later on in dev. So we decided to pause our play testing and iterations and switch the project over - not implementing the terrain yet, but at least setting up the project in a way that it wouldn't have to be reworked just to accompany the isometric perspective. 

And That’s All Done!

We dove in. flipped the coordinate plane and updated the raycasting on the selection system to work with Physics3D. The final step was converting a 2D steering algorithm to 3D - if you ever thought trig was;t important, well it was this week. Implemented gravity and a solid ground for the Avalonians to stand on. It was brutal, but it’s all good now - back on track!

Up Next

We really want to upgrade the building system - make it more intuitive, more fun, more... better. We’re going to switch to 3D-modeled isometric buildings locked to the tile grid. Towns are gunna switch from this:

to something more like this:

And that’s super exciting. Kinda worried about the town radius-based building system, so we’re gunna play with that as well after the new building models are in. Hopefully we can get building to feel as good as gathering. Once we’re there we’re going to expand out the types of job buildings and add a sense of urgency through health bars and death on characters. This will start tightening the strings and building some more flow - should be fun!