Dev Blog
Fourth Quarter, 2015 (slightly delayed)

January 31, 2016

   We seem to have missed our next quarter post, so better late than never, here it is. That’s going to be the theme of this briefing, ‘better late than never’. In the last Dev Briefing we noted that we were close to finishing the Publisher Demo, and that we had more ‘paths in the road’ than anticipated. Well, that was true, but there were also a lot more bumps in the road.

So let’s talk about those bumps. Of course, in software terms, a bump is called a bug. And if you will remember the bad guy from Men In Black, he was a gigantic bug. Well, we had one of those too! In fact, this bug has taken the better part of four months… and counting. It isn’t a matter of finding it, the time has come in fixing it. In most cases, a bug is more difficult to find than to fix. In the case of the foliage bug, it is the opposite. We soon discovered the issue, and then started trying to fix it. Soon we discovered that a quick fix wouldn’t work, so we attempted other methods of repair. Eventually, after several of these, we realized that the whole damn barrel of apples was bad (sorry, mixing metaphors here).

Let me be more plain and dispense with metaphor’s completely. We found that our approach to rendering trillions of unique trees, all their leaves, as well as every blade of grass, on an Earth size planet, was crashing the system due to just overwhelming resources. Of course, it isn’t that simple, there were also issues with transitions from one rendering type to another, etc.

So, have we decided to do it the old fashioned way and give up on all of this! Hell no! What was required is a new plan, and a whole lot of new math. We had to back up and start fresh, and come at things from a new direction. This is being done, and though how we do it is changing, what we are doing remains the same.

OK, so that’s what has been holding us up for an entire quarter. However, that does not mean that progress stops in all areas while the programming team rewrites the foliage and LOD system. Other members of the team have been working on new elements. Since we talked about programming issues, lets now talk about programming advances.

Our NPCs (vast numbers of them) use our own method of S.I. (simulated intelligence). This allows them to live their lives in the Reflected Worlds without following any linear script. This also means that at any given moment we don’t know what they will choose to go do, or where, or with whom. Now, we can make educated guesses. It’s like trying to predict where your friend is and what they are doing. You know them, and they have routines and typical things they do, so you could take a pretty good guess, and sometimes be right, but not always. They might do something out of the ordinary occasionally.

As neat as this is, and as real a simulated life as our NPCs might mimic, it opens the door for them to do something… odd. In this case ‘odd’ means something they shouldn’t do. Or, a bug. The first thing we did for this was make them ‘self-healing’. If they get ‘confused’ they don’t stop. They go into a mode where they work on getting themselves back to doing things they should be doing. This could take anywhere from a few seconds to quite some time, but they do get back on track on their own. While doing this, they still ‘look’ like they know what they are doing, at least to any player. This system has been working for several years now, and we let the game servers run weeks at a time. The NPCs keep going, and always get themselves back on track.

However, we added a secondary system, NPC reporting. This means that any NPC who gets confused reports this to us. The report shows which NPC got confused, and where they got confused. You can then click right on the location or the NPC and teleport there to see what the problem is. This system has also been working for several years. So at this point when NPCs get confused they start fixing themselves and report to us that they got confused, and where.

This finally brings us to the new feature added last quarter, NPC logging. Since NPCs fix themselves, getting temporarily confused is not a big deal. However, this did put variable length delays in while the NPCs get back on track. We wanted to fix these moments so that the NPC didn’t have that delay in the first place. We knew where and who got confused, but not easily why. Now our NPCs all log exactly what they are doing, what decision they made, when and where, why they choose to do that, and more. If we open up the log on any of these NPCs we can look back through their history and see what they were thinking, at what time and place. Not only that, but while open the log is live, so we can watch them making new decisions.

This makes finding the error in their choices very easy to discover, and therefore fix. Of course, they still get themselves back on track, but now we are told who, what, where when and why a delay occurred.

Our programmers have also been working on other elements of the terrain, including terrain shape manipulation tools. We created the system for this, and added the first (of more to come) tools for hand editing the terrain. Remember, our world creates itself initially. It makes a planet, then continents are made (with our continent tool). At that point, all of it goes through simulated millions of years of wind, water and gravity erosion. This generates a very realistic terrain. It is then that the foliage tool would start growing plants (see above, we’re reworking that).

