Penrith was feeling a little bare. I have some friendly trees, a few buildings, even some random fences and water, but the ground was still pretty bare. When walking around it was a little tough to tell if you were even moving because the trees might be far off and since there are places where there is little variation in the color of the ground, it was sometimes fairly unsatisfying. So I created tools to add grass to my scenes. There’s only one type of grass at the moment, and the whole process is Super Unoptimized™ but it already looks 10,000% better.
I also turned on shadows for the screenshot above, so that helps. The tool allows you to basically paint on grass, and it works surprisingly well. Eventually I’ll need to add in multiple type of grass but for now I’m happy with it and will probably move on to something else.
I had a chance over the Thanksgiving holiday to sit down with my brother and talk about the game. There are, obviously, a virtually endless number possibilities when creating a game and picking a coherent direction can be tough. Talking it over with him really helped and we decided on a slightly new direction for the game. Since I started on this incarnation of the project I have been thinking of Lyridia as a multiplayer-focused game. I was doing this primarily because I thought that I would end up with a game that other people wanted to play. While this is an important goal, in order to keep working on this in my spare time I really think I need to make a game that I want to play. Hopefully it will also be a game that other people want to play, otherwise what’s the point? But I think it’s reasonable to assume that if I like it, at least some other people will too.
So here are the highlights of the new design for Chronicles of Tright: Lyridia.
- The core of the game is a single-player experience
- There will be a primary story that takes players all the way through the game with side quests that are not necessary but will enhance the experience.
- Multiplayer features will be added later
- Extra content (like instances and raids) will be available for those that enjoy that type of play, but will not be necessary to play or finish the game. Public areas, chat, an auction system, and other features are also planned.
- Choices matter
- The story will require you to make decisions that affect the rest of the game. This means there will be multiple versions of the same core story and multiple ways to finish the game. A reincarnation system will allow players to play the game over and over, making different choices along the way each time.
One big challenge is going to be writing a story that is complete and yet can be extended later if needed. Typically in an MMORPG if you want to add more story, or increase the level cap, you just create a new area and create a story for it. For this game, increasing the level cap or adding more area to the game means I have to modify the whole story to include the new content. I can still add side quest content without messing up the core story, but I don’t think it would work to add content for players at level 60 if the game’s main story ends for players at level 50.
Obviously this is still a very big challenge and will require lots and lots of planning to avoid having to totally redo things later, but I’m excited to have a specific path to follow, and hopefully that means progress will come a bit more quickly.
I’ve missed my December 1 deadline for a demo version of the game, but that’s due to the redesign. I’ll have to see just how much time it takes to fully flesh out the story, but hopefully January 1 is a reasonable time to have something playable up and running. We’ll see.
Math is just hard. I’m an educated person. I’ve never been afraid of math. But sometimes it’s just hard. Especially when dealing with 3d graphics. I fully admit that there things going on in the background of the game that I don’t understand. THREE.js does a great job of abstracting away much of the dirty work, but sometimes things come up that have to be dealt with at a low level and that can get downright frustrating.
Here’s what I’m talking about. I have been working on getting Penrith to the point that I can release a demo-type version of the game. That means adding objects to the world, modifying the terrain to be somewhat interesting, and testing as much as I can along the way. This was all going pretty well until two weird things cropped up. First, my player character started moving *very* slowly. This was confusing because the movement at each frame is based on the game’s framerate so that the speed at which the character moves should be framerate independent. I noticed it especially on my faster development machine. It turns out (I believe) that THREE.js caps the display frame rate to 60 frames/second, but this cap is not reflected by the Clock object. So if the game is running fast enough that it is looping through my main loop at, say, 100 times/second, then the delta on the clock for each loop is going to register 0.01. But if the renderer is capped at 60 frames/second, then at each frame the character is moving 1/100 of the distance he should move in a full second, but only actually doing that 60 times/second, so he movement speed is dropped to 60%. The bizarre thing is that the faster a machine is, the more noticeable the drop. If a computer was capable of looping 600 times/second, the character would at 10% of the desired speed. On the flip side, any machine not capable of looping more than 60 times/second will never see this problem. It was simple enough to just test if the delta time was less than 1/60 and, if so, set it to 1/60, but it was still frustrating to find.
Now, the more complicated problem. My collision detection system is still a bit of a black box to me so I’m thrilled when it works and slightly befuddled when it doesn’t. To make a long story short, I had to apply the world matrix of the parent of each collider object to the points of the triangles the collision system is testing against. Without this tranform the colliders were not rotating and positioning correctly over the rendered objects and I was seeing strange behavior. Again, it only took three lines of code to fix, but required several hours of testing to find the problem nonetheless.
In any case, math is hard and I’m still moving forward. I hope to have a version of the game up and running so that multiple players can simply walk around Penrith by December 1st. I think this is a reasonable goal given how close I am to that point right now.
The design of Penrith Forest is going pretty well. A big part of pretty much every game I’ve played in the last several years has been water features, so I thought it was time to try and tackle some water in Lyridia. I’m shocked to say it really wasn’t all that difficult, at least to do the most basic job of getting something that looks like water into the world. I have a large pond/small lake that now has water in it. It even has waves on it, which is quite cool. I need to figure out an easy way to make videos of some of these features because it would be much more effective to *show* the water gently lapping against the shore of the pond than just talking about it, but for now you’ll have to take my word for it that it is cool, and I’m excited about it.
The world editor is now back in business. I can add assets, I can move them around and rotate them, I can move the terrain up and down, I can paint colors onto the terrain, and I can save the results. That seems like a really small list of things that it can do for the amount of effort it has taken to create, but at least it works. Now it’s time to step back a bit and really design the game’s first area, Penrith Forest. I have a general picture in my head but I need to really know what I want players to be able to do before I just throw some mountains and trees together. Obviously the first iteration will be just that, and I’m absolutely positive I’ll make numerous changes as more of the game develops, but this area sets the tone for the entire rest of the game so I need to make sure it makes sense from the beginning. Hopefully my next post will have some screenshots from the world editor of Penrith Forest!
I have now converted all of the art assets for Penrith Forest into glTF files. Before I had a mix of .json, .fbx, and .gltf/.glb files. While I was doing this I created collider meshes for all the assets that needed them. I also added in the ability to load double sided meshes. By default meshes created by THREE are one-sided. This is an optimization that prevents WebGL from drawing triangles that are facing away from the viewer on the assumption that these triangles will probably get drawn over anyway. This works fine for most things but for very small, simple objects like grass and flower petals I need the material to be visible from any angle. This is accomplished by simple putting the word “(Double)” anywhere in the material name in Blender. This name gets exported and the object loading code looks at the name of each material getting loaded, and if it contains “(Double)” it sets that material to double sided. This only has to be done once, when the asset is loaded, so it shouldn’t have any real effect on performance and will allow me to make all kinds of foliage as simple planes.
The next thing I need to do is clean up and confirm/re-implement the terrain editing and painting code. I had this working at one point, but I’ve changed quite a bit over the last several week so I’m guessing it’s at least partially broken. Once this is fully working again, I’ll put some time into the design and layout of Penrith Forest.
I was plugging along converting my tree models to glTF by exporting them out of Blender as .glb files and replacing the references to the old .fbx files in the map when I found a piece of weird behavior. The glTF files I was loading into the world editor moved strangely. It seemed like each individual asset would move differently when selected and moved. This made absolutely no sense because the code to move any object is the same for all objects, but I could see it happening. I’ve now spent a few days investigating this and I finally figured out it was a bug in what I was selecting. My assets are structured like this (for now):
- Scene (Scene)
- Collider (Mesh)
- Asset (Group)
- Asset Mesh_0 (Mesh)
- Asset Mesh_1 (Mesh)
- Scene (Scene)
- Collider (Mesh)
- Asset (Mesh)
When an object only has one material applied to it (which will likely never happen with a production asset) the exported file contains a Scene object named “Scene” with two child objects that are Meshes, an object named “Collider” and an object named “Asset.” If an object has more than one material it follows the same patter except that the object named “Asset” is now a Group and contains children, one for each part of the Mesh to which a particular material is applied. So if the asset has three materials, there will be three child Meshes name Asset Mesh_0, Asset Mesh_1, and Asset Mesh_2.
Updating my selection code to handle both possibilities was not terribly difficult, but it took me a while to actually figure out this structure of the exported files. I’m sure it’s documented somewhere, but I’ve never actually seen it.
The problem I was seeing was caused by selecting the wrong object. If I select the Asset Mesh or Group then move it around, its transform is still ultimately affected by its parent Scene object. So if I move a selected Group like this strictly along the x-axis, but the parent Scene object is rotated along the y-axis, the resulting movement will be unexpected and it will move off of the global x-axis. Since each Scene object is rotated when it gets loaded I was seeing different translation behavior for each object and it was very confusing and frustrating. Now that I understand the structure of the loaded files a little better I can select the root Scene object and move it, and everything works the way I want it to.
One of the primary lessons I’ve learned through this whole project is that I have to just keep looking at it. When frustrations come up, and many have, if I just keep working on it a little at a time I will eventually get past the problem. Just last night I was seriously considering scrapping the whole thing and starting over with a 2d game engine like Phaser. Now I’m glad I didn’t because I didn’t even have to change much to make this work, just invest some time and effort into understanding what is actually happening inside THREE.
Here’s that fishing shack I mentioned.
The ground and the water are just placeholders so that the building wouldn’t just be floating. I added some crates around the back door as a part of this asset, but I’ll probably end up separating those off and placing them in the world editor. That way the terrain will be a little easier to create around this building, and I can just place the boxes on the ground wherever it ends up. This whole thing is, of course, subject to change since I don’t really have story built around the building yet, but I still think it looks pretty nice.
I’m actually struggling a bit with deciding how to move forward. There are still many, many things to do before I have something that could be considered a working game, but figuring out where to focus next has been a bit of a struggle. I’m honestly still a little shocked that my implementation of the collision detection system actually works. I need to rewrite that whole thing, but I’m hesitant to mess with it because I don’t want to break it and waste time. I know I talked about broad phase collision detection and spatial partitioning, but I just really don’t feel like diving into either of those right now even though the broad phase thing should actually be quite easy.
I’ve committed to using the glTF format so I’ve been recreating the assets I have now as glTF files. I also created a pretty nice looking fishing shack that I’ll stick into the world once I figure out how I want to handle water. I guess for now I’ll continue converting/improving my art assets and working on the world editor. The editor still works but it really needs to be cleaned up and have some more convenience functions added. I don’t particularly like working on the editor because it doesn’t always result directly in a new feature in the game, but it’s a necessary tool and requires time, so I guess I’ll just keep plugging away at it.
A basic, working system for gravity is now in place. Eventually I would like for gravity to work a little more realistically because right now you fall at a rate of 9.81 m/s, not 9.81 m/s². This isn’t a huge deal, but eventually I want to make it so that falling off a cliff means the character’s falling speed increases until he hits the ground, then use that impact speed to determine how much, if any, damage the character should take in the fall. Still, I’m really excited a player can now stand on top of a box, or a fence, or whatever. There is still plenty of adjusting to do. For instance, I’m not sure what would happen if a player stood on a sloped roof. My desire is that a character would slide down a steep slope but not on a shallow slope, but that will likely come later. Now that the major pieces of my collision system are in place, I absolutely have to spend the time to refactor that part of the code to be more usable. That will take at least a few days, but I’m happy to be moving forward again.