Member Discussions

I'm in the process of converting a heavily modified ROM mud to C++ and
MySQL (for all data storage) and I'm facing some code design paradigm issues
that are making me wonder whether it's worth converting at all. Specifically, I'm
trying to decide whether to convert the more heavyweight structs, e.g.
characters, players, rooms, objects, mobs, etc., to C++ classes. This would be
primarily for two reasons:

- Convert many of the old ROM functions to class methods in order to take
advantage of visibility limits

- Implement a full-scale ORM to provide an interface to the MySQL database for
loading and persistence.

The first point seems like a sound idea to me, but I'm not sure whether it's
worth undertaking the ORM implementation, simply because converting the
DIKU-style of structs to use classes and database persistence seems like it
might be more of a pain than it's worth. I could just start from scratch with a
new C++ mud, but the one that I'm using has a lot of systems that I'm fond of
and want to re-use.

So, just wondering if anyone has thoughts on the matter. I'd especially like to
hear from anyone who's done similar work on DIKU derivatives, MySQL
persistence in particular.

I recently converted our custom Circle to use MySQL for all our persistence needs. I'd say that, although extremely tedious during the initial schema design and db interface rewrites, it's worth it a thousand times over in the long run. We use our new capabilities in too many ways to mention. I shared some details about the adventure here:

http://www.mudbytes.net/index.php/Contact?a=topic&t=3488

I haven't ever converted code from C to C++ so I can't comment on how worthwhile that would be. Just so you know, you don't have to have a C++ codebase to use MySQL heavily and maximize its utility.

plamzi wrote:
I recently converted our custom Circle
to use MySQL for all our persistence needs. I'd say that, although extremely
tedious during the initial schema design and db interface rewrites, it's worth it a
thousand times over in the long run. We use our new capabilities in too many
ways to mention. I shared some details about the adventure here:

href="http://www.mudbytes.net/index.php/Contact?
a=topic&t=3488">http://www.mudbytes.net/index.php/Contact?
a=topic&t=3488

I haven't ever converted code from C to C++
so I can't comment on how worthwhile that would be. Just so you know, you
don't have to have a C++ codebase to use MySQL heavily and maximize its
utility.

Thanks - that's an interesting thread. I'll have to read it in some detail. Good to
hear someone else who's done this with a DIKU mud and had some success. My
main motivation for using C++ was to take advantage of an ORM for
persistence, such as C++ ODB ( http://www.codesynthesis.com/products/odb/
). That way, the database persistence code can be abstracted and hidden away.

If you're sticking with C, how are you handling persistence? Did you just
implement MySQL at the loading/saving points and keep everything else the
same (i.e. structs for the data, etc.)? I'm considering doing that, especially since
implementing an ORM would mean making major changes to every struct that I
want to persist, which would take eons.

(Comment added by Aelius on Sat Mar 3 12:16:25 2012)

I'm also curious as to how you're handling building and OLC. My preference
would be to get rid of OLC and just switch to a browser-based interface, since
that would make syncing the DB and the in-memory stuff far easier.

Yes, more than worth it.

Even if you don't carry through with a complete C++ conversion, at the very least you should consider using new/delete and the string class.

MySQL is also quite worth it. Off the top of my head the only things I personally have stored in flat files are Areas, MobIndex and ObjIndex. And the only reason they are still that way and not using MySQL is because I haven't taken the time to store them in the database.

In my experiences from the last few years of using MySQL, the worse experience I've ever had is recently when my player table started to become overwhelming. Began to have so many variables on players that needed saving that I began to feel like my save/load functions where becoming unmanageable. But after some input from others I steeled myself and saw some places to clean them up.

(Comment added by Jindrak on Sat Mar 3 13:43:44 2012)

EDIT: Should also mention that for me the C++ conversion was not an 'over night change'. It was something that happened over the course of a few codebase changes as I refined my ideas and figured out what I wanted to do and where I wanted to take my ideas.

If you're sticking with C, how are you handling persistence? Did you just
implement MySQL at the loading/saving points and keep everything else the same (i.e. structs for the data, etc.)?

Yes, I started out by designing a schema that maps to existing structs as they were, rewriting only the interface functions.

I think there's a lot to be said about db interface code that is not 'hidden away'. One of the main advantages is that it's pretty transparent, and even relatively novice coders can add to it. And by having designed the schema myself, I'm able to do a lot with direct queries. In fact, I'm using a number of tricks to make the db more human-readable, such as using SET data types for bitvectors, ENUM data types for numeric definitions, etc: http://www.mudbytes.net/topic-3729-60032

I'm also curious as to how you're handling building and OLC. My preference
would be to get rid of OLC and just switch to a browser-based interface, since that would make syncing the DB and the in-memory stuff far easier.

Web OLC was definitely one of the major highlights made easier by having all world data in the db: http://www.mudbytes.net/topic-3667-60097

It was a ton of work in and of itself, and then there was quite a lot of work to make it able to push changes in-memory in a clean way. We are now technically independent of text-based OLC, but we do use it for small tweaks. Also, some of our older builders are way too used to in-game OLC to switch.

To expand on an earlier point, if you design the schema yourself and try to make it human-readable, you can do a lot with direct data entry and queries even without having a Web OLC interface. Install something like phpmyadmin for use by others, and MySQL Workbench on your workstation and you're good to go. I do a lot of balancing and global changes via queries.

Yes, I started out by designing a schema that maps to existing structs as
they were, rewriting only the interface functions.

I think there's a lot to be said about db interface code that is not 'hidden away'.
One of the main advantages is that it's pretty transparent, and even relatively
novice coders can add to it. And by having designed the schema myself, I'm
able to do a lot with direct queries. In fact, I'm using a number of tricks to make
the db more human-readable, such as using SET data types for bitvectors,
ENUM data types for numeric definitions, etc:

I suppose it's just a difference in design philosophy. In any project I do, I
separate the database interaction and use an ORM as an interface. In addition to
making the code cleaner and less prone to error (I find writing raw queries risky
at times), it also makes migrating to a different database simpler, since the API
doesn't change. So, although I may be starting out with MySQL, I may decide
down the road that PostgreSQL suits my needs better. With an ORM layer, that
switch is easy to do.

It was a ton of work in and of itself, and then there was quite a lot of work to
make it able to push changes in-memory in a clean way.

Well, I think the key with that is not to load everything into memory when the
game starts. There's really no reason to load all of the information for EVERY
area. While I"m not going to touch this part of the system anytime soon, ideally
I'd like to move towards an on-demand loading system.

To expand on an earlier point, if you design the schema yourself and try to
make it human-readable, you can do a lot with direct data entry and queries
even without having a Web OLC interface. Install something like phpmyadmin
for use by others, and MySQL Workbench on your workstation and you're good
to go. I do a lot of balancing and global changes via queries.

You're a braver man than I! Giving phpmyadmin access would definitely scare
me, even though I know you can lock it down, restrict privileges, etc etc. I come
from a web development background so I'd rather whip up a web-based
building tool.