Progress Report – School, Interactive Objects, Gamepads, and Camera Phone

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.