Progress Report #2

Welcome to your new high school.

Hello everyone, I’m sorry that this update has been so long coming, I’ll try my best to keep you more in the loop in future. The main focus of this update has been building and expanding the high school location and getting it into the game engine, but in doing so, I encountered quite a few technical issues which are preventing me from showing off all the media I wanted. A lot of talented people actually contacted me offering to contribute to the project for which I am really, really grateful. There is, however, one specific area which I still vitally need some help with considering the stage the project is at which could be filled by a talented 2D character artist. I’ll discuss this more near the end of the post, but for now, I’ll discuss what I’ve been working on since the last update.

Expanded School Building

The most obvious aspect of this update is the expansions to the school I’ve been modelling. As you can see, I can now show you a lot of the school from the outside grounds as well as the rooftop, and you might have noticed that school is particularly large, with the intention of it being fully explorable. The school’s geometry is created out of a set modular pieces which are clipped together to form the overall structure, and I have now created enough modular pieces that multiple large tower blocks can be interconnected in a variety of ways for more interesting architecture. As for the interior, I’m also showing off some of the props which were generously created by one of the first and most dedicated contributors to this project, and I feel his work has gone a long way to improving the overall detail and quality of the location. I’ll be interested to hear people’s feedback on the overall design of the school, as it is based on substantial research of common real-life Japanese high schools. I also have a question, I would specifically like to ask people if they would potentially be okay with the windows of the school being opaque when viewed from the outside but translucent on this inside. It’s not ideal or realistic, but the way Japanese high schools are commonly designed makes it very hard to optimize through common occlusion culling techniques since when viewed from one side, many rooms with detailed objects are potentially visible and have to be rendered, and this approach, while a cheap trick, would make it much easier to optimize the scene.

Ingame Smartphone

The phone is basically the ‘swiss army knife’ of Galatea.

This feature is something I’m very excited about and I feel it will open a lot of potential gameplay possibilities. Some obvious ones would be the ability to send and receive SMS messages, make and receive phone calls, and using the phone’s camera to take pictures, but as a modern smartphone, there is so much more that could be done here. I also intend to implement the ingame map screen as part of the phone’s GPS map system, and this would play very well into a game mechanic I would like to try out. Basically, I want the map to be able to calculate the travel distance between locations and pass the time accordingly, as well as having appropriate impacts on your character’s stamina and other elements. I would also like to add the option to choose between walking, biking, and using public transport which would all have different trade-offs. This integrates with a core design philosophy that everything you do in the game, no matter how small or trivial, should have some mechanical significance on the overall simulation. The phone itself still has a lot of bugs (a lot of them to do with event processing) and missing features, but it’s at least functional and moving forward now. I also added the ability to use multiple cameras as separate layers in my fork of the engine to allow the phone to appear as a 3D object on the user’s UI without intersecting with the geometry.

I’ll also discuss the less notable features which are still important and necessary, but may be less interesting to talk about

New Freeroaming Movement Physics

I anticipate many sugoi bentos being shared up here. Is your heart going doki doki yet?

This is one of those features which is kind of hard to explain and quantify, but I’ve basically implemented a new movement system based on kinematic physics rather simulated rigid bodies. The upshot of this is more fine-grained control over physics, allowing me to create more graceful movement around the environment. The trickiest part of this feature was probably the code for ascending and descending staircases. Godot does not feature an equivalent of Unity’s Character Controller class which had inbuilt support for ascending step heights, so I had to figure this aspect out from scratch. At first I tried this fairly complicated technique which involved casting a ray from a rotated point around the collision hull relative to the normal which the player collided with, and doing a variety of tests to see whether it would be possible to ascend. However, this proved unreliable in certain circumstances, so I ended up using a much simpler solution which involved leaving some space at the base of the collison hull and simply casting a ray from there, checking the difference, and adjusting accordingly. Furthermore, the movement system can handle sloped surfaces correctly, and I also added view bobbing for purely aesthetic reasons. I purposefully disabled jumping because I feel it serves no purpose in this game and wouldn’t be very elegant on certain control schemes. This system might arguably be considered overkill for a game like this, but I’m still happy to have done it right rather than half-heartedly, and it will also be used by the AI characters when they are introduced.

