Earlier while I was making the tower pieces in Blender, it became apparent that managing low LOD collision meshes for each piece was going to be a headache. So to speed up workflow I made a nice improvement. Now the exporter will detect presence of custom collision meshes and flag them. But even if they’re not there I can set a custom flag per object that tells the runtime system to auto-generate the data from the renderable mesh. I also partially added support to free the mesh data afterwards, in which case the system will rely strictly on the bounding box hierarchy generated from the mesh.
I just finished going over the current tower scene and removing all of the unnecessary collision meshes, though in a couple of cases of more complex collision shapes the meshes are still necessary.
In this screenshot every object has a custom collision mesh and now 90% of them are removed and managed automatically. This will greatly improve the level design process.
…albeit a short one.
I decided the game would be slightly more representative with a walled tower instead of just a first and second floor with blocks connecting the two.
I also made some camera adjustments to fix some near-z plane clipping that would occur when passing through the doorway. One of the projection matrix elements was incorrect.
I’ve been thinking of calling the game “The Tower’s Spire” or something along those lines. Here is the concept:
[ A young man pilots a small wooden boat toward an unnatural stone structure protruding from the sea. The only other occupant of the boat is a girl, struck with a curse that traps her in sleep forever. The structure is an ancient tower that rises seemingly forever into the sky, disappearing into the clouds. There are hints of legends that say the Tower's Spire is the Tree of Life and the fruit from it can cure any illness. The Tower's Keeper stands watch below, judging the intentions of visitors. For these two latest, he grants the young man permission to ascend. ]
The focus of the 11 Day Game project has been to build a (very rough) prototype of the above. While the current tower only takes a few seconds to ascend I am proud to say that all major game systems are represented. From this point forward it is all iteration.
So without further ado, here is the very first prototype. We’ll see how things evolve from this point.
Sort of. At least as done as I expected to get. What I have now is a rough prototype with all major engine systems and game components represented in at least a basic form. The game’s primary objective is in place and is achievable. I didn’t implement start-up or ending screens because once they’re implemented they’d be shut off to facilitate rapid iteration.
I made a video of me starting the game and completing the main objective but I will wait a bit longer to post it. It takes all of 30 seconds currently to “beat” the game but that is not intended to be representative.
Anyway, I spent Thanksgiving day away from the computer, though tempted I didn’t turn it on even once. I made a lot of progress today though. I added the scene component that holds the main objective, added the main objective, and added another critical mesh to the boat. On the tech side of things I was able to tie in the adventure game scripting system. Now in Blender I can specify “activation scripts” on objects. Then when the engine loads the scene it calls a callback per object and gives the game a chance to attach supplementary data management to each object. That includes script management. Now as I move around the level I can activate scripts on the various characters and objects. Those allowed me to create very simple but complete story and objective elements.
I’ll leave it at that for now. Tomorrow I intend to make a new post that fills in all of the game details that I’ve been leaving out, and shows the (very) rough prototype of the game in video form.
Lots of interruptions today, but I did get the rest of the static meshes moved over to the scene export process – by removing the game code and adding the properties containers via Blender.
I’ve been considering various methods of instantiating terrain via the scene pipeline but it didn’t feel quite right so I reverted it.
Now it’s time for PHYSICS! and this relates heavily to the gameplay that I’m visualizing. I’ve done some experimentation in the past from the book Game Physics Engine Development but none of the code is present in the engine now. My intention for some time now has been to get the animation system working, then level editing capability, and finally start experimenting with physical interactions between the two components. This book defines a physics system that simulates individual particles, and then applies pseudo-rigid constraints between them. My plan now is to re-implement the particle simulation and apply one of those to the player, and then apply jump impulses. My objective is to get the player to jump on top of one of the boxes, and to be able to get back onto the pier and platform after falling into the water. At some point buoyancy will come into play as well.
Just a small update. Previously on scene load I was requiring the static meshes to be pre-loaded, so at game start-up a list of resources had to be loaded. Now the scene load is capable of searching for pre-loaded resources and then loading them if they’re not present. This trims down on the amount of game-specific code, but it adds a couple of gotchas to the data management on the Blender side. It’s a fair trade-off though.
I added collision mesh checks and flagging to the scene exporter. Now when the scene loads, after the static mesh is handled it will run a similar process for collision meshes and automatically pair it with the proper physics transform.
I removed the hard-coded loading of the base and pier so now the main architectural components are all coming in from the scene and can be repositioned, etc. through Blender. I still have to add the Boat and Keeper which are also currently static meshes. That should take about five minutes.
First thing tomorrow I’d like to add support for a “player start” and “npc start”. I’m debating whether I want the player to be instantiated by the scene… I’m thinking not, but it seems to make sense to have NPCs work that way. I’m not sure there’s a significant difference between the two object types though so I need to think on the architecture a bit.
Anyway, I’m done for the night. I’m pretty excited about the gains made today even if it wasn’t too interesting to show. I think tomorrow I’ll be able to start touching a bit on gameplay.
The scene pipeline works! This feature is pretty exciting to me because it means that Blender is now effectively my level editor. On that note, I deleted the old in-game level editor code. I originally went that route because I didn’t want to learn Blender scripting, but that has definitely happened so…
The six blocks in the scene below were instanced in Blender, positioned, and exported in a matter of seconds. This will be a huge improvement to my workflow for this game or any other that I pursue down the road.
I’m pretty excited to see how far I can take this. Hopefully before the end of the 11 days I can try to export some menu screens as scenes and then have game logic operating on them. Eventually I’d love to try to do a simple cutscene through the same pipeline.
The cool thing here is that the scene manager is part of the engine, not the game so it is pretty automatic. It is loading the data in a game independent manner, but a game could also attach custom properties and then parse those via callback once the engine properties are loaded into the engine.
Next I’d like to spend a little more time moving some of the hand-placed objects over to the scene exporter and out of game code. I’ll start with the platform and pier.
Also, it has become clear from the screenshot above that my vertex normal exporting is not providing the necessary data for flat shading. I’ll try to fix that up.
Yay! That wasn’t too hard. 1.5 hours to export the simplest possible world. Each object that I want exported will have a “prop_container” child object. The prop container will allow me to easily copy/paste properties between objects and contains a list of custom properties that I want access to in the game - for now just a game-recognized object type. I tack the object name and location on to that and we’re good to go.
Step next: load the world file into game.
My next task will involve adding hundreds, if not thousands of world components to the game. So far I’ve been adding them in code, except for the player start position which is set by a level xml file.
Since this approach is no longer going to be practical it is time to create a Blender world export script. I’m hoping it will only take a couple of hours, but it could take all day. I’m starting on it now and will post again when it’s functioning.