Posted on

Christian: Getting into Gear

This week marks the second week that we have been performing weekly builds of Dawnroot. These builds serve as a way to do integration testing for our game. That is to say, we have all been working on our own pieces of the puzzle in a sort of isolation until now. We started the weekly builds to see how all of our pieces work together, and hopefully find the places that they haven’t. Well, it turns out it is much easier to see what needs doing when you have a “gun to my head we have to release right now this is what we have” game to look at. our first weekly build generated a large list of items to fix, and an even larger list of items to tune. Now, after creating our second weekly build, I’d like to talk about a few things I noticed. First, it is often the little things that make a game feel like a game. Sure a game without movement would be strange, but a game with almost but not quite great movement feels stranger still. Likewise with splash screens and menus. certainly these things should be added as needed for development, and then polished later, but they are more than deserving of time and attention.
Second, is how much faster game development can move when you have a clear marker to iterate on. Often, we would test our features in isolation. This is of course still a major part of our development process, and we will often make fresh scenes just to try out a new feature. However, by having a game “released” and unchangeable, we now have a razor to cut through to the most import aspects of our game. One question I find myself asking while playing a weekly build is “What is the part of this game that I would most like to change, or that I find most embarrassing.” Often these are areas that we prepared for and just need to be tuned, but some of the time we find something that we didn’t think about until we saw everything together in one place. This has been tremendously helpful for getting our priorities set. Hopefully, we will see a lot more tuning as we iterate on the builds.
Posted on

Christian: Come again?

It has been quite a while since the last journal I wrote. Needless to say, the game has improved quite a bit since then. The AI has gone through several iterations, and now is getting to where we need it to be. The behavior tree model that RAIN uses is meeting our needs nicely for the time being, and the AI now behaves more or less like you would expect. We’ve been working quite a lot on movement and traversal options, including swimming, sidling, mantling and using ladders. This is all in the service of allowing more interesting puzzles, and they provide a more fluid feeling movement system in general. For the most part, our biggest challenge has been fixing the never-shrinking list of bugs. The bright side of this is that now that features have slowed down a bit and we’re fixing more bugs, we’re able to start creating more specific test cases and try out entire sections of our first level. Basically, we’re getting a little bit more into content than we were before, which is nice. Now, not everything is a grey box, and it’s starting to feel more and more like a game! For me personally, the next thing on my plate (besides the ever present bugs to fix) is to set up a wider variety of AI to see what feels good and what doesn’t.

Posted on

Christian: And from the Ashes

The workaround is now fully in place, and we’ve managed to make things a good deal simpler. Now, our game has the following structure. Upon game start, a “Setup scene” is loaded. The purpose of this scene is to hold the singletons and the travelers. Basically, anything that there is only one of (e.g. the dialog database) or that is expected to move from scene to scene (e.g. the player gameobject) is placed in this scene. Also in the setup scene, is a script which waits till the setup scene is loaded, and then additively loads the specified scene.

Continue reading Christian: And from the Ashes

Posted on

Christian: Don’t fear the Reaper

The holiday season was a great one, but now it’s time to finally catch up with all that we’ve been doing. What we’ve been doing the most of (from my perspective anyway) is cutting down the game into a more manageable scope. This is undoubtedly a good thing, as it means that what we have in the final product will be more focused and polished. So! lets take a look at what’s changed. 
First, the dialog system has been modified to deal with more than two branches at a time. Originally, we wanted the player to be able to “interrupt” the conversation, almost like someone with a megaphone telling the conversation participants what to do. However, we’ve since moved to a more subtle dialog method. Our new method allows for more branching paths, and integrates items into the dialog system. With our new system, the player uses words that they’ve learned to respond to npcs. Sometimes these words are in fact representing items, so for example, the player could give a yam to an npc that asked for one. This gives us a lot more flexibility with our conversations.
The next thing that is substantially different is the AI. As stated before, the AI system was quite clunky to work with. However, the behavior tree system that we picked up also had a problem, in that it seemed to be incompatible with certain situations that cropped up quite often in our game. Namely, if an NPC wasn’t in the scene when it was loaded, but instantiated afterwards, the behavior tree would freak out. This left us with a conundrum. We could either give up this really nice system, or find a work around that worked with the package. Well, I’ve been experimenting with a workaround that seems to deliver more than it takes away. The workaround requires changing the way we’ve been setting up our levels, but in making the change, we can cut out large parts of the level manager, AI manager, and navigation code. It’s kind of painful to look at cutting out code that we spent lots of time on, but the reduced complexity is really quite worth it. Going forwards, things should run much more smoothly with the workaround in place.

