Login

PremierBromanov · 08-13-2023, 03:46 PM

Awhile back, I wrote wrote about a "physics based sim" I created in Unity. In short, I used Unity's simple physics engine as a proof of concept for what a 3D sim might look like. I did this for fun and as a project I could put time into in the future. Well, that future has come at last. I put a few more hours into the "sim" and laid some ground work for future updates. Today, I want to give a small update because I enjoy sharing what I do and I enjoy SHL bucks.

The Model

The most important part of this project for me is to be, as much as possible, data driven. Being data driven means that once I hand off this application, a user should be able to modify the data that controls the sim. Much of FHM8 is already data driven. We have many hands wrangling a lot of data to make the sim work. But, there are some aspects of the sim that are unchangeable or outside of the sim's scope. Primarily, our entire league is built around a data system that the sim knows nothing about: our update system.

Since FHM8 is an entirely different entity from the SHL, it makes sense that they would not bend to our will in any shape or form. But, since this is a passion project for me, a member of the SHL, i wanted to bake in some of that functionality. Namely, attribute editors and attribute definitions.

This update focuses on the attribute definitions. Now, without being too complex, the attribute definitions are in name only. But, even that should be data-driven. If, for instance, I want to run a fun tournament with SHL players, I need to be able to accept any number of attributes and display them on screen. How I consume those attributes is a problem that I can solve later. But, with this system, I can devise a simulation that requests certain attributes I expect and silently fails if those are not around. In addition to defining the attributes, we can define two more pieces of data: How much each level costs and whether or not it is enabled.

For the technically inclined, here's my first pass

[Image: 7HQqio6.png]

In keeping with the theme of being data driven, this Model is designed first and foremost for JSON. That means if anyone had access to this application, they could save or load JSON at their own leisure. My plan with the rest, like teams, users, players, etc, is to make those serializable as JSON as well. My priority on this matter is to consume data from the API whenever possible.

A fun thing about Unity is that it allows an instance of a class (in this case a data manager i made) to serialize and display other objects in the inspector, as well as to edit them in real time. I created save and load functions in the inspector so that I can load data from my hard drive or save it to my hard drive. Either way, there is an instance of the data alive in the scene and another version serialized as json in the project. In the future, there will be a folder structure similar to FHM8.

[Image: jkP6EhJ.png]

So, why does every Attribute have it's own array of costs and why is it an array of integers?

There are a few ways we could define the TPE cost of an attribute that might seem more elegant. We could limit the number of fields by grouping together some of the costs, such as values 5-9 all being 1. And, we could use a single solitary array for all of the attributes, and that would slim down our JSON. The issue there is that we have things like Stamina, which work differently than the rest of the Attributes. In Stamina's case, the first 14 elements in the array are 0, since they are free, thereafter they continue like the rest. So I figure, why complicate things? Our values are hard-clamped to 20 (in this case, i went to 22 because FHM8 can go beyond 20), so there's no need to create some sort of algorithm. Also, it's sometimes better to be verbose for a potential user, to limit the learning curve of using this system. Now, I could simply have a "base" array of costs and if the array field is empty on an attribute we will simply use that, but again I'm striving for verbosity and to speed along development.

UI

Lastly I want to display the data in a UI as a proof of concept. Here, I've made the worlds worst UI. This is not my forte. However, each of these white boxes is instantiated at run time and given their Attribute data from the model. Values are hard coded to 5 at the beginning, and then we can press plus or minus to increase or decrease the value and the displayed cost will change. You are probably familiar with the Player Build tool, so think about that for reference. We are of course missing a TPE field and a total spent and all that good stuff. BUT, the proof is here. I can create any number of Attributes in my data and I don't need to create specific UI for them. Rather, the UI is built using Prefabs that hook into the data we defined.

[Image: 6UNoish.png]

This of course paves that way to player editing, team editing, and so forth. If I can read one piece of data and build a dynamic UI for it, then users could also fiddle with their data and create whole new sets of attributes. Obviously, if the sim doesnt read those, it wont matter. But, that's a problem for future me.

Thus concludes a small update. I hope to build upon this project soon and my hope is to have a fun little sim engine for all star events and other fun projects. Hopefully, wrangling the data is far easier this way.