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:02 AM

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



View Profile WWW
« Reply #20 on: August 29, 2016, 06:32:38 PM »

First of all, fantastic art-style. I really enjoy the pixels and the premise of the game looks very nice!

About the graphics, I feel you need a little more variation in the values/brightness, as it is now, everything is a little bit too close in value and it makes hard to see. A little more contrast in the values can go a long way!

keep it up!
Logged

koalefant
Level 0
***


View Profile WWW
« Reply #21 on: August 29, 2016, 06:52:26 PM »

Hey, the unit art looks really awesome! Grin I must agree with some of the comments though, that they look somehow less interesting on top of the terrain tileset. I suspect that it may be due to too much contrast in the background. At least judging by the fact that they look great om some middle grey background.

It is an interesting write-up about L-paths in path-finding with manhattan distances. I am surprised I never noticed it when implementing it myself, perhaps because of the different cost of the terrain it was already twisting quite a bit...

Good luck with the game! I am looking forward to a playable build!
« Last Edit: August 29, 2016, 07:17:33 PM by koalefant » Logged

Working on a turn based strategy: DevLog
bacon
Level 1
*


View Profile
« Reply #22 on: August 30, 2016, 04:11:04 PM »

First of all, fantastic art-style. I really enjoy the pixels and the premise of the game looks very nice!

About the graphics, I feel you need a little more variation in the values/brightness, as it is now, everything is a little bit too close in value and it makes hard to see. A little more contrast in the values can go a long way!

keep it up!

This has definitely been the feedback we've seen most! Most of the images here are just mockups and were made to get at the idea of the game less than what it would actually look like. The strategy we're going for in the long run is to have a single palette for the game, with each faction taking its own discreet chunk of the palette, and the landscape potentially borrowing from the palette as a whole but with value that helps the art on top to blend in. I also think the strategy with the environments will be to have them be a bit sparser, giving the units room to "breathe" across the landscape instead of being swallowed by it and hence generation "noise".

Hey, the unit art looks really awesome! Grin I must agree with some of the comments though, that they look somehow less interesting on top of the terrain tileset. I suspect that it may be due to too much contrast in the background. At least judging by the fact that they look great om some middle grey background.

It is an interesting write-up about L-paths in path-finding with manhattan distances. I am surprised I never noticed it when implementing it myself, perhaps because of the different cost of the terrain it was already twisting quite a bit...

Good luck with the game! I am looking forward to a playable build!

Thank you!  And same as above re the art  Smiley This is definitely all good feedback though! And I'll definitely try to get out test builds when it's feasible and valuable. I'm really interested in itch's refinery process, so I'll probably use that to do some version of private testing for the game, as balancing it will be a herculean task. Also, stoked to see you are a fellow turn-based tactics dev  Toast Left
Logged

eigenbom
Level 10
*****


@eigenbom


View Profile WWW
« Reply #23 on: September 11, 2016, 12:23:43 AM »

Looking good Smiley

One gotcha with Events is that they make things a bit harder to debug as you don't have a call stack and if you rely on an order of events then that gets tricky also. Personally I'd route all event handling through one place in your code and manually deal them out to the listeners. Like if you have a 'Watering' event, make that pass through a Game::handleEvent(...) function, which knows about all plants and deals the event to it. The less the objects know about each other the better. Besides that events are awesome. (I use them in Moonman too.)
Logged

sajidsarker
Level 0
**


View Profile
« Reply #24 on: September 11, 2016, 04:42:04 AM »

Wow I'm really loving your work and the art style! Would eagerly love to play it one day :D
Logged
bacon
Level 1
*


View Profile
« Reply #25 on: September 12, 2016, 05:47:26 AM »

Looking good Smiley

One gotcha with Events is that they make things a bit harder to debug as you don't have a call stack and if you rely on an order of events then that gets tricky also. Personally I'd route all event handling through one place in your code and manually deal them out to the listeners. Like if you have a 'Watering' event, make that pass through a Game::handleEvent(...) function, which knows about all plants and deals the event to it. The less the objects know about each other the better. Besides that events are awesome. (I use them in Moonman too.)

Thanks! Yeah the inability/difficulty debugging events is definitely something I keep in the back of my head and is definitely their biggest drawback. What you suggested is more or less what I'm doing to mitigate that. I've got a single static EventManager class that handles the registration/dispatching/creation of events, so all event calls are "EventManger.Push("SomeEvent", SomeParams)". I've been thinking recently about setting up some debug stuff where I can track who is subscribed to what, because like you said, once they are in code they are kind of invisible, which isn't great as the code base grows.

