next »

[FuzzySlippers]

This looks super cool. Did you stick with CastleDB? I had been thinking of converting over to it and it seemed like a nice way to manage data outside of Unity.

[bacon]

This looks super cool. Did you stick with CastleDB? I had been thinking of converting over to it and it seemed like a nice way to manage data outside of Unity.

Thanks!!  I’m still trying to figure out if CastleDB makes sense for my game. It was nice to build the plugin as a proof of concept but I don’t think my game has enough need for lots of small items that I would implement it with. That said I think if I was to start a new game, I’d probably use it from the start and never look back. It’s a great tool so I may still use it, but in not sure yet! Cantata is also built for modding, so it needs a slightly more flexible data import pipeline than relying on a “master” data file.

So right now it’s a little bit of generic JSON, and a little bite ScriptableObjects. I will say a benefit of ScriptableObjects is that you really can write nice data-specific editors, where as everything you edit in CastleDB looks and acts like a spreadsheet. Custom editors can do simple things like real-time, game specific data validation, which is a nicety that’s hard to give up.

I was reading about Unity ECS stuff and it sounds like it’s moving in this direction, so hopefully in the future we get a nice happy mix of external data management and nice in-editor data support.

[FuzzySlippers]

Thanks!!  I’m still trying to figure out if CastleDB makes sense for my game. It was nice to build the plugin as a proof of concept but I don’t think my game has enough need for lots of small items that I would implement it with. That said I think if I was to start a new game, I’d probably use it from the start and never look back. It’s a great tool so I may still use it, but in not sure yet! Cantata is also built for modding, so it needs a slightly more flexible data import pipeline than relying on a “master” data file.

So right now it’s a little bit of generic JSON, and a little bite ScriptableObjects. I will say a benefit of ScriptableObjects is that you really can write nice data-specific editors, where as everything you edit in CastleDB looks and acts like a spreadsheet. Custom editors can do simple things like real-time, game specific data validation, which is a nicety that’s hard to give up.

I was reading about Unity ECS stuff and it sounds like it’s moving in this direction, so hopefully in the future we get a nice happy mix of external data management and nice in-editor data support.

Yeah Unity is definitely moving away from GameObjects loaded down with Mono scripts. I run a hand made ECS currently but I'm sure whenever Unity's is done it'll be better performing.

I've been tinkering with RPGs in Unity for a couple years and I've come to prefer external data. ScriptableObjects are a huge improvement over prefabs but they are still a pain to manage whether a single scriptable contained many serialized or a directory containing many scriptables. There's also no good way to get a global look at all your data without a lot of editor window scripts. There is also the unintended memory consequences when you have scriptables referencing Unity objects which get a copy permanently loaded when you touch the scriptable (I had some crazy memory problems until I found that out).

So now I keep most of my data outside of Unity and use very simple Unity prefabs just to tether the art/animation/etc to my ECS.

I've been looking at CastleDB and your Unity integration code today and I like it but I think I'd rather avoid the code generation. I think I'll just use CastleDB as a nice interface for editing JSON files rather than a pseudo DB. I'm currently using Excel sheets and Castle seems like a great Excel alternative with JSON flexibility baked in.

[bacon]

Yeah Unity is definitely moving away from GameObjects loaded down with Mono scripts. I run a hand made ECS currently but I'm sure whenever Unity's is done it'll be better performing.

I was at their NYC dev day the other weekend and they went over their ECS system and it seems incredibly powerful. Right now though I'd say the overhead of using it doesn't really suit most games because their emphasis is basically on making spawning 100K+ "GameObjects" performant vs. providing an API as simple as Monobehaviours + GameObjects. They also act strangely in the editor for now, so I'd stay away unless you're running into similar performance issues — especially because I'm sure the API will shift over the rollout period. That said, I'm hopeful!

I've been tinkering with RPGs in Unity for a couple years and I've come to prefer external data. ScriptableObjects are a huge improvement over prefabs but they are still a pain to manage whether a single scriptable contained many serialized or a directory containing many scriptables. There's also no good way to get a global look at all your data without a lot of editor window scripts. There is also the unintended memory consequences when you have scriptables referencing Unity objects which get a copy permanently loaded when you touch the scriptable (I had some crazy memory problems until I found that out).

