@vinexgames cool suff! I really like it!
Just a question about the main player: did you make his physics with CharacterControl or RigidBodyControl?
@ghoust Good idea, that would work too. I’ve more or less got it working and I’ll be posting a tutorial with the release of v0.6. 
To the building question: Actually, I didn’t think of that. The only problem with that is loading all of the fracture pieces at runtime. The load time for those models is about 1.5 seconds on a Phenom II X4 925 @ 2.8GHz (I think it’s close to about 12 polygons per fracture piece, and there’s 372 parts in the building). I do have some LOD’ing ideas though. Before the final v0.6 I’m planning on adding a per-wall fracture sort of thing, so that you model each building per wall, and if a wall hasn’t been damaged it renders as the full model instead of the fractured model. That would more or less solve the loading at runtime problem, and also keep a large number of polygons out of the scene and cut down on load time. I might even be able to multithread the model loading, but the only problem with that is if it does take > 1 second you might just be looking at an invisible wall. Plus it’d be hard to track which parts of the wall are to be fractured. I’ll mess with it and figure something out after vehicles are done.
@mifth I’m using the CharacterControl, but I’m using a custom extension of it to track health, team, and armor stuff. If you’re having trouble with the CharacterControl, some common causes I’ve seen so far is not having it’s step height right or setting it’s collision shape’s height too low. If the step height is too high, or the control’s collision shape is too short (in my case < 3F i get problems), your player control will often just fall through the ground. My collision shape is a CapsuleCollisionShape, and I think the height is 4, diameter 1, and the CharacterControl’s step height is 4.75.
Still don’t know how to edit posts, so I’ll just throw this down here. xP
Update!
+Fixed sprinting animation (it’s a bit faster now)
+Added drivable vehicles (Almost done too!)
+Changed pistol sprint animation
+Attempted some AI optimizations
As of right now, the only thing I want to finish before releasing v0.6 final is AI. Right now, with > 10 AI at one time the performance is terrible. (Running on AMD Phenom II X4). This is because it’s entirely non-multithreaded, and all pathfinding is done on the render loop. I was just throwing AI code into it to see what I could achieve, and now that I’ve found out what I can do it needs optimization. I’ll be spending the next week or two adding to and optimizing AI, so expect lots of videos of me getting my butt handed to me by giant boxes. 
Now, the eye-candy!
[video]http://youtu.be/5fWmVO_S_7M[/video]
If you want to bug test the current version as it is right now, or maybe for performance reasons try to run the game with lots of AI, PM me and I’ll send it to you via email or something. I want a good variety of systems running it so I can see what does the job best and what doesn’t. Thanks for all the support so far!
What do you do with the pieces after it finishes collapsing? For performance you might find you need to remove them from physics and then geometry batch them (dunno how you would then handle collisions though).
Yeah, also having the “broken” parts all the time when they are not used is probably not ideal and causes some unnecessary overhead. Just put the “pieces” in when its supposed to explode.
@zarch after about 30 seconds I set their sleeping thresholds to very high numbers so they’re basically immovable unless there’s nothing under them or if there’s another explosion.
@normen The only problem with that is that the each building is modeled in pieces. I wish I could do that but as of yet I haven’t found a way to. Before they’re hit by a high force they have a mass of 0. I’m going to move the explosion to another thread so that if it’s a large amount of damage done you don’t see a half a second delay before the building is thrown about. I’m calculating their new collision shapes on the render thread so multithreading there would give a decent overhead decrease.
All that’s left before a final v0.6 release is to optimize and finish rewriting AI.
In the works for v0.7:
Almost the entire version will be dedicated to general code improvements and optimizations to performance
A new (and very amazing, super secret) weapon system. 
More maps and, of course, more epic things to blow to pieces.
The only problem with that is that the each building is modeled in pieces. I wish I could do that but as of yet I haven’t found a way to. Before they’re hit by a high force they have a mass of 0. I’m going to move the explosion to another thread so that if it’s a large amount of damage done you don’t see a half a second delay before the building is thrown about. I’m calculating their new collision shapes on the render thread so multithreading there would give a decent overhead decrease.Well, I guess it will become a matter of weighing off both things the bigger the levels get. You are surely able to stitch the objects together in blender and export them, then keep the other parts and collision shapes prepared around the player(s) but attach/exchange them only when needed. Definitely outsource the shape creation and loading etc., yes. Just make sure collision shape creation happens on one thread, the jbullet library has some issues else. Also, if your models are all prepared j3o files already, you can add the collision shape in the SDK SceneComposer already and just load it along with the model instead of creating it.
Create the shape that is doing to be fractured, copy it and then fracture the copy. (You will want to keep the original anyway in case you need to modify it.
Then you keep both in your scene and swap them in/out as required.
@normen The way buildings work is, when you load them into the game they’re all in one Node, containing each part. (The whole building is loaded as 1 spatial). Then I iterate over the children of the loaded Node and set it’s properties according to it’s name (see the post on the first page) and give it collision shape and stuff like that.
@zarch not a bad idea, actually. I’ll probably make it so if the broken fragments of the building are more than like 200 wu away from the player (or for MP, the nearest player) I’ll just call
[java]buildingFractureControl.setEnabled(false);[/java]
until it’s needed again. If the nearest player is more than 300 wu away, I’ll make them stop rendering. (How could I do this without detaching them from the scene? It’ll be complicated to do if I can’t because then my physics controls get odded out). Also at this point I’ll make (a lower detail version of) the original, un-fractured building come back into the scene with no physics. I’ll have to write in this swapping code for the building class at some point. It’ll more than likely be in v0.7 because I’m dedicating my time to AI right now. After that’s done, I’ll be releasing v0.6 for public testing.
Put the fractured sections all in one node (they probably load like that anyway), the full model in another. Swap in the node/model appropriately and all children will swap with it. I would only swap in the fractured model and start the sections up in physics as something that can fracture the building hits it - basically don’t add the overhead of processing them until they are needed. This will also get rid of any issues with cracks etc showing prematurely.
After an explosion throw the fragments into a BatchNode and that should help a lot although it won’t be as good.
@zarch Thanks for the suggestions! I’ll work with the code after some more AI progress is made.
Plus, bump for small update again!
Another small update! Thanks to @zarch and @normen for some of the suggestions for building optimization!
Update.
Nothing bad about that. Sounds like you’ve had a great learning experience thus far.
I trust you’ll make it smaller, stronger, faster
It’s a learning experience This is why I always recommend people to start with the most basic game they can think of and then work up from there learning as they go.
Expect to need to do this several more times (maybe not with the full project but certainly with bits of it).
Been there done that ^^.
Actually you can expect to write alomost all parts of a game at least two times, before it is somewhat right, if you have not done something similar already. Of course if this affects the core of the game, its often easier to just wipe out and restart with the knowledge Don’t let yourself discurage from stuff like this.
Its even normal in large projects and with very experienced programmers you just can’t avoid its going another course at some point.
Parts of Mythruna are going through another rewrite at the moment… so I can relate.
Good luck!
Thanks all! I’ve had very small chunks of Lexicon done before, and this is by far the furthest I’ve successfully gotten. When I started I had very little knowledge of Java at all, and even less about jME. There are parts in the code that look like a 4 year old stepped on a keyboard and out came the results. Other parts are actually good, but when added to the chaos just make things worse.
@EmpirePhoenix I rewrote weapons about 3 times before coming up with the new weapon system. I rewrote movement code god knows how many times. This will be the second big overhaul. I started this rewrite in May, over a version that was more or less just walking in a scene. I decided I wanted to do it all differently so I started over. And this is the furthest I’ve gone with it.
@pspeed Good luck! Mythruna looks awesome so far!
@zarch Definitely true. I think I learned more working on this than I did in school. That’s mostly because I focused all my time on this instead though. xD
@erlend_sh Definitely smaller. The player update loop was like 200 lines. It was one of the biggest chunks of CPU overhead other than calculating collision shapes.
@rangerplus10 Thanks! I’ll need it. Starting over will be a big step but it’ll be worth it. Plus, it was unbelievably fun the first time around. This time, knowing a lot more of what to do and how, it’ll be even better!
1 Like