General question about data driven design

Development Programming & Scripting
1

Hey guys, I am planning out a survival game system where you can pickup items, these items refer to a data table which holds their unique parameters, and then for whatever type of item it is, you may be able to do different behaviors with it.

My question is about clarifying some ideas shared here:

No hardcoded classesPermalink

However as a programmer you might decide to write all of the logic for each of the buildings in their own classes. Farm.cpp, Windmill.cpp, House.cpp etc. Maybe you use inheritance to share common code, and seems pretty simple.

But what if a designer wants to create a new type of building? They have to come to you, the programmer and ask you to create it. Being a programmer is about being intelligently lazy, so how can we improve this?

Stepping back, what is a building? What can it do? We can see a building as a set of behaviours that can be mixed and matched:

  • Create resource behaviour. A farm creates wheat, a fisher hut creates fish.
  • Convert resource behaviour. A windmill takes wheat and converts it to flour.
  • Store resource behaviour. A windmill can store a small amount of flour that it creates, a barn can store many resources of any type.
  • Require Worker behaviour. The building will not work unless all the worker requirements are met.
  • etc.

By decomposing a building into a collection of behaviours, designers will be able to create new types of buildings without programmer intervention. Modders will be able to create new building types very easily, too.

Programmers are only required to create new behaviours. For example designers might want buildings to be able to catch fire. In that case then the programmer can create this new behaviour and let designers add it to the buildings they want to be flammable.

This idea that programmers are only programming the behaviors… where does that happen? I think if I can envision one example, I could extrapolate from there.

Say you have a meat item and you want a “cook meat” behavior. The meat item can exist just as a string variable on the player character, or where ever inventory data is held.

The cook behavior would do a couple things:

  • remove meat item from players inventory
  • add cooked meat item to players inventory
  • run some other logic like play sfx, etc

The question is, where do I define this behavior? In an actor component? Does that scale well if you have like, 100 different behaviors that are possible? In a single player game is there any benefit to separate behaviors into components when there is only one player character class? I could just as use separate graphs in the blueprint editor for organizational purposes, and then I don’t have the added verbosity of passing data from one place to another, right?

I know there is know right answer and everything depends on project - just looking for any general advices, ideas, thoughts, etc.

2

Alrighty, I’ll share a few things I learned.

My primary goal is to reduce complexity. I am looking at every example of inventory systems I can find and it is all like NASA level stuff. Just way too much work for me to even consider.

My guiding thought is that all pickups should be represented by a single class, and with a minimum of moving parts we should be able to identify a data table to draw data from to get info about the item.

Nearly every example I see combines all item types into a single data table. While this can work, to me it feels very sloppy - if I want to get data about a building material, why should I also read strings about calorie content and damage values?

So, I want specific data tables for categories of items, and all items should be represented by a single blueprint.

I’ve made a test and accomplished this for the most part, I believe.

On the Pickup actor, I have a public String variable:
image
I type an items category, separate with a space, and then its name.

A string is just an array, so I parse that:
image

image
image1130Ă—649 143 KB

And that gives me all the knowledge I need to look up the correct data table for the item. I just Switch from the category name, and then I can grab the right data table to get access to further data.

This reduces the need for tons of nested data types that gets my brain twisted in a knot, and it also means for saving the entire inventory it can be contained in a single string array. There is also no inheritance involved so I don’t have to figure out where to draw line between common and unique needs.

I doubt this is the most efficient method in the world but it is simple for me to get started with.

For managing where behaviors are scripted, I think I just need to consider on case-by-case basis. I think for most part, it seems logical that player character would hold most behavior code in a single player survival game. Not sure the added verbosity of composition design nets me anything in a case like this.

4

hey thanks!

i did manage to get some advice from other old-timer game devs and they had similar thoughts as you, so I think there is some wisdom there.

In my case things are a bit easier because I am solo dev and also not planning on tackling multiplayer any time soon. So like you are saying, I only need to justify to myself and the only major hurdle is just making a system I can deal with down the road.

I actually reached a pretty satisfactory solution for this that I believe should be pretty extensible and future-proof. I wrote a little about it here on my devblog here: Project Alaska: Setting up framework for the inventory system - Project Alaska - GameDev.net, though that is mostly a journal for my own sake so it might not be super clear to other readers.

In a couple weeks I get into new house and get my workstation out of storage, I’ll try to remember to update this with what I settled on. It actually may be worth doing a short video overview because it’s a very simple system that I think accomplishes many common inventory needs, and to be honest I have not found a single “simple” inventory example anywhere. That’s subjective of course but I am sure some other developers have a cave-man brain like me :).

1 Like
6

I read that and I immediately like the simplicity of your solution. It’s very much similar mindset I take to game dev. I have no compsci training and my job before this was shoot a machine gun and carry heavy stuff long distances. So I am a simple solutions type of guy.

However, I think a case can be made for consistency. In my game development, it seems the major problem that I face is that there is too much information I have to deal with. I cannot keep a mental map of the entire project in my brain. Being a solo dev I often have to switch gears ,and each time I do, this becomes more and more taxing as the project grows.

So these days I am usually leaning towards more consistent code, even if it is more verbose. For instance, if I handle a state machine one way in the project, I try to handle state machines with the same pattern everywhere in the project, even if it isn’t the most efficient code.
The time and energy I save in not needing to load any additional caveat situations into my brain I think pays for itself in a lot of cases.

edit: not to suggest I would be against implementing a solution like you described there, but if I did, I’d be sure to make a giant pink comment box with a clear description of how I was handling htat unique case, and that would be my guideline for any developers in my team - if you break the standard, make sure you flag the hell out of it and write in plain language exactly how things work.

1 Like