So now I keep most of my data outside of Unity and use very simple Unity prefabs just to tether the art/animation/etc to my ECS.

Yeah IMO this should be the way games are made, but I think Unity is trying to target a different audience that doesn't run into those problems. I think if you're managing large tables of data, external is definitely the way to go. I wrote the CastleDB thing because JSON seems like one of the best ways, but Unity's JSON support it relatively limited so you have to craft compliant JSON and properly account for it's serialization which... can be a lot.

I've been looking at CastleDB and your Unity integration code today and I like it but I think I'd rather avoid the code generation. I think I'll just use CastleDB as a nice interface for editing JSON files rather than a pseudo DB. I'm currently using Excel sheets and Castle seems like a great Excel alternative with JSON flexibility baked in.

I think this is totally valid! The code generation is basically a total hack. If C# 6 supported language macros like Haxe it would be much smoother, but alas. Since diving into all of this I've also been looking at other JSON editors, but honestly for as wack as CastleDB can be sometimes, it still feels like one of the best JSON editors around. I'm surprised nobody else has pursued or developed the idea (or made something not with nwjs/electron  ).

[bacon]

Also worth posting some progress, I'm working on a new website for the game!

[FuzzySlippers]

Are you doing all the art and the code? I really dig that style. It hits a center point between pulpy scifi goodness, easy to read for gameplay purposes, and still approachable to a wider audience. I think that's a tough thing to pull off in a very stylized game. 

I used some of your code as a base for my runtime CastleDB reading and in case its any help to you I've posted it here. Example usage here. (sorry it's just a chunk of uncommented code)

I'm also wanting to be very mod friendly and I think CastleDB has a lot helpful for that. So I switched where I'd normally use an enum to be a simple index based sheet in CastleDB. Then when other sheets need an enum instead they reference that enum sheet. It comes out pretty well and then users could mod things like stats, vitals, equipment slots, etc.

[bacon]

Are you doing all the art and the code? I really dig that style. It hits a center point between pulpy scifi goodness, easy to read for gameplay purposes, and still approachable to a wider audience. I think that's a tough thing to pull off in a very stylized game. 

Thanks for the feedback, I'm really glad you like the art! While I wish I could claim total ownership of it, the pixel art is done by CobraLad, who lurks in these parts, and the character design is done by another artist who's name I haven't announced publicly yet To your point though, I agree that we really aimed for high-stylization but something that didn't feel too "inside baseball" - something that could resonate with a lot of people while still being unique. I also really owe the character designs to the main narrative guy Roy, who came up with and grounded a lot of the characters in the universe. I'm the lead on design and programming, but I benefit from a great team.

I used some of your code as a base for my runtime CastleDB reading and in case its any help to you I've posted it here. Example usage here. (sorry it's just a chunk of uncommented code)

This stuff is great!!! You should see if there is a way to contribute to the main repo I made. I'm not sure how it would slot it, but just adding runtime reading is a great solve for people who don't need full edit-time code completion.

I'm also wanting to be very mod friendly and I think CastleDB has a lot helpful for that. So I switched where I'd normally use an enum to be a simple index based sheet in CastleDB. Then when other sheets need an enum instead they reference that enum sheet. It comes out pretty well and then users could mod things like stats, vitals, equipment slots, etc.

I've thought about this but was unsure how to implement it from a file system perspective. Are you just loading whatever happens to be in a StreamingAssets folder or something? Would love to know more about your approach here!

[FuzzySlippers]

I've thought about this but was unsure how to implement it from a file system perspective. Are you just loading whatever happens to be in a StreamingAssets folder or something? Would love to know more about your approach here!

Yeah I have a GameData folder in StreamingAssets I import anything with a cdb or json extension. It all gets processed and added to a central dict by sheet name as long as that sheet doesn't already have something with that ID. That way people can add another item to the game by just creating their own json, add it to the directory, and if it has a valid shee" or whatever any entries that don't collide with the existing IDs will be thrown into the game's pool of weapons without needing to tamper with the original content.

I also have a JSON config file that tells the game certain constants that sorta need to be hardcoded but still allows editing (like which particular Vitals stat should trigger dead when it reaches zero).