Something I did discover recently was Unity's replacement for their boondoggled SendMessage() in their Messaging System that works more off of interfaces, which gives you a concrete contract to your event. I'm wondering if I should refactor my code to use interfaces, but then I worry about, by the end of programming, I'll have 50+ interface classes. I know you're a C++ boi, what do you normally do to manage events? I imagine Moonman probably has a fair amount by now.

Wow I'm really loving your work and the art style! Would eagerly love to play it one day :D

 Smiley That's all the artist! His style meshes so well with what I want the game to be so I'm so happy he's attached!
Logged

AaronTooNerdy
Guest
« Reply #26 on: September 12, 2016, 03:19:30 PM »

Isometric Wargame? Sounds interesting. Looking forward to seeing updates to this.
Logged
bacon
Level 1
*


View Profile
« Reply #27 on: September 27, 2016, 08:32:19 AM »

Mod-centric Programming in Unity

Been spending the better part of my most recent game dev tasks in pursuit of one of the main ideas of the game, namely, making it moddable. For anyone that's ever modded a game, you know that there's about a million different ways to go about this, but for indie devs perhaps a bit less, depending on what you want to achieve. My main goals were/are:

1. I want anyone to be able to somewhat substantially mod the game without knowing how to code.
2. The mod toolkit should be easily distributable and portable.
3. I want Steam workshop support.

Achieving all of these is sort of an exercise in compromising, especially in service of the first idea. I wasn't exactly sure how to go about this when I first started programming, but really nailed down the idea in the past week out of necessity. So here's a little about how the system works.

Everything that you can interact with on the play field is an interactable . Think of an interactable as a checkers piece in terms of what it "knows": the board, and the boundary in which it plays, and how it traverses the board, but doesn't have any special "abilities" that dictate how it moves across the board. As anyone who has played checkers knows, this doesn't make for that exciting of a game, and the general idea is much improved with something like chess, which has a similar board, with pieces that all too share a general ruleset, vary in terms of how they operate within that defined ruleset. The mod system I made essentially literalizes this "upgrade" from checkers to chess

Interactables, general like checkers pieces, have the capacity for what is currently called a " core ". Depending on their given core, any two interactables can have vastly different behavior. A Queen in chess can be thought of as a Pawn augmented with a "Queen" core, and so on. Every interactable knows how to interpret every core, but doesn't need to actually implement every possible type of core just to know how to talk to any other one. So modding (at least in terms of interactables) is just swapping out cores.

In terms of the actual implementation in Unity, this comes down to the ScriptableObject system. "Cores" are ScriptableObjects that any interactable can interpret, and add on the required components to itself that make it be like what is declared in the core. The interface for designing a core in Unity looks like this:





This is actually an older version of the builder, and in it's oldness highlights some of pluses of this approach. At the top you can see that there is a dropdown for Unit or (hidden) Building. With this new system, I realized that this distinction is mute, as a building was just and interactable that could be supplied but couldn't move, and a unit was a building that could move but couldn't be supplied. But no longer! Now any interactable can have any aspects (Movable buildings?! Supplyable Units?!), so the rigid distinction of what any type of interactable "was" was abolished. This is great, also really frees up some design possibilities, allowing me and the team to easily mix and match characteristics to better come up with gameplay.

It also makes extending in the future very easy, as adding new dimensions to units (currently called aspects ) means simply making a new aspect for the given functionality and then adding it here. Aspects are not mutually exclusive, and only know about what is relevant to them, so adding new ones can be done in a vacuum without knowledge of the rest of the code base. Aspects are manifested through Components that are added to an interactable at runtime. This is an area I would be interested in opening up to script-based modding as well, but that will come later.

In terms of Steam, these cores can easily be uploaded after created! There are also very shareable, as the ScriptableObject core is just a Unity asset. Adding new cores to your game would be as easy as just subscribing on the workshop, or downloading and dropping in your game folder. I'm doing some deeper "validation" stuff here as well, which will allow you to iterate on other people's uploads, as well as group multiple cores into a ruleset , but I'll get into that later.

So as a recap, interactables have cores that contain aspects . As a small note on compromises here, this (for now), dictates that all modding must be done inside of Unity. I recognize that this may not be ideal for some people, but Unity gives me a lot in terms of easily extending the game (as well as the ability to create nice tools), so I hope people are down with the small barrier to entry.