However, just because a planet generates itself does not mean that we don’t want to mess with it! This is a fantasy game, for one thing, and we want to put fantasy elements into our terrain. What is a fantasy element? Well, for example, the Citadel is supposed to sit on this very odd mountain that goes up in a spiral. Not only that, but that spiral has sheer cliffs that go down to the ocean, which goes nearly all the way around, leaving just one peninsula connecting it to the mainland… and that peninsula has a canyon.

Expecting to find this generated on a planet, naturally, is a needle in a haystack. I suppose if we generated the planet a million times, and search all 900 million sq. kilometers each time, we might eventually find this formed naturally. Or… we can make terrain manipulation tools, pick a spot along the coast and form what we need where we want it.

Hence the terrain manipulation tools.

The first tool allows us to do that. We can create a variable size brush, with falloff, and go in and paint strokes of variable opacity to raise or lower the terrain. We can set the frequency as well, to affect small or large features only. We can also smooth if we want, undo and redo strokes, or reset back in case we royally mess it up. This is all done in the live world, so we can see the adjustments in the game.

This is neat, and allows us to mess with the terrain to our hearts content, but it isn’t the only tool that will be added to this system. Now that the main system for this is in place for this first tool, future tools can be added even more easily. Next up (once that pesky foliage system is working!) will be the foliage tool to let us hand edit the foliage. For example, let’s say we want to hand place a new village in a forest (these will be automated as well, but still). We could scout a place where there is a clearing and put it there. With the foliage tool we can create a clearing anywhere, or add in foliage where we want it.

Then there is the road tool, which again allows us to modify the auto-generated roads and hand paint in any type of road where we want it. Anyway, you get the picture. These are tools we need to hand alter the game, where needed, and the first of these is now functional, and it gives us the system to make more.

We got to play with the first version of the Terrain manipulator tool last week, and made a list of a few improvements we want, which will be available next week.

We are also working on some parts of the game that have little to do with the publisher demo, mainly things like the Player Database and Login Server. These are important for allowing our Patron team of players into the game world. This was meant to happen late last year, but due to the delays in the foliage (curse those plants!) we have had to put a lot of resources into reworking that code. This meant taking them off of other things. One of those is the Player Database and Login server, which are needed if we are going to let players into the game world permanently. Or course, initially those players will be the Patron Team. Hey, they donated early when others didn’t believe, so they should get in first! They will not be in a finished game by any means, but they will be in the Reflected Worlds, and be able to watch the game world progressing from inside.

How soon now? Not sure, we did assign a programmer to get back to work on the Player Database and Login Server, so we expect that to work soon. After that, well, there are a few other systems that are needed. For one thing our new Cell System, which I talked about last briefing, is awesome! But, we need to take it from BackStage (our tool set) into a player mode. Otherwise, players can’t freely travel from cell to cell. As soon as the Player Database is finished up (as mentioned, it was started and put on hold, but is now being worked on again), we’ll get programming working on the player cell transfer system as well. So a few things to go yet before we can let Patrons into the game, but not too much.

The Art Department, and Level Design have been working together on a new system, towns. Now, that seems pretty obvious, but truthfully we hadn’t decided we were going to have towns. We worked on a village system, and we worked on castle and fort systems, and thought that would cover it. But, better sense prevailed and we decided to make a town system. Our Reflected Worlds are a dangerous place, and any place that has a community of people will be under attack at times. Therefore, every town has to have a stout wall around it for defense. Putting a wall around something means that the real-estate is limited inside. Over time, as more people come to the place to live, they cannot expand outwards easily, so they tend to pack things in tighter and taller.

A fort or village becomes a town. To this end we have been creating new art for taller tighter buildings for the town situations, and designing the auto-construction methods for the game to build the walls and town within. A new town construction tool has been designed and put on the programming list. A new wall system for towns has also been modeled.

We hope to put the first town into the game world soon. This will be a test town, built by hand rather than auto-generated (since that tool is on the future programming list for now). However, we will at least be able to see how it all comes together, and works with NPCs living there, etc.

So that’s where we stand at the moment, we’re waiting on the new code for the foliage, and waiting on that has delayed work other critical systems for the demo, which means that once the foliage works, we still have a bit to do before we can get the publisher demo finished. It is all still progressing, so it will eventually get done, making that old statement, ‘better late than never’ true. It is late, but it is also still getting done.

Thanks for your patience, we are working on it,

The MMO Magic team.


(Return to Dev Blog)