I'll try to add it in a way that makes sense to your repo at some point. I was also considering tackling level/file/image imports. I have a runtime level editor that spits out JSON but I need to check if the Castle level editor works out better.

[bacon]

I've thought about this but was unsure how to implement it from a file system perspective. Are you just loading whatever happens to be in a StreamingAssets folder or something? Would love to know more about your approach here!

Yeah I have a GameData folder in StreamingAssets I import anything with a cdb or json extension. It all gets processed and added to a central dict by sheet name as long as that sheet doesn't already have something with that ID. That way people can add another item to the game by just creating their own json, add it to the directory, and if it has a valid shee" or whatever any entries that don't collide with the existing IDs will be thrown into the game's pool of weapons without needing to tamper with the original content.

I also have a JSON config file that tells the game certain constants that sorta need to be hardcoded but still allows editing (like which particular Vitals stat should trigger dead when it reaches zero).

I'll try to add it in a way that makes sense to your repo at some point. I was also considering tackling level/file/image imports. I have a runtime level editor that spits out JSON but I need to check if the Castle level editor works out better.

Ah cool yeah I like this approach. I think this is also how Caves of Qud does things. Do you expose your "main" game data in StreamingAssets as well or is SA used solely for external data people load in? I feel like I've sort of felt a tension in this way, like needing to support different load paths for data based on how "exposed" I want my game data to be.

I'm also looking to tackle some runtime image loading, mainly because I don't want people to have to use Unity just to produce a Unity compatible asset. So images + json = new stuff!

[FuzzySlippers]

Ah cool yeah I like this approach. I think this is also how Caves of Qud does things. Do you expose your "main" game data in StreamingAssets as well or is SA used solely for external data people load in? I feel like I've sort of felt a tension in this way, like needing to support different load paths for data based on how "exposed" I want my game data to be.

I'm also looking to tackle some runtime image loading, mainly because I don't want people to have to use Unity just to produce a Unity compatible asset. So images + json = new stuff!

Yeah I think expecting users to download the Unity editor to mod anything is gonna make it unlikely anyone bothers. I use SA for main data as well. I figure if people want to mod-cheat the game no reason to throw road blocks and I sanitize the input so they can't literally break the game. I think I need to eventually add multi-path loading in my config file to support mod bundling.

I'd love to support even more extensive modding via scripting but I really hate lua syntax and don't want to tackle securing c# scripts against malicious uses. If I ever have the time I'd like to look at something like Wren but I'll probably be limited to what you can do with JSONs and some simple plain text scripting.

[bacon]

Ah cool yeah I like this approach. I think this is also how Caves of Qud does things. Do you expose your "main" game data in StreamingAssets as well or is SA used solely for external data people load in? I feel like I've sort of felt a tension in this way, like needing to support different load paths for data based on how "exposed" I want my game data to be.

I'm also looking to tackle some runtime image loading, mainly because I don't want people to have to use Unity just to produce a Unity compatible asset. So images + json = new stuff!

Yeah I think expecting users to download the Unity editor to mod anything is gonna make it unlikely anyone bothers. I use SA for main data as well. I figure if people want to mod-cheat the game no reason to throw road blocks and I sanitize the input so they can't literally break the game. I think I need to eventually add multi-path loading in my config file to support mod bundling.

I'd love to support even more extensive modding via scripting but I really hate lua syntax and don't want to tackle securing c# scripts against malicious uses. If I ever have the time I'd like to look at something like Wren but I'll probably be limited to what you can do with JSONs and some simple plain text scripting.

I do know some people DO do modding through Unity - I think this is how Sky Rogue works and given the amount of mods on the workshop I think that it is tenable for at least some people. But yeah I totally agree, JSON + assets in StreamingAssets seems to be the way.

I also view script modding as a "if the community wants it" sort of thing. You can create a lot with some smart interpretations of the systems I've implemented so it kind of "acts" like scripting, but yeah doing "safe" uploads and whatnot is hard to manage. I think the Cities: Skylines team bundles a compiler and uses JIT and they said that they've only had a few incidents of malicious users, but it's mostly been fine.

I'm also super interested in Wren!! I haven't looked into its interop with Unity at all yet though. Just know that it was chosen to be the scripting language for the Luxe Engine (whenever that comes out). Have you played with it? Does it seem like a solution?