Lastly, I've really got to shoutout a few things that really put me down this track to modability and helped me get there:

 



 Creating a Moddable Unity Game

 



Thanks!
« Last Edit: May 06, 2017, 08:23:11 AM by bacon » Logged

bacon
Level 1
*


View Profile
« Reply #28 on: October 01, 2016, 03:38:13 PM »

Just a small update post because I'm so excited! I started going down the rabbit hole of making Aspects also be moddable, and have finally achieved it! This means that anyone can now pretty easily build their own aspects into interactables as long as they conform to some code. This is the basic structure of an Aspect now:

Code:
public class CanAttackInfo : AspectInfo
    {
        public int Damage;
        public int AttackAPCost;

        public override void Setup(Interactable attachedInteractable)
        {
            CanAttack addedAspect = attachedInteractable.gameObject.AddComponent<CanAttack>();
            addedAspect.Setup(this);
        }
    }

    public class CanAttack : Aspect<CanAttackInfo>
    {
        public int damage;
        public int attackAPCost;
        public override void Setup(CanAttackInfo data)
        {
            damage = data.Damage;
            attackAPCost = data.AttackAPCost;
        }

        //implementation logic
    }

I'm not a big fan of how you have to call setup in every aspect, but it works for now. I was trying to make it work with Generics but couldn't really figure out the proper implementation with this system, mainly because AspectInfo is... A Scriptable Object! So now you basically just make a scriptable object that has the data you want, plop it into the builder, and then all the logic happens at runtime. A peek at the editor now:


« Last Edit: May 06, 2017, 08:24:20 AM by bacon » Logged

Kris with a K
Level 1
*


It's a good day to die.


View Profile
« Reply #29 on: December 08, 2016, 07:02:14 PM »

Bacon, thank you so much for this devlog! I'm working on an iso game and it's both inspiring to watch your art/design, and educational to use the code samples.

As for the concerns about color palette and scale, first off let me just say brown snow may not be pretty but it feels far more appropriate for a war game than some pure white, fairy tale stuff.

The concern about sizing and soldiers as tall as cliffs is definitely justified, but imho one of the old school appeals of strategy games is the crazy juxtaposition where a foot soldier can occupy the same space as an entire city. It's silly and unrealistic, but I like it. Especially for a grid-based tactics game where 1 unit = 1 tile and you have units sized from single soldiers to strike planes - might as well embrace it.

How much are you and Cobralad working together on the design direction of the art? As in, will the mechanics/story of the game be entwined with the somewhat unconventional armies of alien saber-tusked mammoths and spiderbots?

Now, if you don't mind me derailing your thread a little bit, I have a question about your event queue; specifically, your delegate definition in the EventManager class:

Code:
public delegate void EventHandler( params object[] args );

If I'm understanding, parameters for events are just an array of objects, so you're relying on broadcasters to give the right arguments and for listeners to only look at events relevant to them, i.e. having the same parameters. Is that correct? It seems somewhat dangerous and opposed to the best practice of compartmentalization, although I do know it gets used in a lot of the C# language specs.

Thanks again for sharing the code examples - I am looking into game state management and the event pattern seems really helpful. I've still a lot to learn, but I've never used delegates before today and they're already up and running in my code base! You da real MVP.
Logged

bacon
Level 1
*


View Profile
« Reply #30 on: December 09, 2016, 06:43:06 AM »

Bacon, thank you so much for this devlog! I'm working on an iso game and it's both inspiring to watch your art/design, and educational to use the code samples.

As for the concerns about color palette and scale, first off let me just say brown snow may not be pretty but it feels far more appropriate for a war game than some pure white, fairy tale stuff.

The concern about sizing and soldiers as tall as cliffs is definitely justified, but imho one of the old school appeals of strategy games is the crazy juxtaposition where a foot soldier can occupy the same space as an entire city. It's silly and unrealistic, but I like it. Especially for a grid-based tactics game where 1 unit = 1 tile and you have units sized from single soldiers to strike planes - might as well embrace it.

How much are you and Cobralad working together on the design direction of the art? As in, will the mechanics/story of the game be entwined with the somewhat unconventional armies of alien saber-tusked mammoths and spiderbots?

Now, if you don't mind me derailing your thread a little bit, I have a question about your event queue; specifically, your delegate definition in the EventManager class:

Code:
public delegate void EventHandler( params object[] args );

