Pre-Order the Early Access of TaleSpire and get access to the End of March Beta
Latest Updates from Our Project:
Just checking in
over 4 years ago
– Mon, Nov 25, 2019 at 11:41:35 PM
Hi folks,
This will be a quick one but there's plenty of additional reading for those who like the technical details
On the asset side of the story, we've been working on base meshes and tools to speed up the asset production workflow. This should give us a boost, especially when making Heroes and NPCs. We are aiming to do a longer update focusing on that in the coming weeks.
One the code side, there has been progress on scripting, pathfinding and a whole bunch of project organizational stuff. I'm now hammering away on the code that handles the boards so I can start making changes (add, delete, etc) using multiple cores. More details and write-ups as this all progresses.
And finally, as promised, the additional reading :)
End of week update - Statefully yours
over 4 years ago
– Wed, Nov 20, 2019 at 11:56:53 PM
Update time! Progress has been very good.
@Ree has kept on hammering away at the building tools from the last update. He’s also been handling lots of behind-the-scenes organizational stuff which whilst not exciting to blog about is as critical to TaleSpire happening as anything else we do.
Jason has been chatting to loads of the backers who pledged at the ‘Help design a ___’ levels and sculpting is in full swing. Very exciting!
I’ve finally broken through the wall of fiddly details that was plaguing my board sync implementation and it’s looking pretty good now. This has freed me up to look at some other tasks that are on my todo list so I’m gonna ramble about that for a bit in this post.
First off I went back to Fog of War. Basically, the task is this:
Take a 16x16x16 grid
In every cube write ‘true’ if there is meant to be fog there and ‘false’ if not
Now take this info and make a 3D mesh that contains all the cells marked ‘true’
And I wanted to make sure we had step 3 worked out.
Now there are a couple of points to keep in mind:
The mesh we need to make needs to conform fairly closely to the grid as we don’t want to see glimpses of anything we shouldn’t
We don’t need to make this look like fog, we just need a mesh we can start working with, we can do all kinds of polygonal and shader effects on top of a simple mesh that will look much more fog-like.
As a great example check out this tweet from @Ed_dV !
Inspired by Sea of Thieves and Sky, I've been playing with opaque polygonal clouds - sphere meshes that have their normals softened and distorted via command buffer. Still lots to work out, but progress is being made! No animation yet, just aiming for a fluffy render first. pic.twitter.com/WVyk7X5p5b
Those clouds are spheres, with lots of magic on top (if you watch the whole thing it shows the spheres without the magic).
Given those two points, I decided a good source of wisdom would be the kinds of algorithms that Minecraft-like games often use. Luckily for me Mikola Lysenko of 0fps.net has written some amazing articles on these techniques along with WebGL demos and source code, what a star! This gave me a huge boost and along with a few implementation tips from other sources I was able to put together a ‘Greedy Mesher’ (the name of one of the techniques) in Unity. Now, this next picture is not meant to be clouds, it was just a test to make sure it was working.
For the coders out there, I also made this implementation using Unity’s job system which allows me to run the mesh generation jobs in parallel across all cores. It’s pretty speedy considering how little effort was required.
That is all on the subject of fog for now but we will be back with more in future.
Next on my list of concerns was interactable Tiles and modding.
We have a bunch of interactable tiles in TaleSpire and this is only going to increase as we open up the ability for the community to make them.
A real pain point when you make a user-driven content game like TaleSpire is that you have no way to know when or where someone will just suddenly throw tonnes of extra stuff for your game to do.
For example, take that side-table in the gif above. There is nothing to stop you dragging out a whole load of tables and the numbers get large FAST. Remember that if you drag out a square with 32 tiles down one side then that is over 2000 tiles that your game suddenly has to handle. They all need to appear on all the other player’s machines quickly and they all need to be interactable immediately.
That means all 2000 of them are running their own little scripts. How do you ensure that they don’t start crippling your game?
Now we naturally knew this was coming and previously we had been making small fast components that would then be wired up using a LUA script (that’s another programming language for those not into this stuff :] ).
It worked but I was still concerned about how it would scale.
There was another thing. Like I said we were using LUA in a weird way, as a way of setting stuff up. I started thinking that that might be the worst of all worlds for users as, for those who like LUA, there are lots of things they would be told not to do and for those who hate LUA, well they hate it :p
Were there other problems? You’re damn right there were!
As mentioned before, we need to keep all of these tiles in sync on everyone’s machines and so the idea of scripts just being able to fire off messages whenever they liked was a nightmare, it could really make the game unstable if done wrong.
Now, this sounds tautological but there are two kinds of state for a tile: State that matters to the story and state that doesn’t. For example, whether a fire is lit or not matters, the exact positions of every smoke particle does not. As long as it roughly conforms all is well.
So it would be good if we can separate these kinds of scripts out from each other so we have a shot at being able to enforce sensible behavior over the network.
So after pages and pages of notes and a lot of coffee, I decided it would almost be worth making our own compiler that suited our needs but we needed
Now, this bit gets technical so feel free to skip to the row of asterisks!
0. I decided to start with only 4 data types: int, float, int3, and float3
1. I use a node graph as the code representation. I’m currently using the excellent XNode but if/when Unity’s new graph UI stabilizes I will probably move to that.
I added code to detect cycles and compute the correct types at each node
2. Walk the graph and generate a tree of IR nodes. This is mainly for convenience but in the conversion, we also pick correctly typed IR nodes in a few specific places.
3. Walk the IR nodes to compute the layout for the stack
4. Walk it again and generate a bytecode that represents the program
5. Do a little cleanup pass and kick the result out as a NativeArray<byte>
6. Write a Job that takes the instruction array, an array of private state and a few other bits and run our little bytecode in parallel.
It took 18 hours to get the first version up and running and the results were promising.
Here is a picture of some nonsense ‘code’
The graph above (whilst being gibberish) can be run for 10000 tiles in around 2ms, which is way slower than it will be but it’s acceptable for a first pass. It told me the approach was worth more work so I took Friday to flesh it out a bit.
Oh, and the language is called Spaghet!
With that we have the kind of script that can be used for the ‘not story critical stuff’ but we still need the other scripts too.
To that end, I’m now working on how to script the state machines that will run the important stuff. Here is a little picture of the prototype I’m currently working on:
Naturally, the look of the graph and the nodes available will be improved too.
Soooo yup, it’s been a good, busy week. I’m going to be working on this and all the code that holds it together all this week. I’m hoping to have the major plumbing done by Wednesday though.
Seeya! Have a great week
More gifs? More gifs.
over 4 years ago
– Wed, Nov 20, 2019 at 12:19:27 AM
First off a little clip of some of the cutaway work we are doing.
This is a WIP of the effect from the other day, re-implemented in to Unity. As you can see we haven't made this play nicely with shadows yet but it's fun to see that we will have the level of control we need for the effect.
Next Jason has another great mini in the works.
More of this fellow when it lands in-game :)
That's all for tonight.
Seeya
It's not heights that frighten me, it is the rapidly ascending floor.
over 4 years ago
– Wed, Nov 20, 2019 at 12:17:56 AM
(Paraphrasing Rincewind the Wizzard)
Greetings!
Baggers is continuing his amazing work on the new backend and Dwarf has started exciting work on the Kickstarter "Help design a" rewards! So this week I'm going to be rambling on about stuff. Stay awhile, and listen. I mean, if you've got some time...
Everything in this update is still work in progress, UI, etc will evolve, so will the features themselves.
Let's talk about the floors.
This past couple of weeks, I've been working on building mechanics, and more specifically, how they should work with floors. We're technically obliterating the floor concept as it existed in the Early-Alpha. That doesn't mean we're removing verticality, of course, it just means that we're trying to embrace it fully by allowing GMs to stack blocks onto each other, not worrying about what is a "floor" and what isn't.
This new solution doesn't come without its share of challenges, however, as there are certain things associated with the previous system that I'd like to maintain. There was also clarity in the last implementation, and everyone could refer to the floor by number, which quickly translated across. Also, this adds a bunch of complexity. Not only in systems written, but a lot when it comes to the (UX)User Experience. What are the" points of interest" on the vertical space?
How do we communicate that with other players? Where should we cut to make this area visible without hiding relevant information?
I'm trying to move backward through my thought process on these experiments, to talk a little bit about why I went down specific routes.
Navigation
Moving around vertically is the first issue to solve. As we now require somewhat free movement on the vertical axis a couple of things has been added. [SHIFT] will be repurposed to move vertically, while a lot of the building tools will be associated with [CTRL] (delete, copy, sample). (The new input system will allow for easier remapping of these, mapping them to separate buttons should also work). I Added double-click to move to a location, working across all 3 axes. There is also a new marker indicator bar that has a slider to move the camera plane up and down. So far this does feel pretty good and answers our question about basic navigation in vertical space. It will require more actual game testing to settle on though.
"Floors" and Indicators
Looking at the above example, it sort of feels like floors are very much still there. But in reality, the markers clicked on to the right are clusters of creatures. That was mainly done to test the system as creatures are not a great way to calculate where markers should be placed. Although players and Game Masters would be seeing the same markers at the same locations, they also reveal quite a lot about the tower to our players. One could have the ones shrouded in fog, hide, but that would be another piece of data for the Game Master to keep track of. A different approach is to analyze the space with clusters of walkable spaces and try to guess what "a floor" should be. Or maybe more appropriately make it easy for the GM to create bookmarks/markers, both permanent and temporary, which could allow for a bit more control. The answer likely lives with multiple of these options.
All of this also makes me want to ask the question of, should players even be able to move between floors which the GM doesn't deem a point of interest. This is a question for another time, however.
Before moving onto the next topic, this solution maintains the nice juicy feeling of moving between floors, but it doesn't fully solve the problem of clarity between Game Masters and players, which is something we'll have to dig into soon.
Visibility, Colliders, and Building
One of the greatest features of the new system, and quite frankly why we needed to get rid of floors, to begin with. Building. Now you're able to stack blocks on top of each other, not worrying if it lines up with our preset "floor" height. We could have kept the floor system, and enabled each floor level height to be defined by the Game Masters. That would make sense if you have a single structure, but if you're at the ground floor of a tavern, you don't necessarily want to flatten the rest of the city. As a result, we've centered the visibility around the Camera target. It is currently set to be a square, which can be moved up and down by using the sliders to the right (might change). Zooming out also reveal all hidden tiles (might also change). This along with our cutout shader we can get pretty good visibility within structures which multiple floors.
I started talking about this great building feature, and then suddenly shifted to visibility. The reason for that is I wanted to talk a little bit about some challenges associated with implementing building with this new system.
(I might on occasion accidentally use the phrase "floor", but what I really mean is a vertical marker, which indicates a vertical point of interest.)
(If you know what raycasting in games is, I'd skim through this next part) I mean, stacking tiles on top of tiles is great! nothing wrong with that, but what happens if you want to furnish a room way down in your tower, or replace a wall inside. The way the Early Alpha building system works is that we just RayCast down the camera, and interact with the first surface we hit or the plane of the currently selected floor. Raycasting is like pointing a laser at something and seeing where the red dot appears, and from that, we can ask for all sorts of information, including the tile/model hit. It should work perfectly still, but the way we hide tiles is actually more of an optical illusion. The laser still believes they're all there. The red dot would still appear on the outside of the wall, unable to see inside. One solution is to remove the optical illusion, and just actually remove the tiles, temporarily. But there are certain benefits to leaving them in place. One is performance. Disabling\Enabling them (or removing them as per my analogy) is costly, but the main reason is. How would we stop you from building/placing tiles through other tiles? Let's say you forget there is another "floor" above yours. It would be good for us to be able to warn you. This is why we went with another feature of RayCasting. Let's call it XRay mode. Instead of hitting the first thing you see. You can turn on x-ray, and ask it to return ALL the tiles it passes through. Now we get a list of all the Tiles they laser passes through, and we can ignore all results with the illusion applied.
(if you do know what Raycasting is and happen to be using Unity. Remember that Physics.RaycastAll & RaycastNonAlloc doesn't guarantee being ordered by distance. This took me a while to discover, despite it being clear in the documentation)
With this approach, we should be able to create a visual indicator when something you're building is intersecting with something hidden. How that should be represented visually is still a work in progress. All of this does enable pretty free building, without having to worry about floors, which has been our goal.
Oh, we've also got a separate, moveable, Build plane, which gives you the option to place "floating" things. As hinted at below.
This is still rather clunky, but it's next on the list. Will post more actual building in my next update.
Final thoughts: I think this covers a lot of our requirements. It is currently feeling pretty good! The main thing which hasn't been answered is clarity across players and GameMasters. Making sure there is a consistent language that can be used for communicating where and what.
Thank you very much for getting this far through the rambles. I apologize for the low resolution on those gifs, I'll fix that for the next update I write.
Till next time, have fun!
TLDR: We got rid of floors in favor of a marker system. This allows free building being able to cut into areas dynamically, and locally. You can now also build things inside of enclosed rooms, replace walls, etc. Still, a lot of work to be done.
Behind the scenes update
over 4 years ago
– Tue, Nov 19, 2019 at 07:07:13 AM
Heya folks,
Recently we've held off putting out an update as most of what we have been doing is either not visual or still experiments. However, it feels bad to be so quiet after so much fun around the Kickstarter so here is a little update.
Work continues well, I've been working on undo/redo and related changes to the data behind the scenes. It's a bit of a palaver to try to explain here but I have written up a dev-log on one approach to one part of what we need to consider. It's a bit technical so don't worry if it's not for you, you aren't missing anything. The short version of it is "man there's quite a bit to consider regardless of how you try to do this" :)
Next up Ree has cut his way through the webs of business work and been able to get back to coding. He's been working heavily on:
Tooling for the new building system:
Having explicit floors in TaleSpire was revealed to be a serious impediment for building large worlds so we have stripped that out. In its place, there is a way to place a temporary plane which you can build on top of. This tool is simply named the 'build plane' and you will be seeing it a lot in the future. Along with the work of building the core functionality, a good chunk of time is spent on making this feel fluent to work with.
Experiments in scaling
As we mentioned in the Kickstarter plan, we need to support the scaling of creatures in TaleSpire. This has an impact on creature movement and general game feel and so work has begun on exploring this feature.
Experiments in off-grid creature placement
This is one thing we haven't talked about before now. Up until now, we have always snapped creatures to the nearest tile when they are dropped. It feels good and works well for a lot of cases. However, we are interested in what it would be like to have an option to allow off-grid creature placement. If we do add this option it needs to be at least as good as the current approach.
It's hard to guess which issues are going to come up without testing so that is what is being done. A creature would still have a tile it is said to be 'in' and it's most likely just the tile whos center the creature is closest to. This could also allow multiple creatures to occupy the same tile.
More news on this as it happens :)
Assets
Outside of coding, there are more tilesets in the works but we have nothing to show of these just yet.
That's all for now :)
Thanks again for checking out these updates. Have a great week!