[Devilkay]

great pixel art!

[FuzzySlippers]

I'm also super interested in Wren!! I haven't looked into its interop with Unity at all yet though. Just know that it was chosen to be the scripting language for the Luxe Engine (whenever that comes out). Have you played with it? Does it seem like a solution?

I haven't tried to integrate it with c#/Unity but just playing around with the language I really like it. It solves all my problems with lua so maybe Luxe will make it more popular. If I ever try to integrate it I'll definitely put it up on git.

[bacon]

Small update — getting Fog of War in!






Any unit/building has a Visibility number that determines how far they can see, and any terrain can have a Visibility cost that determines how much it "costs" to look at that tile. This also uses part of a pathfinding algorithm, so high Visibility cost terrains can actually block visibility behind them, something like casting a shadow.

The way the fog is implemented leverages the fact I wrote my own tile renderer, so I'm hijacking the Red channel in my tile shader to indicate how much "fog" a tile should be drawn with "fog". After sampling for the proper tile, the shader multiples the vertex color by the Red channel, so a red value of 0.3 would make any color be 70% more black, hence it getting "darker".

The fragment shader looks like this:

Code:

fixed4 frag (v2f i) : SV_Target
{
    float FOG = i.color.r;
    fixed4 col = UNITY_SAMPLE_TEX2DARRAY(_TerrainArray, i.uv) * FOG;
    clip(col.a - _Cutoff);
    return col;
}

I'm still due for a post on the actual Tilemap render method, but I may make that an actual blog post series + tutorial.

Until next time!

[bacon]

A NEW WEBSITE!

Okay so in non-development related news, I've finally launched the new website!



This is a pretty big deal for me, as the site is now meant to be a living portal into the world of Cantata and I'm looking forward to updating it more regularly with dev blogs, general announcements, and extra goodies.

www.cantata-game.com



FORUMS!

I've also launched a dedicated forum for the game!



For now this is meant to server mainly as a place where people can respond to new announcements, but hope that over time it becomes the destination for the game's community. I'd love it if people who were interested in the game from this thread could join here as well and introduce yourself!

forums.cantata-game.com



THE CANTATA GUIDE!

Lastly, in conjunction with the site, I've also launched The Cantata Guide. You can think of it kind of like a back-of-the-box description of Cantata, existing somewhere between a wiki and the game's manual. This too is a living doc, and I'm excited to slowly flesh it out as I start to say more about what's actually in the game.



Visit the guide here

This all really represents big steps I'm taking in 2019 to start being more public about the game, so I'm excited to see what the reception is. Let me know what you all think.



WEBSITE DEV LOG

For more dev-loggy stuff about this work:

The Website
I built the website on top of a tool called Webflow. It's kind of like squarespace, but a bit more powerful/complicated. It strikes me as kind of a modern Dreamweaver, and has you laying out divs/containers/etc. in a WYSIWYG manner. This also means that you're very much visually coding your site without having to explicitly write div tags and other mundane stuff. I really like Webflow/using Webflow, so much so that I also used it at my day job to build our new site. Working in it is super powerful and has lots of responsive web niceties with things like Flexbox (and now CSS grid) that lets you leverage those features without needing to actually code them.

Another added benefit is that Webflow has this idea of "Collections", which is basically a customizable CMS. This is how the announcements work. The announcements are a collection, and I have the collection placed in the website's pages. When I want to add a blog post, I just update the collection and it automatically appears on the site.



Not only this, but you can also have multiple collections of different types. What this allows me to do is dynamically link one collection element, like an announcement post, to a different item in a different collection, like categories:



Because the announcement item is now linked to the category collection, I can dynamically populate the "related" section on a post's page with other posts that share that same category!:



Note too, this is still all without any custom code! Being able to quickly whip this stuff up in Webflow is part of the reason I chose it. As an indie dev, I don't have a TON of time to work on non-game stuff, so being able to quickly add what I want to in a site in Webflow without needing to really learn CSS has proven a god send.

A note on style: The design of the site itself really pulls from a trend in website design known as "web brutalism". Though my site is far from some of the more wild implementations of brutalism, I do think it may be the first games website to really lean into this aesthetic and seem different than other blog based game sites. I just felt like all game sites looked the same, so wanted to pull from a current website trend and make something that looked unique!

