Here’s another short update and video. I’ve been experimenting with basic AI navmesh pathfinding and navigation. For the NPCs, I’ve refactored the player’s movement code in such a way that it can be used by NPCs too, and while I was doing this, I also redid the movement code yet again to solve most of the physics-related glitches people had reported in the last playable build. When I release the next build, movement should be more stable and graceful. I’m going to focus mostly on polish and bugfixing, and then I may release another build shortly after featuring the AI character. Although I’ve gotten a lot of feedback on the character, I haven’t had time to do any further revisions just yet, but I plan to improve it in the near future. There’s also a feature which I think people might actually find really interesting which I may consider implementing soon, but I’m keeping it a secret for the time being since I don’t want to implicitly promise one way or another as to whether it’s actually going to be implemented, but I get the feeling it’s something people might find a lot of fun, especially with the project in such an early state.
Regarding, the translations, the response to this has been incredibly positive. I’ve been receiving early translations in Polish, French, Russian, Germany, Spanish, Italian, and Swedish. I would like to take this opportunity to thank everyone who has contributed translations so far. This is still something of an experiment, but so far, I think it is going very well. Galatea is still a very small project and this blog does not get much traffic, but it appears that for the traffic it does get, it seems to have a very international audience, so allowing even these early builds of the game to be enjoyed by people in their native languages can only be a good thing. I hope people will continue to send me further translations as the game develops.
Sorry for the delay with this update, I ran into a lot of issues along the way, but I’m happy that I finally feel ready to share what I’ve been working on. The majority of my time has been spent on completing the character model I’ve been working on, rigging her, animating her, and finally getting her into the game. Getting this character into the game has raised some further issues though. Continuing what I mentioned a while back, performance regarding skeletally animated character is particularly poor in the engine right now, but I’m hoping this will be improved soon, and there are also various parts of the import process concerning animated character which are downright broken and will need to be addressed. Still, at least now you can see her in motion, and this should give you some insight into whats coming in the next major update.A lot of the delays on this character came from feedback I got from a select few people who suggested a lot of improvements. I’m still not entirely happy with it, and will likely continue to improve it further, but I would really appreciate your feedback on seeing this character since this is actually my first attempt at character modelling, rigging, and animating. I am aware of some issues already like a slightly unconvincing run animation and the fact that the hair intersects with the body, but this will hopefully be solved with the introduction of physics simulations for the hair model.
Incidentally, if you’re an artist who thinks they can step in and improve this character, either via modelling, animation, or texturing, please consider contacting me.
Quick Localization-related ammendment
A few people have contacted me about wanting to translate Galatea into their own language. While there isn’t all that much to translate, I’ve decided to host the strings .csv file on a Github repository so people, if they want, can contribute translations of Galatea into their own language and I’ll include them whenever I update the game. Now, this won’t encompass all the strings in the game, and there are two types of strings which would both need to be translated for a full localization: generic system strings contained in csv files, and visual novel scripts written in a custom scripting language. While I will start to include some of script files, there is likely to be a LOT of narrative planned for the final game, and I don’t want to make everything public for the sake of story spoilers, and would generally prefer to work on this aspect with more professional localization people/teams. However, if you just want to have the base game available into your own language, feel free to translate what I have made available. The engine is unicode, so it should be possible to translate into any language, but there might still be some font issues related to CJK and right-to-left languages which I don’t yet know about.
Now, about git. I understand that git is very complicated for non-programmers (and even quite a few programmers), but since the strings in the game will be subject to very frequent change, I want a system which instantly allows me to update and revise data in the same way I work on code. This of course means that translations will become obsolete very quickly, so you will be responsible for making sure your translation remains in sync with the rest of the game. If git is too complicated for you to deal with but you still want to translate the game, just click the ‘Download Zip’ button on the Github page, and send me the updated file via email and I’ll commit them for you. Either way, you can find the first .csv file in the game here (https://github.com/SaracenOne/galatea_localizations).
Okay, so I’m putting out the first public test build of the game today. As stated before, this release is still very light on overall content, not really containing any actual gameplay or characters, but will allow you to explore part of the environment due to appear in the full game (which has unfortunately also had to be scaled back for now due to performance reasons cited in earlier posts). This should at least reflect some aspect of the game, since exploring 3D environments will be a part of it, and this is something of rarity for this particular genre. Honestly though, I didn’t really want to put out anything playable at this stage, but a lot of people had requested it and are likely eager to see some of the stuff being worked on, so here it is as promised.
Now, a few facts about this release: first of all, it will likely have bugs, it’s built from a custom fork of the unstable development branch of the Godot game engine I’m using, and I’m already aware of a couple of bugs which have not yet been fixed in this release due to the seemingly random nature of their occurance.
Secondly, it’s more or less what you see is what you get; this release is simply to show off an in-progress look at the school environment and nothing more. Again, some people might be let down here, since there is no real gameplay and there are no characters as of yet. I did manage to get the phone camera to work as some of you may have already seen, so there’s that I guess. However, I’ve already teased at a character model I’ve been working on, and finishing and integrating her will be the primary focus for the next major release, which should be a LOT more interesting than this one. I’ve also exchanged some emails with the lead programmer and maintainer of the engine I’m using, and said he will fix support for GPU skinning in the next few weeks, which should help performance when I introduce characters in the next major release. I will also be merging some of my own code in the mainline.
A lot of people on the YouTube channel commented that they felt the default FOV was too wide. While I personally think a 90 FOV is a good default value (I think most modern games have what essentially amounts to glorified tunnel vision), I’ve lowered it down to 80. However, you can still configure it yourself by changing it in engine.cfg file distributed with the game with a text editor, or by using the console command ‘set_fov’. You can also change other configurations in the engine.cfg file, including resolution and key bindings. The lighting is also a lot better this time, although still not ideal.
Finally, in order to justify the existance of this release somewhat, I’ve hidden a very small secret/easter egg in this build. See if you can find it.
Hello, just a short update. I am still going to release a playable build, and if everything goes according to plan with no hiccups, it should be out within the next couple of days to a week. I just want to try to add some more models to the school and missing collision hulls, as well as adding more interactive hotspots to the environment.
For now, here’s a video showing off one of the new features I worked on recently. I redid the raytracing code for the phone and added support for the phone’s camera. I’ve also got some more really nice new sketches contributed by Akainai this time showing off close-up head shots and emotions of some of the cast. These will actually prove very useful in improving the quality of the 3D model’s head.
Other things I’ve been working on recently are, as I mentioned in my last post, adding fixes and improvements to the offline light baker, and adding the framework for interactive objects, so far including doors and areas in the environment you can examine which is hooked directly into the visual novel engine giving us a framework very much like that of a western point and click adventure game. The game also now features working passage of time, although so far this only effect this has is that both the ingame clocks and the digital clock on your phone will accurately tell the time now. So far, I’m considering having passage of time be a 1:1 match for passage of time in the real world, since the way the gameflow is structured is that certain activities, studying, attending class, ect., will make a predetermined amount of time pass automatically. Furthermore, I’ve started adding in various sound effects and redoing a lot of the code for handling 2D screen elements as well as lots of other minor bugfixes and improvements. One of my contributors, Arno, also recently touched up a bunch of the early models I created with brand new texturing which I think looks a lot better now.
Another feature I’ve been working on which unfortunately won’t be ready for the release build is a brand new driver interface for gamepads on the Windows version. To explain why this driver is necessary, I should first explain the problem with gamepads on Windows. A question, have you ever noticed that most modern games will mostly work automatically, plug ‘n’ play basically, with gamepads, but only Xbox 360 gamepads? If you try to put in another pad, they usually won’t be recognised, and you’ll be forced to use a third-party solution to fool the game into thinking it’s an Xbox controller. This is because there are two main APIs you can use for pads in Windows nowadays, DirectInput and XInput. DirectInput is the older API which works with pretty much any pad out there, including more unconventional ones like steering wheels and flight sticks, however there is a slight problem in that doesn’t read Xbox 360 pads correctly. The specific issues are that it treats the trigger shoulder buttons as a single axis and I don’t think it recognises the dpad. I’m not sure why this is, but some have speculated this was deliberately done by Microsoft to uproot competition in the gamepad market, and that’s where XInput comes in. XInput supports Xbox controller just fine, but the problem is that is ALL it supports; it has no support for any other type of gamepad. Game developers will usually pick just one, and they’ll usually pick XInput since it’s easier to use and provides a more unified approach to gamepad support (by unified, assuming everyone has an Xbox controller). However, I’m not accepting that, and my driver is a hybrid of XInput and DirectInput, meaning it should correctly recognise pretty much any controller you use. I also came across this really cool little extension written for the Godot engine called SUTJoystick which essentially provides a system for automated keybinding based on the gamepad’s GUID (or rather an MD5 hash serving the same function of the controller’s name since the original driver was actually based on a deprecated API called the Microsoft Multimedia Joystick API which does not expose device GUIDs to my knowledge). By using such a library, we can construct a database of devices with correct button mappings which can be distributed with the game and updated as needed, essentially making a wide variety of gamepad completely functional with no prior configuration required.
The reason this won’t be ready for the first public build is that I still need to work out some kinks in the driver as well as build a whole new control scheme specifically designed for a gamepad. It’s also is quite hard to test the full functionality of the feature since right now I only have a single Xbox 360 gamepad.
By the way, thank you to everyone who contributed to the poll in the last post. The results were interesting to say the least, and not necessarily what I was expecting, since the most popular character in that poll was actually not even intended to be a featured character in the first release, instead planned to be delegated as a side-heroine for a post-release build of game, but seeing how popular she turned out to be, I may reconsider that now and place more focus on her. I’ll have more details on characters in future updates.
Quick amendment, but consider voting in the Straw Poll here with your opinion on which girl you find most appealing based on these designs.
I wrote in a comment in my last post on how despite having made significant improvement to the performance of the game’s most demanding location, the school, further development of the location with new content being brought in has brought the framerate back down to unacceptable levels, and has led to the unfortunate realisation that there are some core architectural problems with the engine’s scene system related to occlusion culling. This would require some somewhat non-trivial rearchitecturing of this part of the engine in order to bring the framerate back up. Thankfully, I do have a set of plans for how this could be improved, and it is unfortunately going to result in some further delays, but I think it will be universally beneficial. I’m intending to take my proposal directly to the Godot community and discuss their feasibility as an engine mainline feature
More concept art for glasses-wearing character by Akainai
On one hand though, I’m going try to focus on some smaller goals for the next update. Right now, I’m trying to address some problems which are present in the engine’s internal light baker, mostly stability issues resulting in crashes, but also missing features like the inability to correctly interact with translucent surfaces and raytracing from the skybox. There is also the issue of this feature’s massively high memory requirements (on my end, not the player’s), which has resulted in me having to recreate my toolchain to allow a 64-bit build of the engine in order to be able to use all the memory I have (8gb), but this may still not enough if the scene continues to grow in complexity, and if I can’t find a way to make this process more memory efficient, I may have to save up for some more RAM.
Concept showing two of the cast in potential casual clothes by Akainai
On the subject of less speculative work, while a lot of work recently has been dedicated to research as to what will be required for the new scene system, most of my other focus recently has more been on recreating early systems I had attempted with more knowledge and experience of the engine. As well as a ton of minor architectural improvements, we now have entirely abstract location loader which allows warping between the school and upcoming locations previously teased at before while retaining the state of higher level nodes in the scene. We also have improved physics, a rewrite of the title screen with some new UI theming, and new general-purpose ingame 3D prompt overlay system (to be used with interactive objects and the upcoming character dialogue system), early work on the character creator screens, and a complete rewrite of the developer’s console with a bunch of new commands such as noclip, setting and getting flags in the visual novel engine, and hooks into the new universal audio system which includes multiple volume controls for master, music, sound, and specific character voices. There’s also a ton of new 3D artwork ready to go in the engine but I’m still waiting for the right time to reveal the majority of it. A longer term goal I’m intending to tackle is creating a brand-new procedural skybox and weather system needed for the game’s timeflow system.
A new design showing potential drills hairstyle by Akainai
Something you’ve probably noticed in this post is the presence of the fantastic new character designs for the game’s cast, and my main reason for making this post was that I really wanted to share what these two incredibly talented people had made and hopefully drum up some interest in their own work. Check out their respective pages, they’re incredible, and I hope we can see more from them in the near future.
Same character, this time shown in a maid costume by Akainai
That’s all for now. The three near-term tasks I’m going to focus on right now are fixing and improving the offline lightmapper, adding in a completely generalised system for object interaction in the freeroaming mode, and finishing the character model I’d shown previously. I hope you’ll continue to follow this blog and thank you all for being so patient. While I don’t want to put out a build with such glaring performance problems, I may still do it if these issues can’t be resolved in a timely fashion, but I would still rather not have this form people’s first impressions.
Alternative proposed designs for athletic girl by Akainai
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.
I was internally debating showing this since it’s not complete and I didn’t want it forming everyone’s first impressions, but this is the result of the work I’ve started recently on the base female model. While I feel there is still a lot to improve before I move onto texturing and rigging, I’m generally quite pleased with the level of detail despite it being my first attempt at modelling a semi-realistic humanoid. I posted this primarily because I feel it’s important to get as much feedback as possible at this stage, so please feel free to suggest things which you feel could be improved about this model. There is also progress being made on a second location, the protagonist’s home, by one of my main contributors, and it will soon be adapted for usage within the game. This part should be particularly interesting because we are planning to allow some degree of player customisation for this location, changing furniture arrangements, ect. I’m also experimenting with ways in which the engine can be optimized. I’ve brought in and updated some SIMD code another person had started working on a while back, and have made changes to the engine for the memory alignment required by such code. As of yet, this is still highly early and experimental, and while some minor improvements have come out of these experiments, I’ve yet to get the substantial performance improvements needed, but I’m sure that further research will lead to significant improvements in this area. Usually I would consider optimization something for much later in the project, but the fact is, even with the early static assets we already have, the game is already hitting unacceptable framerates, and solving this issue will be required before I can even consider putting out any kind of playable build.
Anyway, it seems odd to neglect showing off characters as part of the game’s initial concept considering that it is fundamentally what the game is about, so for now, I thought I would share some very early concept sketches. Some of these were done by me, and I personally have no pretence of being a legitimate 2D artist, but I hope that they might at least give some insight into the direction I’m hoping to take the game character-wise. There are also some additional sketches generously done by someone who is already contributing to 3D assets, Arno, but as of yet, we would still appreciate the help of a more experienced dedicated 2D artist.
Arno’s latest iteration of this character. Probably the closest yet to capturing her intended personality.My first attempt at this character. I think I captured her playful spirit, but I’m not sure if I captured her sportiness as of yet.An older sketch of this character.Arno’s first attempt at this character.Guide used in producing the 3D model.
I know this update is kind of shallow, but I’m going to post a follow-up post very soon when I feel the character model is ready. This post may also be updated if some new sketches are done, but for me personally, I’m not planning on doing any more character sketches for a while.
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.
Galatea Project Development Blog 