Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1352614 Posts in 62411 Topics- by 54135 Members - Latest Member: richaell

December 12, 2018, 11:51:15 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsCANTATA - Character-driven Empire Building [Advance Wars + Civilization]
Pages: 1 ... 3 4 [5]
Print
Author Topic: CANTATA - Character-driven Empire Building [Advance Wars + Civilization]  (Read 10799 times)
FuzzySlippers
Level 0
***



View Profile WWW
« Reply #80 on: September 15, 2018, 02:52:15 PM »

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.
Logged

bacon
Level 1
*


View Profile
« Reply #81 on: September 15, 2018, 05:53:52 PM »

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.
Logged

FuzzySlippers
Level 0
***



View Profile WWW
« Reply #82 on: September 16, 2018, 06:11:17 PM »

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.
Logged

bacon
Level 1
*


View Profile
« Reply #83 on: September 18, 2018, 09:47:26 AM »


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  Facepalm).


Logged

bacon
Level 1
*


View Profile
« Reply #84 on: September 18, 2018, 09:49:56 AM »

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

Logged

FuzzySlippers
Level 0
***



View Profile WWW
« Reply #85 on: September 18, 2018, 12:42:18 PM »

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.
Logged

bacon
Level 1
*


View Profile
« Reply #86 on: September 18, 2018, 07:19:24 PM »

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 Smiley 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!
Logged

FuzzySlippers
Level 0
***



View Profile WWW
« Reply #87 on: September 18, 2018, 11:35:50 PM »

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.
Logged

bacon
Level 1
*


View Profile
« Reply #88 on: September 19, 2018, 04:56:46 AM »

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!
Logged

FuzzySlippers
Level 0
***



View Profile WWW
« Reply #89 on: September 19, 2018, 01:36:00 PM »

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.
Logged

bacon
Level 1
*


View Profile
« Reply #90 on: September 20, 2018, 04:24:33 AM »

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?
Logged

Devilkay
Level 1
*

Hi! First game-dev experience!


View Profile
« Reply #91 on: September 20, 2018, 07:46:07 AM »

great pixel art!
Logged

Favourite GM Game
FuzzySlippers
Level 0
***



View Profile WWW
« Reply #92 on: September 26, 2018, 03:58:20 PM »

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.
Logged

bacon
Level 1
*


View Profile
« Reply #93 on: October 31, 2018, 08:11:20 AM »

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!
Logged

Pages: 1 ... 3 4 [5]
Print
Jump to:  

Theme orange-lt created by panic