If I'm understanding, parameters for events are just an array of objects, so you're relying on broadcasters to give the right arguments and for listeners to only look at events relevant to them, i.e. having the same parameters. Is that correct? It seems somewhat dangerous and opposed to the best practice of compartmentalization, although I do know it gets used in a lot of the C# language specs.

Thanks again for sharing the code examples - I am looking into game state management and the event pattern seems really helpful. I've still a lot to learn, but I've never used delegates before today and they're already up and running in my code base! You da real MVP.

Thank you so much for the kind words! Smiley I'm glad you're getting something out of it. I also definitely hear you on unit sizes - I settled where I'm at now as well to be at peace with the notion, but also because I didn't want height to have an effect yet on units. I think that makes the game a bit too crunchy for my tastes now, but maybe in the future!

In terms of design direction, Cobralad did a lot of the initial sprite concepting off of some loose narrative I had developed, as well as a wealth of reference shots I had been grabbing, but that has since been fleshed out by Roy, who has been doing all the actual narrative design. In terms of mechanics/narrative as well, they are totally entertwined. We start off first with the races, then think about what units would make sense to "inhabit" that race from a narrative perspective. Then we actually assign mechanics to what's decided on there, tying them deeply into the theme. This comes out most in COs, who start out as narrative ideas from Roy, who we then craft into having very unique playstyles, even between other COs in the same race. We'll hopefully be making some posts soon more specifically about the races soon - so definitely watch the thread. We also just got a great character artist on board, who I think will really breathe life into the universe we're creating.

No worries about talking about code! You're definitely not derailing. For the EventManager class, you're totally right that broadcasters/listeners need to know/expect the same type of info from each other, even though it isn't explicitly defined in the parameters themselves. More so then that, the parameters have to be casted upon arrival at the Subscriber, which leaves functions prone to improper casting. This is definitely a weak point of the design for the obvious reasons here. If you look in the C# documentation, you can see that the "proper" way to handle this is to send, with any event, a reference to the object calling the event and bespoke arguments that can be referenced/constructed by the subscriber/publisher.

I haven't worked this way yet because I'm not super sure how well it would scale. MSDN suggests that basically every event should have bespoke arguments, but my thinking on implementing this is to have caller-specific arguments (vs. event specific) that a subscriber would then parse to its liking. These args would then encompass anything that something would want to know about the caller. It would still, at its root, has to be generic though to encompass the fact that I am sending almost anything through the system. In the future, it may be best if the parameters were scoped down to at least something like IsoTacticsArgs, but we'll see. This to say though yes, it's not a perfect system. The other way to validate is to just run assertions at the top of functions to ensure you're getting the right args in.

I'm also planning to open source the event system I'm using, so look out for that being posted here!
Logged

bacon
Level 1
*


View Profile
« Reply #31 on: December 28, 2016, 09:24:18 AM »

Small update — after talking to some devs and looking into how other people were doing Unity modding, I think I'm going to keep the actual designing of Aspects "closed", meaning that only the dev team has the ability to make new Aspects for Interactables. I think this also makes sense creatively, as it gives other modders a limited toolset to work with vs. trying to just cram all their intended functionality into a bespoke Aspect. I also think that you would end up getting a lot of duplicate Aspects that do more or less the same thing, but would have different ways to go about it.

This also means though that it's now much easier to "mod" the game because all of the data is just a ScriptableObject, easily passed around as a .asset file for Unity. Opening this end up to modders is easy! I've also changed a bit of how you design an Interactable now to reflect the more static nature of Aspects:



Now you just check/uncheck what you want an Interactable to have and then fill in the corresponding data. This also means that I don't need to try having every the actual data of a given aspect as a ScriptableObject as well, so all the data has just been moved to much simple structs.

On top of that, as I learn more about C#, I'm converting a lot of old code to better C# convention, namely using Property modifers to replace a lot of the getter/setter functionality. I've also added some extension methods to make workin with all the Interactables on a given tile much easier.

Lastly, I was working on some very basic UI to reflect actions that can be performed for a given Interactable based on its Aspects, and built this modular UI system:



It's a single instantiated UI whose available buttons change based on what is selected. For a closer look —



You can see on the right that, depending on what is selected, certain buttons are toggled on and off. Unity's AutoLayout system keeps them all looking well spaced out and in line (for now Smiley )
« Last Edit: May 06, 2017, 08:27:02 AM by bacon » Logged

bacon
Level 1
*


View Profile
« Reply #32 on: January 17, 2017, 08:54:32 AM »