Visual Novel Script Interpreter with Ren’Py-like Scripting Language

Why am I showing off the toilets as a showcase of my new waifu simualator again?

I now have a working implementation of a basic interpreter for Ren’Py-like scripts which can be used to write dialogue scenes. This should be very familiar to a lot of people and the base syntax remains more-or-less the same. It does not, however, support the obvious benefit of being able to embed Python code directly inside of the scripts. Instead, I’ve started working on providing replacement methods for comparison operators, setting flags, and callbacks into the main game logic to control things like character animation and camera movement. This features should be of interest for people who may want to mod the game, since as a result of this, modifying character dialogue and creating new story scenes will probably be one of the easiest things to do. Internally, I call this Ren’Py-derived language GalScript. I also added a developers console to better interface with this and other systems.

Multi-threaded Resource Loader

Just a random long shot of the corridor. ‘Nuff said.

I’ve re-architectured my game logic tree to be built around a resource loader which dispatch requests to background threads along with a lot of general improvements to making communication between game logic elements more elegant and robust. While this is currently only used for loading assets behind a loading screen, it has the potential to dynamically load things even while ingame scenes are still running. The nice thing about this is that it was not a hack or anything, it is simply implemented as a by-product of the way the engine is designed.

Where do we go from here?

The same classroom people have already seen before, but now with some new and better props and textures.

While a lot of the issues encountered during developing this update were straight-up bugs (the light baker needs some fixes badly), there were also a lot of performance bottlenecks that were encountered, with three of the most notable being the speed of the shadowmapping for the directional lighting, moving objects sampling light from the baked lighting octree, and the rendering speed of skeletal meshes. The Godot engine is still young, but is maturing fast and has a lot of future potential. I already have a Github account for my fork (https://github.com/SaracenOne/godot), and I hope in some way the work I’m doing on Galatea might passively benefit others making use of the engine since Galatea is looking to be one of the more demanding games being developed for it. I would really like to work on making the engine faster with things like SIMD optimization and hardware accelerated skinning, but I’m concerned that too much time spent on the more technical aspects of the game will allow me less time to work on the core gameplay aspects of Galatea, and as such, I would have less to share with people; I’m already unhappy with how long it took to get this update out. Even if Galatea is not something you’re specifically interested in, I would encourage you to check out the Godot engine (http://godotengine.org/) as a viable alternative to things like Unity, and (if you’re a low-level technically-minded programmer) consider contributing to make it better, since you would not only be helping me, but everyone else using it.

I’m currently looking with dread at a laundry list of issues that I need to address after bringing in such a large environment, but a new aspect of the game I’m eager to work on next is designing and implementing the planned heroines, and I’m wondering if I should put other things on hold and just start working on this aspect straight away, since it’s probably the most fundamental appeal of a game like this. I’m nervous, but somewhat confident I can pull it off. There are some technical specifications the model will need to be built to though. For example, it will be designed to take full advantage the morphing system for facial animation, and I intend to use a rig with bones matching those of Miku Miku Dance characters in order to provide compatibility for modders. A further potential idea is designing a character with customisability in mind, specifically using the morphing system demonstrated in the last update to create a face mesh which can be morphed into a variety of different shapes and then cached as a new mesh. Not only would this make it much easier to create new characters off a base template mesh, it could also open the doors for potential customisation of the protagonist.

This leads into a very specific area I could use some help with. As I stated, I’m currently in dire need of a 2D artist, someone who is highly capable of skilfully drawing and designing characters in an appealing anime-style. If this is something you feel you could help out with, please get in touch with me. Interactive and highly appealing characters are the main focus of this project, so this is arguably one of the most notable roles, and your artwork may become key in defining a huge aspect of the game’s overall art direction.

That’s all, I’m sorry this update took so long and was so lacking in interesting content, but I hope you’ll continue to follow the development of the project. If I indeed start working on the new custom character mesh, I may put out more frequent updates concerning that since it will be fairly easy to show and I would appreciate people’s feedback as it develops.