-
How do you debug? Some things are difficult to test visually unless you do a very special scene setup. One thing I can think of now is attaching some helper component to every entity I create to I could see not just the id. Is it practical?
-
How do you decouple? I mean how big your components and systems are? The biggest component I have now has 10 fields (2 of them transient, can’t get rid of them). Is it wrong?
“ If debugging is the process of removing software bugs, then programming must be the process of putting them in. ” - Edsger Dijkstra
The first lesson that I’ve learn programming was: You must debug, you can’t avoid it. But how to do that on gaming development? Sadly there is no easy workaround: You have to develop your own tools.
Whenever I can I avoid developing a debug tool, because they are “waste of time” but whenever I got stuck, about 2 or 3 days on a problem, I spend 2~3 hours developing a tool to debug this problem and voila, it takes me only 1 hour to figure out whats the problem…If I’d decided to make the debug tool 2 days early, I wouldn’t truly wasted time…
So, now letting my thoughts out, on jME3 I create a DebugAppState, like jBullet, so whenever I need to debug something, I add it there. When deploy time came, just don’t attach this state.
Some times it’s hard to keep all debug on a single state, but you have to try because it’s easy to maintain.
Note.: By debug tool I mean a function to match your debug needs.
1 Like
Interesting point, I’ll think of it, thanks! Truly, detaching a state is way easier than surfing through the code removing .setComponent()
Does any other system use those fields? If “No” then your component is too big.
Else, it’s hard to comment without specifics… but it is super-super strange to have 10 fields in a component. Chances are you are either using your component as a dumping ground for system state or you are missing a layer of entities. Again, hard to say for sure without specifics.
Yes, it looks if the base one is done with the task or not, for instance. I could indicate this with yet another component ofc, but having another class just to say yes/no… doesn’t seem reasonable.
Can you describe more specifically what these systems are doing? That might help me respond properly.
The hypothetical is often a hard place to make design choices.
Processing orders, like moving through a sequence of points (patrol task). Once it reaches last point it says “I am done” this way. Of course task might be endless (i.e. looped route), in this case I need to indicate that it is doing a never ending task somehow as well. I could distinguish that by other task properties of course, but I want to be able to add new tasks without modifying another/upper level system logic.
Yeah, see, to me again this is all part of the AI system and not something that needs a component, really. The AI will have a behavior tree or a state machine or whatever other AI technique it uses to keep track of its state. It then publishes simpler components like “walk to X”.
It’s possible that the AI system might publish a component for persistence purposes but even then I’d expect that to be maybe one field with the state, or behavior, or whatever as current.
Well there’s not much of intellect implemented so far, we’ll see where it comes. If everything is a running system I need to do these checks somewhere anyway. Having systems leveled seems more functional as it looks easier to extend “ship level logic” to, say, “fleet level logic”… this might be just because I don’t have solid top level logic concept in my head yet, so I want to do some experiments first 
I’m still trying to wrap my head around the whole Entity/Component stuff myself, but from what I understand so far, I would do it like this (given the fact that you want to implement the AI as components):
Store tasks (like patroling) as a separate entity. This entity has one component for the actual task (in this case containing the list of waypoints), one component for what to do at the end of the task (like “loop”, “full stop”, “fall back to standard behavior”, …) and one component that contains the ID of the ship or fleet it is assigned to (this allows you to easily implement new objects in your world that can have this kind of task).
For the purpose of patroling you only have a component for movement (containing values for direction and speed) and position on your ships. You could also include a component referring back to the attached task, so your ship knows which task it is currently following.
Your task system now only compares the ship’s position to the waypoints and adjusts its movement component in case it has to change course.
Well, I suspect there are a few hundred different ways to do this particular thing…
but generally I guess things tend to be layered where you have steering at the bottom and then some kind of executive layer above that, whether based on FSMs, Behavior trees, GOAP, whatever. Above that you might have a higher order strategy layer fleet/team/army/whatever interaction. That top layer coordinates the individual actors in the lower layers.
I suspect that regardless of the specific approach, that if the layers are properly constructed then the communication between them is minimal with respect to components.
If you’ve never played in this area before, finite state machines (FSM) are probably the most straight forward but I think “behavior trees” are probably a little more powerful. And one doesn’t necessarily preclude the other anyway. Those keywords maybe will give you something to google if they are unfamiliar concepts.
Yep, I am aware what FSM is, behavior trees is something I will look into now, thanks! Though, I mentioned not that I don’t know how to implement top level logic, but actually that I don’t even know yet how many levels there will be 
And yes, that big component is big mostly because I wanted to encapsulate in the system a lot of things to exactly minimize communications (yet to simplify higher level). Certain compromises are to be taken anyway!
Note: if you are interested in books on the subject, I kind of really enjoyed Game AI Pro (volume 1) as a general overview of lots of stuff with enough detail to really know where to go next. I have volume 2 sitting on my desk but haven’t read it yet. I’m forcing myself to wait until I’m actually in a position to implement something so that I can take advantage of the inevitable inspiration.
I have some other game AI books but so far that is my favorite one.
But now that we’ve discussed it and I understand the context better, yes, I think it’s strange for a component to have so many fields. Not necessarily ‘wrong’ but it’s a sign that two systems are really one system split in a strange way. Perhaps it should just be one system with multiple semi-coordinated entity sets or should be broken apart at a different place.
…but all of that state shared through a component is a bit of a bad sign. Something to look at, anyway.
Sometimes the mistake is forgetting that systems can keep their own state that doesn’t have to be components. Though I suspect that’s not the case here given other fruitful discussions.
It’s an interesting topic, though, because I haven’t fully fleshed out Mythruna’s AI yet so it’s always in the back of my head.
Oh yeah, I do so with incredibly good books sometimes too. “Too good to read right now, it needs a special day for it!” Thanks for pointing me, I’ll look forward to get it (cause what I have read about AI so far were neural networks which I guess would be kinda overkill here 
)
About component, yeah, I am doing some refining now, so it may become more lightweight (probably I can transfer couple of checks onto another system so it will lose at least one field), will see.
Note: now reading what you have pointed me to I see things I started to implement are somewhat similar to HeBT concept (though in my head I didn’t have it that well generalized as a concept of course) - at least using for “engage task” value of the task’s importance provided by higher level certainly looks close enough. Well, logic drives us all the same way Thanks for the reference once again.
Glad it’s working out for you.
Unfortunately, I got that book right as I had lots of time to read… meaning I was spending lots of time in lobbies and waiting rooms from taking other people to appointments. This meant that I didn’t have a chance to try out any of it. A very frustrating time because a lot of it is very inspirational.