Hey everyone!

In order to stay on track with dev stuff I've started streaming development weekday mornings from ~9AM-10AM EST. If you're interested or have any questions definitely stop by! I try to dictate what I'm coding so you aren't just watching a mouse move around.

Check it out here

In terms of dev progress, I've been getting all the UI working with real values to move away from strictly debug UI. I also worked with the Facepunch Steamworks library and have my game now nominally working with Steam! I did some research into P2P architecture as well, and the way the game is designed will make implementing this pretty "easy".
Logged

pturecki
Level 0
***



View Profile WWW
« Reply #33 on: January 17, 2017, 11:51:20 PM »

I like the artstyle, especially winter theme (with white ground). The game looks interesting Smiley Do You have a twitter for the game?
Logged

bacon
Level 1
*


View Profile
« Reply #34 on: January 18, 2017, 07:24:28 AM »

I like the artstyle, especially winter theme (with white ground). The game looks interesting Smiley Do You have a twitter for the game?

Hey thanks! Smiley I hadn't actually thought specifically of themes but you've given me a good idea. As far as Twitter, nothing yet as the name isn't finalized. Once I'm able to get a name through I'll definitely get one though.

Also, small visual update: got reeeeally basic terrain generation in and am working on a more exact system. It will probably end up being something like the Spelunky generation system plus some of my own ideas. For now, here's a small taste:

« Last Edit: May 06, 2017, 08:27:58 AM by bacon » Logged

bacon
Level 1
*


View Profile
« Reply #35 on: January 22, 2017, 10:02:35 AM »

Still working on getting some better terrain gen in! I've got some basic noise-based terrain in working with a "Terrain" system I'm developing. Essentially, any possible terrain has an array of nine sprites associated with it, one for each possible sprite position. Each terrain also has a given "height index" which determines where it will be placed in the whole "terrain stack". In the picture below you can see how the water "blue" has a lower height index than the ground, which is less than the trees, which is less than the mountains. It obviously needs to be refined and injected with some more randomization (as well as prefab "areas"), but you can see below that the system works! It also makes adding in custom terrain types really easy, as they are just scriptable objects that can be created on command.

« Last Edit: May 06, 2017, 08:28:52 AM by bacon » Logged

Mahn
Level 0
***


View Profile
« Reply #36 on: January 22, 2017, 02:29:10 PM »

I like where this is going, and the in-depth dev ramblings are much appreciated, keep it up! Definitely consider Twitter though, even if you don't have a final name yet you can always go with a codename for now.
Logged
bacon
Level 1
*


View Profile
« Reply #37 on: January 23, 2017, 06:25:23 PM »

I like where this is going, and the in-depth dev ramblings are much appreciated, keep it up! Definitely consider Twitter though, even if you don't have a final name yet you can always go with a codename for now.

Haha thank you! Also for some reason I didn't think you could change your handle, but since you can, I've made a twitter!

Follow here: https://twitter.com/isotacticsgame

Also, definitely let me/us know if you're interested in something specific, I obv love talking about the game.
Logged

bacon
Level 1
*


View Profile
« Reply #38 on: February 02, 2017, 02:57:54 PM »

Got a pretty good Save/Load system into the game over the past few days! I also uploaded the system to a gist you can check out here, but I’ll also paste it here for good measure:

Code:
using UnityEngine;
using System.Collections.Generic;
using System;
using System.IO;
using System.Text;

// Super easy saving/loading of binary data for Unity games
// by @kkukshtel
// License: Do whatever!

public enum SaveType
{
    //Add more types here
    Map,
    Match,
    Options
}
public static class SaveLoad
{
    // Make more properites like this to easily access file names
    public static List<string> Maps
    {
        get { return getFilesOfType(SaveType.Map); }
    }
   
    //Points to User/AppData/LocalLow/DefaultCompany/YourGame/...
    public static string dataPath = Application.persistentDataPath;

    // Add other directories here to indicate where you want to save
    public static Dictionary<SaveType, string> gameDirectories = new Dictionary<SaveType, string>
    {
        {SaveType.Map, dataPath + "/maps/"},
        {SaveType.Match, dataPath + "/matches/"},
        {SaveType.Options, dataPath + "/options/"},
    };
   
     // Add your file extensions here - they can be anything!
    public static Dictionary<SaveType, string> gameFileExtensions = new Dictionary<SaveType, string>
    {
        {SaveType.Map, ".map"},
        {SaveType.Match, ".match"},
        {SaveType.Options, ".options"},
    };