For more brutalist websites, check out this great index here.

The Forums
The forums are running on the popular forum software Discourse. They are self hosted on a DigitalOcean droplet. I set it up using their getting started guide and found the process overall pretty painless. The weirdest thing was probably setting up the mail server backend, which I did not anticipate, but their guide walks you through it pretty well and enough people use Discourse with enough DNS providers that you can pretty easily find guides on how to do what you need to do online.

One cool aspect of the forums is how they tie into the main site as a comments portal. I didn't want a dangling comments account for my site and wanted people who were posting to be true members of the community, so I used Discourse's native ability to be embedded as a sites comments in the Webflow site to achieve this! In addition to standard web tags, Webflow supports the ability to inject custom code into a site, so I just embedded the requisite code inside my site at the bottom of a post, and it works!



Setting up the Discourse forums in general was also really easy, so shout out to the whole team there for building a really great piece of software.

The Guide
The guide may be the weird one for a lot of people, because though it looks like a website (and technically is), it's actually built in a tool called Notion. Notion is kind of a "do everything" too - docs, spreadsheets, etc. - that is so hot right now and frankly I love it.

The guide leverages the ability for a Notion page to be published publicly (with no git nonsense needed), so it means I can easily update the guide and have those changes immediately reflected at the guide's link. Additionally, the guide is a collaboration between the whole team, and is one of the only collaborative writing tools that allows you to write with others, offer comments, style, etc. and have that be reflected on a live website immediately. Most other solutions would have required a post-edit step of pushing changes to some remote git repo and that starting a doc building process, and then... it goes on.

Notion empowers the whole team to easily contribute to the guide, with nearly no overhead or barrier to publishing. They also plan to add custom domains in the future, so hopefully soon it can have a more reasonable URL like guide.cantata-game.com.


And with that I'll bring this post to a close. Thanks for reading! Again, if you're interested in the game, join the forum below!

JOIN THE CANTATA FORUMS

[mystic_swamp]

This pixel art is all so pleasing. Great work!

[bacon]

This pixel art is all so pleasing. Great work!

Thank you! All love to cobralad for the beautiful pixel art. I love how bright the game continues to be.

[bacon]

Okay, big post coming up about some mechanical stuff in the game. I haven't really talked nitty-gritty mechanics, so I'm happy to share this.



Supply

Supply is a weird one because in most tactics game it's relatively non-existent. In larger 4X games it's often abstracted away so that you don't have to manage it as much as you just need to know that it's there. In Cantata however, the underlying design principle is that every system in the game should feel immediate and connected, and as such, Supply, and the management of it, is one of the core aspects of how the game is played. Effectively managing Supply will be a major factor in determining who wins any given match. So lets get into it.

What is Supply?

At the most basic level, Supply is a limited resource in the game that is used build buildings and units. Though I'm calling it "Supply" here, what "Supply" specifically represents for an individual faction varies (and is still being decided!). For the human faction, Supply may very well represent a traditional idea of supply — think boxes of goods and services transported along a route from location to location. For the Alien faction though, Supply may instead be "cosmic energy" — the Aliens pull "Supply" from Shoal and funnel it to their various buildings in order to produce units.

"Supply" then is a catch-all term that describes the in-fiction way that a faction produces and builds inside the game.



Supply Types

Similar to how the word "Supply" is an abstraction, a "Supply Type" is an abstraction used to describe the *what* of a faction's Supply. For humans, Supply Types might be things like "Metal", "Heavy Steel", "Oil", etc. You know, human-y things. For Aliens it may be something like "Cosmic Dust", "Crystal", "Essence", etc. — things that are more space-y and mysterious.

Supply Types are then used to describe the requirements for building any given unit in the game (as well as Supply Lines). For example, a simple Human solider may need 10x Metal Supply and 5x Clothes Supply.

However, all Supply Types are not available at the start of match, meaning you can't just build the best units right off the bat. Instead, access to more "advanced" Supply Types occurs through the building of buildings that produce these advanced types.

