Hello!
First of all, I am new to JME and I am pretty amazed of it. Ten years ago or so we tried to write a MM game using Ogre, OpenAL and few other libs like paging langscape manager etc etc and it was a real pain to integrate them altogether having lack of documentation, bunch of different call and naming conventions, respecting individual restrictions and so on. Finally we realized that we’ll never finish this amount of work in reasonable time period and dropped the project. Sad but not that original story, right? Now I see something looks like “Toolbox of my dream” in JME3 where all that tremendous work is already done for us. Thanks for that, great work!
Now to my noobish case
Say, i have gameplay appstate that handles myself and enemy starships in space. Starship has fire control which spawns individual fire bursts. Each burst is just an instance of some simple class that has its own control and life time. The problem is that I can’t handle the burst’s life in starship control as ship might be destroyed (i.e. removed from scene and memory along with its controls) and burst must still exist and fly towards its target. So as far as I understand I have to pass the burst object to appstate somehow. How do i have to do it properly?
First, the main problem is that you are treating spatials like game objects. This is about like hooking a Swing TextField right up to your database and then wondering how to do transactional commits across a whole UI.
The true story is that your lasers, ships, etc. are game objects and the spatials should merely reflect the current state of the game.
But assuming you want to keep going down the quick-and-dirty-hack method, you should give your ship a reference to the “do all the things” app state or whatever and then the ship just tells the “do all the things” app state to make the burst. Which is not so different from how it probably should be even in the non-hacky-game-objects-separate-things approach.
Thanks for the response! Well, i’m just trying to encapsulate object logic in one place, not separating it into object and its visual reference pair. Considering how much I have already in spatial itself… for instance, i implemented tracking control solely in spatial - it has its location/orientation, .distance() and all that stuff - and now enemy ships “see” me when i’m in range, and rotate towards me - at designated speed - which can be easily achieved having tpf already there. So i don’t need separate logical structures elsewhere, say, for counting time. Is this approach wrong? From what I got from tutorials so far app state is there exactly for handling scene-wide “game state” - so i don’t have to implement separate “logical” loop and then solving sync problem. What’s wrong with this approach? And if there is any other “standard” logic-spatial communication mechanism, please point me where to look at an example?
Update: I tried to pass app state to the control and it perfectly works, thanks!
As to the other, I know it always feels like it will be a lot more code to “maintain two sets of objects” but it generally turns out to be less code. Your game objects become much simpler and focused on what they really do. All of that code becomes generally easier to write. As to the scene graph, you end up with only a handful of classes to make sure the spatials get updated properly… either one manager app state and/or one or two control implementations that are 100% reusable.
What you also gain are things like the ability to have game worlds much larger than you choose to display or the ability to easily switch between networking and single player. As it is, if you ever need these things then you end up rewriting 85% of your code. You may be too far into this project to change it now but it’s something worth thinking about for your next one.
…and in that case, you might look into entity-component systems. Difficult to grasp at first but it’s really quite liberating in the end.
You’re right, integration of logical and visual part into one substance is limited in terms of scalability and/or of “lagging” events where logical part can depend on fps. Small excuses for me are: first, almost nobody will play a game having slideshow-like-3fps-rendering most of the time (therefore i have to worry about triangles count and overall performance impact, of course) and second - i am not implementing a whole Eve Online, at least yet i just wanted to test some NPC-behavior algorithms having quick visual representation of how dumb my bots are
And yes, I started to implement it using classical inheritance-and-encapsulation based approach, which may be kinda ancient in terms of modern games, especially MMO games. Thanks for pointing me onto ECS, I’ll look deeper into it. At first look, systems are a new concept to me, besides i used events and patterns like MVC before. And, speaking of composition concept - this is what, of some kind, i already achieve from JME controls i mean tracking control logic is completely independent of fire control logic, but they work together when I attach them both to target spatial
If you ever want to take a look at a simple JME game that uses an ES then you can take a look at my Asteroid Panic game. It uses Zay-ES which it the entity-component library I wrote that works with JME (though not much JME specific) and also optionally has persistence and networking.
Example here:
The architecture works even for simple games and I use it all the time now. I have trouble thinking any other way anymore, re: games.
Now I see something looks like “Toolbox of my dream” in JME3 where all that tremendous work is already done for us. Thanks for that, great work!