Posted on

Christian: Don’t dam the flow

A lot has happened since my last journal update, so this is going to be a little bit more summary than explanation. The decision was made that the AI we had was too clunky for our task, so we changed to using behavior trees. Behavior trees work excellently for both the size and scope of our project. Next up we started on redesigning the dialog system. Originally, the dialog was going to require only a yes or no from the player. However, we decided that a type of item based dialog would be best, so I have begun overhauling the dialog to allow for item-speech interactions, as well as more branching. Two of my main goals for the overhauled system are to improve the way the dialog database selects dialog, and to improve how dialog is created. We’ll see how it goes, but the first steps on the upgrade have gone well.

Posted on

Christian: AIs can think, but do they have soul?

The AI for this game is an interesting beast. Right now, I can see that it has a lot of power and flexibility to it. AIs can prioritize food and attacking and other tasks. They have needs which they want to fulfill, and in essence they will be able to look a lot more lifelike than your standard JRPG AI. We’ve all seen the ones. They stand in one spot for the entire game, say the same 3 things, and wouldn’t move out of the way of a flock of dragons. Not so with out AI. However, there is one problem that I’m still working out, and it has the potential to make the AI useless. That problem is, they are very expressive, at the cost of being quite difficult to work with. Making sure that states function as intended in the AIs database, making sure that actions perform all of their specified tasks, and so on has meant that I’ve spent the better part of 4 hours just adding a single action. And the bugs for that action haven’t even been fixed yet. This has lead me to another large concern, which is getting the AI to work with the dialog system. I want the AI to be intelligent about engaging the player, but right now, the troubles I’ve had integrating just one new action suggest even more troubles when integrating a whole new system. I’m continuing to search for solutions to this usability issue, but while the AI is technically usable, it may need a much deeper overhaul to get to where I want it to be.

Posted on

Christian: Stress Test

I’m done with level  loading for now. The Json level has proved to be everything I need it to be at the moment, and our level one prototype still needs doing, so it is on to that. Almost immediately it became clear that the AI Manager would need re-working. So, what I’ve been working on is a new spawning method, that condenses the three dictionaries I had previously into one, while allowing for the placement of generic AIs (like enemies) along with the unique ones (like nemmed). So far it is going well, and I think this new system will be a lot more user friendly.

Posted on

Christian: A Star Trek Teleporter

The goal of the level editor is, much like a teleporter, to take the map created inside of the editor, and perfectly re-create it in the game engine. To this end I have bundled all of the data I need into a single json file, mesh included. This week was spent in using the information in that json to build the level in the game world. With some careful planning as to what information is to be included, this has been relatively easy. They most time consuming portion of this task has been creating an acceptable file hierarchy automatically. Currently, the game can take the json file and turn it into a collection of level segments, each appropriately rendered and textured. further tweaks will be needed as I go along, but it is shaping up well.

Posted on

Christian: Itty bitty pieces

After a significant amount of time, I’ve been able to get the uvs and curved pieces more or less sorted out. As a result this week was spent dealing with the saving procedure. The way the game uses levels is a little bit complicated, but the basic method is that each “zone” is broken down into different “levels”. Each level is of a uniform size (for example, 10 units), and that allows us to tile the levels, only keeping up to 16 loaded at any one time. However, this creates the need for a level slicer when we want to make levels in the editor. It’s a really big pain to edit only one level at a time, so we want the level editor to work with zones, and not individual level tiles. I’ve done most of the groundwork for level slicing this week, so on that front only minor adjustments remain. Once I’ve got the level cut up, then I can begin the work of compiling the slices into level tiles, and then combining all of them into a single json file.

Posted on

Christian: 50/50

Well, I was right about the curved pieces going well with the existing data structure… sorta. As far as geometry goes it’s smooth sailing. I had to cut the curved pieces into faces, which admittedly took a bit more doing than I expected, but in the end I was able to get curved faces for both convex and concave edges. Next up was inserting those faces into level builder, and again it went relatively smoothly. after a few minor modifications, the level engine treats the curved pieces just like the triangles and stretched quads that they replace. The part that became difficult was the texturing system. There were not that many vertices to keep track of before now (at most, 4). After adding the curved pieces, I have to keep track of up to 18 vertices and their uvs and normals. So this is going to lead to a lot of new uv configurations. It isn’t difficult to make new uv configurations, it just takes a while, so hopefully it will be smooth sailing from here.