Apologies; another screenshot which contains absolutely nothing visibly new. But after far too many hours, I’ve finally fixed up the drawing of procedural models to work either using shared models for common things, or with custom models for things that need to be unique.
Most things in MMORPG Tycoon 2 go through this code. Region boundaries, buildings, monsters, players, NPCs, the GraveShip, quest boundaries, etc, all work through this single interface, so it was important to keep supporting things that were all unique (regions, quests), while also sharing resources between things that were all the same (monsters, players). This also vastly simplified the code, and will make it easier to work with in the future. Bonus!
So the shot above looks exactly like it did before. Which from where I’m sitting, means that it’s pretty awesome. :)
It’s always disappointing to do a lot of work, only to have to undo it again.
I’ve spent the past few hours working on modifying MMORPG Tycoon 2 to keep just one copy of each building model in memory. At the moment, each respawn point that you place (for example) stores its own copy of the respawn point model. This means that memory grows rather a lot, as you place more and more respawn points. The standard solution to this situation is to load the model just once, and then to draw the single model in lots of different places in the world.
In practice, though, actually making that happen can be a little tricky. I’d gone a fair way toward implementing it, before finally realising that the way I was doing it was ugly and difficult; it was going to be a nightmare in the long run. I certainly learned some things from doing it, but it’s always a bit disappointing to end a session of coding by undoing all your changes, and putting things back the way they were before you’d started.
At least I do now have a path forward, and I’ll make a little progress along this new direction before it’s time to sleep. But I would have liked to have some visible results tonight, and it doesn’t seem like that’s going to happen.
Oh well.
Okay, this was probably a little silly, but.. as a further test of the placement-driven terrain painting, I hooked up roads to create sand around them. Showed up a number of bugs, including some in my bounding boxes (vsBox2D and vsBox3D, for those keeping track at home), and in my octree code (vsOctree). Think I have those all fixed, now.
Still have a few minor glitches to sort out, such as roads not properly clearing the terrain under themselves when they’re moved or removed. It’s easy to do that naively, but the naive approach runs into problems when the roads are being removed because the map system is in the middle of shutting down, when you close the game. Needs a bit more work to make all of that happy.
But in general, am pleased with how this is turning out. It’s becoming surprisingly easy to make this sort of operation work with very little effort, now.
So today I managed to do some extensive cleanups of the terrain generation algorithms. (Specifically of the “painting terrain” algorithms which are used on the back-end of the terrain object placement tools)
My vague impression is that it seems to be slightly slower now than it was before, but I haven’t actually tested it. It wouldn’t surprise me if this was the case. Regardless, it’s still miles faster than what I was using a month ago, and still uses a totally reasonable amount of RAM (now back down to 98 megabytes, down from a high of about 600 megabytes, last month).
Also today, I’ve got region boundaries affecting the terrain again. Previously, region boundaries were created in the terrain by explicitly lifting the terrain into a sharp peak when it was near a region boundary. Here, it’s now drawing a brush stroke of mountains along the region borders, which gives a much more natural mountain range, which I like a lot more than the sharp ridge line we had before.
My last task on terrain (for this milestone) is to make the radius on terrain-affecting buildings be editable by the user. I’ll probably cheat and just put buttons for increasing/decreasing the radius into the context menu, though that’d be totally unacceptable in the final game. But it should be good enough for this milestone.
After that, the new crop of buildings, and then player AI and the new combat model, and then the milestone will be done.
Mere seconds after tweeting about how nice it is to simplify huge swathes of ugly code into a single small, nicely abstracted piece of easily-maintainable code, I discovered that the small, nicely abstracted piece of easily-maintainable code didn’t, in fact, work properly.
It’s a simple fix to make it work properly. But it’s also an important reminder that a group of lions often arrive during the summer.
Apologies; another screenshot which contains absolutely nothing visibly new. But after far too many hours, I’ve finally fixed up the drawing of procedural models to work either using shared models for common things, or with custom models for things that need to be unique.
