Managing lots of spell data

Questions
#1

I’m making a game with lots of different types of magic spells. The way I have it structured right now is that each spell and its data is stored in a Lua module, along with a function that performs all the animations needed for that spell.

The issue I’m running into is that I need to instantiate objects for these animations. I could create a new game object resource for each spell, along with all of the components they need. But then I need a factory component for each one of these objects, meaning I have dozens of factories on one game object. Not very lightweight.

I thought that maybe I could have a single game object resource called “spell” that could be loaded with data from every spell type, because then I just need 1 resource and 1 factory, but I have no idea how to load this spell data at runtime. Each spell will need its own particle effects, which would mean I need to have every single particlefx component on the one resource, which seems like moving the problem.

How would you structure this type of game?

#2

This is not necessarily a problem.

Are you sure it is a problem?

#3

I have no idea. I’d just rather not spend an immense amount of time doing this, then realising later that it causes the game to lag, which leads to me spending an equally immense amount of time refactoring all of it to something faster when I could have avoided the problem from the start.

What would you recommend?

#4

I don’t think it is going to be a problem but I can’t say for sure. I would have to try it myself to be sure. You have not shared enough information to make it possible to answer your question either:

  • How many different particle effects will you have?
    • If you say 20 then I don’t think it will be a problem to have all of them on the game objects, but if you say 100 then maybe it will be an issue. In order to answer we also need to know:
  • How many game objects with active spells will you have at any given time?

Taking the above two factors into account:

#active spell effects #different particlefx components #particles/pfx total pfx component count total particle count
20 10 100 20x10=200 20x100=2000
200 10 100 200x10=2000 200x100=20000
2000 10 100 2000x10=20000 2000x100=200000

Scenario 1
If you have 20 active spell effects at any given time and 10 different particle effects, then you will have 20x10=200 particle fx components (although only 20 will be playing). If each of these effects generate 100 particles then you will have 20x100=2000 particles.

I bet this is not a problem. You will need to increase some values in game.project Particle Fx section but that’s ok.

Scenario 2
If you have 200 active spell effects at any given time and 10 different particle effects, then you will have 200x10=2000 particle fx components (although only 200 will be playing). If each of these effects generate 100 particles then you will have 200x100=20000 particles.

This could be a problem. 20000 particles should not be a problem on a pc, but could potentially be. You’d need to measure this using the profiler. It will definitely generate some CPU usage, and possibly also a bunch of drawcalls.

Scenario 3
With 200000 active particles it is definitely a problem, and possibly above the maximum number we can handle.

3 Likes
#5

I looked into this a bit more, and I’m not worried anymore.

Firstly I should have specified that I was worried about file size, not runtime performance. Making 100 game object resources, one for each spell, would multiply that resource’s size by 100!

Except my resource is 1 KB large, so it doesn’t matter.

Even if I ended up creating hundreds of thousands of these resources, I could still use live update to manage them and keep the binary size small.

#6

Ah, I see. Well, as you saw, Defold data files are usually small when stored in their binary format.