Here’s an update log of what’s going on with Project Universe
Since I decided to switch from text files to in-app master data storage, I was able to get this aspect started pretty quickly. Using collections, I set up custom objects to represent elements such as sectors, stations, jumpgates, and planets (and others to come, like items, ships, and commodities). I define these using Excel, with a special column that takes the data columns and creates the C# code needed to add that item to the collection. Kinda lazy, but saves a lot of time, and allows me to visualize the data in an easy to digest format.
The data controller is working well so far. It’s incorporated with the master data, and consists of List<DataObject> objects that store instances of..well…data objects.
Since the data is pre-loaded, it’s ready and available through the static implementation. I’m kind of at a crossroads now, though. Since this MDS is essentially a kind of database, I’m going to need to pull out records in ones and twos (more on that later). Should I incorporate lookup methods in the Data Controller, or have each data consumer handle their own look-ups?
I had at one time gotten a space ship to fly around in a skyboxed solar system, and in consulting my notes I thought I had the movement scripts and requirements down pat. I downloaded a new ship from the Unity asset store and wired it up for movement, but it was acting wonky. For one, it’s “forward” (as in Vector3.forward used in the calculation of thrust) was parallel to the Y axis…which in the Scene view looked like it was moving down. I think it’s logical to design as if in the real world — horizontal, or along the X and Z axes — so I couldn’t figure out what was going on with this test ship. It WAS the test ship, by the way, because when I set the same scripts on a standard capsule prefab that “stands up” like a little person, it moved “properly” along the correct axis. I’m thinking it has something to do with the way the ship model was created and exported…maybe. This is where my limited knowledge gets even more limited.
But I’m using the free ship for testing anyway. So it flies sideways. Who cares?
One goal is to make all of the items kind of dumb. The plan is to create different representations of classes — stations, ships, asteroids — as models, set a script on them that ID’s them, and then other scripts that simply deal with whatever data they look up from the Data Controller. Ideally, I won’t have to populate individual items by hand if I can get them to look up their own stats when they create themselves.
This is where the idea of “how to do the lookup” comes into play. I might have up to five jumpgates in a single system, and when the player loads in, each of those gates will ping the central data store for info about themselves. Five lookups is OK, but then we’ll have stations and NPCs and stellar objects, all trying to get data out of the data store. Hopefully it can handle it.
And finally, I’m trying to do stuff without Playmaker. I’ve spoken highly of Playmaker in the past, and I still like it, but I didn’t want to become reliant upon it because I know I’d start using it for everything, and then encounter a situation where I couldn’t make it work. Then I’d have to hack in an “old school” pure script method, and suddenly my app becomes some kind of cobbled together mess of two different disciplines.
The things I’d used Playmaker for in the past were handling the docking of the ship at a station, and dealing with the station menus. This morning, I managed to accomplish both of those things with just script, and with not-too-much script either. I’ve planned out a strategy that uses the Data Controller and a hierarchy that minimizes the “communication chains” between GameObjects and their components that I had always run afoul of in the past.