Not sure if this was worth a whole new post, but what the hell. So I took a short break to work on some other aspects of the game, but I’m now back on developing the character. I’ve introduced some changes based on people’s feedback in the comments and started work on clothing. I was wondering if you guys feel it’s made any improvements now. It’s not textured yet, but this may give some insight into how it will eventually look. On the subject of other aspects of the game, I have managed to figure out where a lot of the performance bottlenecks were coming from and it turns out it was more to do with how my scene was structured rather than the capability of the renderer itself, so we are now seeing massive performance improvements in the rendering of static geometry. I’m going to start looking into wrapping up what we have of the school so far and putting out a playable test build so I can get some insight into how this performing on other people machines and to give some sense of the game’s environmental scope and scale. I’ve also been exploring procedural animation techniques, most notably for hair physics.
On that note, here’s a quick preview of one of the new locations Arno has been working on. There’s more to come and I may also update this post to reflect this.
Galatea Project Development Blog 
Great job Saracen !
It’s really cool to see that a game dev’ is giving credit to its “players” feedback 😉
I’d also like to highlight that every new post worth it since it makes us feel that the project is progressing 😉
I’m really looking forward to the playable build !
Anyway, keep up the good work ! 🙂
LikeLike
Thank you, feedback on stuff like this, especially when I self-profess to having less experience with it, is actually very useful. This will probably become even more useful later into the development cycle, since the game is very much built like an RPG driven by stats, so getting people’s feedback will be very useful for balancing. That being said, there are some aspects of the game I don’t really want to make public though, too much detail about the characters and storylines would potentially end up becoming spoilers, and there are some other aspects I’m intentionally keeping quiet about since I kind of want them to be a surprise.
LikeLike
I’m happy to see that the project is stil making progress 😉 Keep up the good work Saracen !
By the way, I was just wondering about “how” is the game going to be modding-friendly. What I mean is that, are you going to put the source code on the net so players can add thing throught the Godot engine ? or doing something like sharing a kind of an Godot-like engine that suits Galatea modding ?
Anyway, I suppose that these things aren’t really your priorities right now, since modding will be possible only after the end of game developpement, isn’t it ?
Well, I just want to add that your project concept is REALLY amazing and that your doing a wonderful job 😀
LikeLike
That’s a very good question. I would kind of consider there to be three tiers of modding potential. The first tier is more related to the way the game and the engine reads and processes data, which is a lot more flat and easier to replace then, say, a game made with something like Unity where the majority of the data goes through a process which makes it more or less unreadable when exported. This means that a lot of the game is highly data driven since it’s kind of built like an RPG, and making this aspect of the game easy to mod is actually influencing how the game is built (which unfortunately does make it a little slower to set up, but I think the payoff is worth it). This tier relates to things like creating new locations, characters, hairstyles, clothing, balance, story events, ect., and would essentially allow you to create extensions to the base game with more basic content. The second tier would involve using the engine’s scripting language, and since the majority of the game is written in the scripting language, this more or less gives you the ability to change the core gameplay mechanics in any way you can imagine. Even if you wanted to turn the game into a moe-themed first person shooter, you could absolutely do that. The third tier involves releasing the engine’s core source code, which is actually already available right now, but is still something a lot of developers cringe at the thought of. Generally, the majority of mods won’t require you to modify the engine itself, possibly only graphical enhancers or someone doing something wildly unconventional. However, my desire to release the source code is something which comes more out of principle. I’ve always liked how the Doom community is still going strong to this day as a result, and it makes me deeply disappointed that more developers stubbornly refuse to the same (often making every ridiculous excuse they can think of), even long after their games have been released, and especially those who were built in part by crowdfunding. Gamers should really try to pressure developers to do this more often as it essentially permits a game to more or less live forever.
LikeLike
Awesome job! 🙂
I agree with Maya in the first comment. I love to watch the development of the game! Every little info is valuable in its own way! 🙂 Keep it up! I can’t wait to play! 😀
LikeLike
Thanks you, I’ll do my best.
LikeLike
Glad to know things are going smoothly!
On that note, what did you find that was really clogging up performance in terms of scene structure? That might be good to write down 🙂
LikeLike
Sure thing, when I built the initial school layout, I made the decision that it would be modular, consisting of pieces which clip together like building blocks allowing me to rapid extend the building, change the positioning of rooms, and easily tweak things. The problem was that I may have gone somewhat overboard with this philosophy. I ended running through some profiling tools, most notably one I’d highly recommend called Very Sleepy CS, and it told me that amongst other things, the main performance drain was CPU-bound, coming from traversal of the scene’s octree, basically trying to determine which objects should be rendered or not. At first I wasn’t sure what to make of this of this, assuming that it was a bottleneck in the engine itself, but I would later run the same scene through Unity. Unity can employ the usage of a renderer which takes advantage of more modern GPU features, and it already has an edge on the rendering of skinned meshes due to the usage GPU skinning, but the performance results from the same static scene were pretty much as poor as in Godot, which was all I needed to know that I had made a mistake in the way the scene was designed. To improve things, what I did was start merging objects together. The worst offender in my scene was the fact that each window had each component be a separate object, which was absolutely unnecessary (I suppose I thought it would be cool if they could be opened, but a model swap would be better here). I’m not even done yet, and it made a huge improvement to performance without any sacrifice to fidelity. Now granted, it is starting to dip again slightly due to me introducing more of the school for the eventual playable build, but there’s still a lot more that I can merge in the scene, and I haven’t even started introducing occlusion culling and LOD, which has to unfortunately be set up manually, but should improve things further.
LikeLike
Wow! Thanks for the detail right there… heh so, the octree transversal bottleneck is actually something that the godot developer community is mostly aware of (comes up often enough), I think someone is trying to improve that somewhere. I thought your performance was suffering even with occlusion culling though, that’s what got me worried.
On “each window had each component be a separate object, which was absolutely unnecessary”, that does seem a bit overboard, considering that the “number” of objects does matter.
Damn, if you made some dev logs about these hurdles you find in godot development, they’re trend around the community a lot, consider that.
Awesome as always, rock on!
LikeLike
Okay, I might have actually spoken a bit too soon in regard to solving the majority of the optimization. Just recently, I had started implementing occlusion culling with the portal/room system, and I made a rather unfortunate discovery. It turns out that this type of occlusion culling does nothing to bypass the slow octree traversal of the entire which occurs at the beginning. It basically works like this, it builds a view frustum as the basis for traversing the scene, but this includes every object, whether it is occluded or not. It is only after this process has occured that we start traversing portal/rooms and render instances are simply disgarded at this stage, ditto with object culled by distance. The problem is that the actual rendering is not where the main bottlenecks are occuring, it’s the scene traversal. Ideally, an algorthim more efficent to a portal-based renderer would be to traverse the portals first and THEN only iterate through render instances relevant to the rooms being rendered. This severely limits the ability to create large expansive scenes densely populated with objects, even with agressive merging of objects, since even those not being rendered can severely affect performance with this system, and I really wanted to make it so that each of the rooms in the school could be dense with unique small details. I can see how this problem hasn’t been addressed as of yet, as it doesn’t seem unreasonable to assume that no one else has yet attempted a scene on this scale and detail with Godot, so no one knew that this could become a major bottleneck (the fact that portal system had some broken functionality which I’ve started to fix is indictitive of this).
The thing is, I’m not sure how much time or effort it would take to rewrite scene system like this. This might actually be my que to start getting more directly involved with the Godot community. Ideally, I would like the oppertunity to discuss these issues with the engine maintainer, reduz, as well as the possibility of introducing some of the my already existing features into the mainline. Since you seem to be more directly involved with the Godot community, do you have any ideas on what would be the best way to open this dialogue? I’d be happy to use the work I’m doing as performance benchmarking to help get the engine where I feel it needs to be, and help directly with coding in anyway I can, but I think a solution needs to be decided on which would benefit everyone using the engine. I know there is already plans for a new modern renderer backend, but this is an unrelated bottleneck related to the scene structure, and as of yet, I had not seen it discussed anywhere.
It’s a shame that this is holding up a playable release build. I still want to still put something out soon, but I really didn’t want a gimped and unoptimized version of the school forming people’s first impressions. ):
LikeLike