What this means is that, through the building of more advanced buildings, you unlock more advanced supply types for more advanced units. This is similar to a "tech tree" in other strategy games, but with the important distinction here that your tech tree has a physical manifestation on the map that itself must be defended.



Base Nodes

But how do you start? Each match, a player immediately has access to a "Base Node". A "Base node", like "Supply", is a generic term to describe the starting building a faction begins with that "holds" all the supply a player has in a given match. This starting Base Node is able to create **Supply Lines** that can connect to other buildings that "accept" Supply of the **Supply Type** the Base Node provides.

So, the human Base Node may give out a generic Supply Type like "Materials". As a player, you want to turn "Materials" into something useful, like Heavy Ammo, allowing you to build a large artillery weapon. The Base node can then build a **Supply Line** to connect to a building that accepts "Materials" and with "Materials" is able to make supply of type "Ammo". That building can then build a **Supply Line** to connect to a building that accepts "Ammo" and turns it into "Heavy Ammo", and so on. It's through these connections that, over the course of the match, you build **Supply Lines** that together form your **Supply Network.** Your Supply Network is the backbone of your military that enables you to produce units across the map.

If a player's Base Node is destroyed, the game is not necessarily over, but players will no longer be able to funnel supply along their **Supply Network** to build any new units. Said differently, if you let your Base Node fall, you better have a backup plan!

Supply Lines

As mentioned in the previous section, supply is transported along **Supply Lines.** Supply Lines are the mechanism by which you you transport supply from one building to another in order to use that supply at the connected building. Though Supply Lines are not physically on the map, they do have the ability to be intercepted by opponents by having buildings in your supply network be attacked or destroyed. More on that in a future post .



Supply is Limited

Every match, players start out with a limited amount of supply. Anytime they build a unit or a building it will cost some number of supply, pulling from this global pool and slowly ticking down the total amount of supply they have left. Once the supply counter reaches 0, you won't have any more supply to use! There will be some things in a given match that may award you with additional supply, but the core idea here is that every match essentially has a timer that players can choose how fast it ticks down. Small, intimate matches may have low supply pools, encouraging quick thinking and action. Large, sprawling games may have large supply pools, giving players tons of flexibility in deciding how to go about the given match.

This means there's a lot of strategy in how you manipulate supply. Do you initially burn a lot of supply to create a mass of units in hopes of overrunning your opponent, but at the expense of knowing you put yourself at a disadvantage in the late game where your opponent will have more supply?

Do you instead hoard supply, holding back using it until key movements of a battle where you can deploy some of your strongest units instead of paying the cost of having an idle standing army?

It's on the team here to ensure that in a given match of Cantata you feel empowered to make these decisions, and have each one be interesting and leave you wondering what would have happened if you decided differently.

I've gone over a lot here, and if you have questions I encourage you comment on this post in the forums! I've also only talked about the high-level idea of supply here, and not really gone into the nitty-gritty of how supply is managed, so look out for more posts on supply in the future. Until then, hope you enjoyed the post and looking forward to saying more in the future!

------

As a reminder, I've recently launched a brand new site! I'd love for you to go give it a visit, join the newsletter, and join the forums! Every little bit helps in getting this game off the ground!

[bacon]

As a small test of the game's modding potential, I recently took a whack at incorporating @everestpipkin's neural net generated tiles into the game and... they don't look that bad! Didn't take long at all to do and mostly meant cleaning up some of the tiles because they weren't transparent.





As you can see in that last image, what's really cool about this is that, as long as the tiles are imported correctly, they slot directly in to the scenario editing system with 0 extra code or modifications needed. This means that anyone that can open paint and draw a tile can build a custom tileset for Cantata and just slot it in!

[Sustrato]

Love these updates!

Your site looks great, very bold design. I saw one minor typo, under "Gameplay" on the guide, the second line reads "Cantata is a tactical strategy game that pulls marries higher scale...".

The Supply mechanism seems pretty intriguing, having resources start out at their greatest and be spent over time, rather than built up over time. I like that the supply chains can be directly interfered with on the map, too. I hope the types of supply and creative and compelling enough to match the great artwork!

Fog of War looks good, but adding tiered falloff (e.g. 70%/90%/99%) to shadows further into the fog would look even better!

Love the art for the COs on the site!

I'm very excited to play/mod this game!