Summary

[ LiB ]

I hope I didn't bore you to death with all the mundane details about entities, their databases, and their accessor classes. I know you must be impatient to get to the real meat of the BetterMUD, so that you can start making your own cool MUD, instead of dealing with all this low-level management. Don't worry, it gets more interesting after this.

In the next chapter, I start getting into the interesting stuff, such as the basics of the scripting engine and how to abstract the logic and the data of the game away from each other.

In this chapter, you learned to make your life easier by combining many little "mixin" classes to form larger classes that share bits and pieces of functionality. The same concept was applied toward all the databases, and macros were used for the same purpose when dealing with the accessor classes.

In the introduction of the book, I told you about the different layers of MUDs, and how you can hard-code certain parts of a virtual world and leave other parts flexible. As you can see from this chapter, the physical layer of the world is entirely hard-coded, and it is very difficult to change (in terms of downtime of the MUD, that is). That's just one of the things you have to deal with when programming in a static language such as C++.

I want you to start thinking about the future of your MUD projects, however, and think about possibly implementing a dynamic physics system of your own. One thing that I've learned from using C++ is that when you build a static physical world like this, you need to be sure to include data and functions for everything you might need, whereas, as you'll see with the dynamic logic part of the game, you can simply add features whenever you like.

Off to logic!

[ LiB ]