I’m making a prototype of a game concept using jME, and I need the camera to have some strict movements. For that I decided to use ChaseCamera, but the camera movements are still “too free”.
So I decided to extend the class and override some methods to achieve my goal. However I’m running into some problems with the way the class is designed (methods that I want to override are final, for example).
So, before I delve deeper, I just need to know if my approach is correct: wheter I should extend jME classes so I tailor them to my needs, or if it’s better to outrigth modify the engine’s classes (and having them a custom jME engine).
Don’t think of them as “engine classes” per se - they are more “implementations” of a design that are in the engine because they are commonly sought. Yours seems more like a different design than chasecam, so by all means rewrite it and use chasecam as a reference for code if you need to.
If your changes don’t cause any conflict with the original classes, extend them.
If you have any issue with extending jMonkey classes, you’re probably trying to do something too different from the original concept and that could be a bad software engineering choice. Rewrite those classes instead using original code as a reference.
Maybe, but 99% of the time there is a reason they are final.
To the OP, these classes are included in case you need them but they generally don’t do very much. Attempting to extend them is often more work than just writing your own. Sometimes they aren’t even worth using as a reference (see: FlyCam).
I agree that some things shouldn’t be “touched”, but I believe in my case I’m forced to.
I need to override the registerWithInput() method from ChaseCamera simply to define my own triggers. Even though there are some methods to override said triggers, there aren’t enough for all of them (most notably, the moving left/right triggers are simply hardcoded into the method)
Also since I’m using a different kind of camera (orthogonal), methods like zoomCamera() needed to be rewritten in my situation.
“Hi, I want a chase camera but I want it to be completely different than the existing ChaseCamera…”
Sounds to me like you need to write your own chase camera.
I’ve made lots of demos and little games. Not once have I ever used the built in chase camera. And I only use fly cam when I’m initially getting setup… it’s usually the first thing I replace.
This project I’m working on now has been the longest I’ve ever used the built in fly cam and I really don’t like it.
Nothing bad about it, if chase cam suits your use case then by all means use it. But if it doesn’t suit your use case or if fly cam doesn’t. Then what to do? I think the best way is to glance at the source code of other camera implementations and then write your own. It is by far easier to do it like that than try to extend the existing cameras.
To clarify, I use a root node and attach controls and models to the root node, controls manipulate their root node only, everything else just goes along for the ride. Wrong approach?
edit: Except for ChaseCam, it has its own empty root node it manipulates that gets added to the root node.
edit: root node may be bad terminology, container or wrapper node may sound better.
Here are all of the things I don’t like about chase camera for my needs:
-follows a spatial instead of a game object. Want to clip it to your game world instead of spatial? too bad. Don’t want to artificially create odd scene structures to support it? Too bad.
-self-registers with InputManager. Want to change the mappings? Too bad. Want to temporarily use those mappings for something else and switch back? Too bad. I use Lemur’s InputMapper for my user control so 90% of ChaseCamera is already totally useless for me. (It really does go through a HUGE amount of trouble to work around the limitations of InputManager… that stuff just isn’t even needed with InputMapper.)
It’s just not suitable for any of my needs. I’d argue that once you hit “real game”, it’s not really suitable for anyone’s needs.
Maybe it’s ok for some prototyping stage (like FlyCam) but for me, I just use FlyCam until I’m out of that stage. ChaseCamera is just too many workarounds to be useful to me.
Would another implementation of one be of any use, though? I use an appstate that moves the world and provides an offset and those type of plumbings. Input management is basic enough. But it will still have shortcomings in some games. In the end, don’t we all just write our own thing? Does a universal example exist?
My whole point was don’t be afraid to drop it and move on as soon as your game is beyond the “just messing around” phase. Don’t feel bad if you don’t keep using the default cameras. They are really just there for simple tests and demos.
