Hey everyone, happy new year! After a short break, we're back working hard on Planet Explorers. Here's an update on how we're progressing on Alpha 0.5.
- Lots of progress on moving the entire animation system into the new Unity animation system mechanim. This should make a lot of the animations much more efficient and better.
- Vehicle creation is now looking really good, we have controlled mounted turrets, ai turrets, and front mounted turrets. We're even considering putting in vertical launched missiles...haha.
- We're working on mines and grenades.
- Guns now can have multiple muzzles. We're looking at how to make plasma material for lightsa...er, laser swords.
- Trading of creations is already done, so you'll be able to swap whatever you create with other people over the net.
- Added in quite a few new animal types.
- We're currently working on getting the LOD system to display stuff players build on LOD 1 and beyond, so you'll be able to see that house you made 1km out.
- Rivers and lakes are in and they look pretty nice.
- Currently working on getting more missions into the game for about 4 new main story NPCs.
- We've started working on the town building system...;)
- Working on generators and engines.
- The terrain structure has been improved with valleys and canyons and giant arches and caves and and distant fog and volumetric clouds in some places.
- A couple of other things (hint: things that bring balance to the game against all that firepower mentioned above)
- New turrets are in, along with new materials.
- Working on a few ways to get the efficiency up. We're running into problems in this regard because we don't have access to Unity's source code. The thing that's killing the frame rate the most is real time terrain collision generation, and buying the Unity source code isn't cheap at all.
Still, due to a few problems integrating into the latest Unity version, we're going to be a bit late in pushing this build out. We're now aiming for before the 31st of Jan. Kickstarter for the project will start shortly after this alpha version's out. Thank you for your patience. :)
nice, keep up the good work
killer! Auto turrets and mortars!
Sounds awesome! This game keeps getting cooler and cooler.
Oh, and if I were you I'd call themn "plasma swords" rather than laser swords - at least with plasma you could have some justification (e.g., blade-shaped magnetic field) for the blade being of a fixed length rather than an endless beam.
We did have a endless beam sword the other day...it kept cutting the protagonist so we took it out. :)
love this. can we buy it already? :D
Edit:
didn`t see the part about the Kickstarter at first :)
Will the money gained from a successful Kickstarter campaign go towards paying for Unity source code access? Given how much trouble you're having with a lack of true integration, I'd imagine things would improve immeasurably if you did have true engine integration!
Also, I can't wait to unleash some good old-fashioned "death from above" with the vertically-launching missiles!
I think once we have enough money, we will try to get the Unity source version. It probably would improve a lot of things since we'd just write our own collision. Unity right now isn't build for making this type of games.
It's nice that you keep adding new stuff, but shouldn't you first fix the more obvious problems? Like the horribly performance? The memory leak (game keeps crashing when it hits ~2 GB memory?
And after a while of playing, the game freezes when loading a save game, making it basically impossible to progress. Either it will freeze/crash during loading or it will load but the frame rates will be like 0.5 fps. Seems to happen more often when saving while it's night/dawn/dusk. Sometimes saving at the second camp (where the second ship crashed) will cause this issues, but i.e. saving and loading 200m away from it seem to work.
This issues are more important than adding new stuff
Expack: I hope you are kidding? The Unity source would be somewhere in the hundred-thousands. Even "just" an Xbox/Wii/PS3 license is in the several 10.000$ range (+ the console license itself that's around 20.000-30.000+ for a single project)
We *are* fixing them, the switch to mecanim is precisely to save on ram, we'll end up shaving around >300MB there. The 2GB thing is due to Unity being a 32bit engine, considering how marching cube terrain generation will take around >1GB at 1km, there's not too much we can do there unless we get the source code or you stay below 512m draw distance.
We are trying to fix a sorting bug for the terrain lod generation, that should also help a bit on the CPU side.
Overall, we could probably optimize for 20-30% more...but it's a costly calculation system running on a third party engine without the source code, and we don't have too many programmers around. There's only so much we can do at the moment.
Well, the issues I had (that loading fails or if it not fails the frame rate is unreasonable low, though the framerate was ok BEFORE the load) are kind of game breaking. No matter which settings I selected, if I had a save game that caused that issue I was unable to ever load it again or get the fps up.
I don't think having Unity3d source could could even help you. Most optimizations nowadays comes from optimizing the algorithm, not that much from compiler side.
You basically have several options on how to go:
1. Simplify the algorithm as mentioned above (probably most important: be careful not to trigger garbage collection too often, as Unity3D runs on an outdated Mono version, 2.6, with old and slow garbage collection)
2. Move the time critical code (i.e. voxel-terrain calculations) to a "plugin". Basically a dll. This requires Unity3d pro in order to communicate with a native plugin (one written in C/C++).
You can't use pointers in C# code directly, because Unity3d disabled unsafe code
3. If the calculation of one black do not depends on results of the other, consider using a Compute shader (new shader feature in Unity 4)
However, the FPS bug after loading a save game is somewhat weird of a bug and hard to explain why fps is ok (20-25 fps at the point of saving at 1024m range) and after loading either freezes forever in the loading screen or fps drop to 0.5 fps.
Hmm, can you send me the output log/save file for that bug if you still have it? We have not seen this before. There was a bug that caused NPCs to cause massive frame drops, but it was fixed. We'll look into it.
As for how to optimizing voxel stuff. The voxel generation is already done through a C++ plugin, but the Unity cache for reading such a plugin is really small, so it does create a bottleneck there. Still, it's fast enough that we don't really worry about it.
The major problem is how to get Unity to generate the collision faster, it can take up to 400ms to generate a new piece of collision at 1km LOD (only about 128m is collision), the best way to do it is to move the collision generation to another thread and just have it do it in the background, but Unity doesn't allow that as far as we know. We even thought about using a parallel program that loads terrain data and generate the collision somewhere else (so it doesn't use the ~2bg of ram and can use another thread) and Unity reads in the data, but that also didn't work. We think...that if we have the source we could implement one of these ideas...maybe. But yeah, any other ideas would be appreciated.
Also, we are using a lot of garbage collecting, not much choice there since all of our AI, path finding grids, and terrain are loading in and out of memory on the fly. Overall, it's just a really harsh game to make, much much harder than we anticipated, heh, but it's still fun.
I've sent a mail with two savegames & two output_log.txt files (one for each save) to admin@pathea.net (sorry didn't found a mail for bug reports).
You *can* generate the collision in a separate thread, but you are not allowed to interact with Unity Objects from, because for Unity.Object derived objects the same rules applies as for UI elements in Windows programming: They can only be accessed (or changed) by the thread that created then: the main thread.
Since a mesh (and a colider is basically a special form of a mesh) is just a collection of Vectors you can generate it in a seperate thread. You will just need to have a copy of the terrain data instead of directly accessing MeshFilter.mesh.
Depending on the size of the mesh it may or may not take a significant amount of memory to hold a copy of the data while working on the thread. After all the calculation is done.
Once the calculation is done, one could notify the class handling it. Unity do not have a way to invoke the main thread from a worker thread, so one would have to keep some kind of TaskQueue that is checked regularly in an Update() method and invoke the triggered event from there. Or simply add a bool variable, which is not a very clean way of doing it and feels more like an hack.
i.e.
void Update() {
if(bColliderReady)
meshCollider.mesh.vertices = newColliderVertices;
meshCollider.mesh.uv = newColliderUv
meshCollider.mesh.triangles = newColliderTriangles;
}
}
You can not modify the "meshCollider" from a separate thread, but you can calculate the data into array and then assign it in the main thread. Or alternatively use the approach of a coroutines and spread the calculation over several frames, which is in no way replacement for multi-threading but could spread the 400ms calculation over 8 frames a 50ms per frame.
This comment is currently awaiting admin approval, join now to view.
as always, cant wait
sounds really promising here, cant wait to try this version out.
by the way, out of curiousity: how many people are currently working on this project?