    // Call this at the start of your game if you want unity to make your directories for you to ensure they are there
    public static void CreateGameDirectories()
    {
        foreach (KeyValuePair<SaveType, string> directory in gameDirectories)
        {
            Directory.CreateDirectory(directory.Value);
        }
    }

    //Call this to save the data of your game. highly recommend using JsonUtility.ToJson to populate the data variable
    public static void SaveData(string data, string nameOfFile, SaveType typeOfFile)
    {
        string file = fileName(nameOfFile, typeOfFile);

        try
        {
            //overwrite protection
            if (File.Exists(file))
            {
                Debug.Log(file + " already exists.");
                return;
            }

            Debug.Log("writing " + file);

            // create the file
            using (FileStream fs = File.Create(file))
            {
                Byte[] info = new UTF8Encoding(true).GetBytes(data);
                fs.Write(info, 0, info.Length);
            }
        }

        catch (Exception ex)
        {
            Console.WriteLine(ex.ToString());
        }

    }

    // Call this to load the data of your game. highly recommend wrapping this call with JSON utility like so:
    // YourSerializeableClass loadedObject = JsonUtility.FromJson<YourSerializeableClass>(SaveLoad.LoadData(nameOfThingToLoad, SaveType.Map));
    public static string LoadData(string nameOfFile, SaveType typeOfFile)
    {
        string file = fileName(nameOfFile, typeOfFile);
        string data = "";
        try
        {
            //make sure file exists
            if (File.Exists(file))
            {
                Debug.Log("loading : " + file);
                using (StreamReader sr = File.OpenText(file))
                {
                    data = sr.ReadToEnd();
                    return data;
                }
            }
        }

        catch (Exception ex)
        {
            Console.WriteLine(ex.ToString());
        }

        return null;
       
    }

    //Gets the full directory filename for a given filename
    static string fileName(string fileName, SaveType fileType)
    {
        return gameDirectories[fileType] + fileName + gameFileExtensions[fileType];
    }
   
    //Get all files in your save directory of file type
    //great for filling out menus
    public static List<string> GetFilesOfType(SaveType fileType)
    {
        Debug.Log($"gettting files at {gameDirectories[fileType]} of extension type {gameFileExtensions[fileType]}");
        DirectoryInfo dir = new DirectoryInfo(gameDirectories[fileType]);
        FileInfo[] info = dir.GetFiles("*" + gameFileExtensions[fileType]);
        List<string> fileNames = new List<string>();
        foreach (FileInfo f in info)
        {
            fileNames.Add(Path.GetFileNameWithoutExtension(f.FullName));
        }
        return fileNames;
    }
}

What it does is save/load arbitrary string data to binary files in a user’s file system. I’m using it in conjunction with Unity’s new JSON Utility, which has been benchmarked to be _hella_ fast compared to all the others. The biggest issue with it is that it’s somewhat picky about what it can serialize. From the documentation:

“Note that while it is possible to pass primitive types to this method, the results may not be what you expect; instead of serializing them directly, the method will attempt to serialize their public instance fields, producing an empty object as a result. Similarly, passing an array to this method will not produce a JSON array containing each element, but an object containing the public fields of the array object itself (of which there are none). To serialize the actual content of an array or primitive type, it is necessary to wrap it in a class or struct.”

What this means is that for significant data that I want to serialize, I just have simple structs that act as wrappers for significant data on Monobehaviours I want to serialize. Then, when that object is updated in anyway, I just update its data in its wrapper. This step is also significant because it now allows me to easily send map data across a network for multiplayer playing (and maybe even editing??).

As a reminder, I've recently started a twitter account for the game @isotacticsgame, and have been streaming development on weekday mornings at twitch.tv/massivebacon!



Logged

Pixel Noise
Level 10
*****



View Profile WWW
« Reply #39 on: February 03, 2017, 11:51:58 AM »

Somehow just seeing this for the first time - looking really good! Looking forward to seeing more progress  Beer!
Logged

Pixel Noise - professional composition/sound design studio.
 https://soundcloud.com/pixel-noise
 https://twitter.com/PixelNoiseMusic
 https://pixelnoisemusic.bandcamp.com/

Recently completed the ReallyGoodBattle OST!  https://www.youtube.com/watch?time_continue=2&v=vgf-4DjU5q
Pages: 1 [2] 3 4 5
Print
Jump to:  

Theme orange-lt created by panic