Previous post: Roguelike MUD progress #4
In order to add some life to my game, I chose a monster that I've always found intriguing, the gelatinous cube.
Now, the gelatinous cube is something from Dungeons and Dragons, and so it reminded me of the time that the people who made it released some open content. Cue confusion trying to understand their license. Still confused. Just as confused now as I was before. I am going to assume that it is workable.
Anyway, the content is provided in the form of RTF documents, so at first I thought I was going to have to rough it old school like they did in the '90s. However, other people provide versions in more approachable formats, like CHM and its inferior brother HTML. And better yet, various forms of SQL database. That was where it all started to go wrong, and this became a prolonged diversion from making real substantial progress on the project.
Rather than using piecemeal bits and pieces of the D&D content in the SRD, as it is available in database format, there should be no reason I can't procedurally generate game content from a database structured form of the SRD data. So, time to choose a database engine, and then to see what I can do with the data.
First up was SQLite. It is the obvious choice because it comes bundled with Python these days and therefore is not an extra dependency, given I am writing my game in.. Python. However, I am somewhat spoilt by the tools that come with SQL Server, so I looked around for some similar tools for SQLite. One promising tool just did not work. The next most promising tool was the Firefox add-on SQLite Manager.
It is a basic form of what it is intended to be, but unfortunately it is open source quality. Clunky. A garish gradient for background colours. As a piece of work, the programmer did well and probably put a lot of time into it, but the clunkiness gets in the way of usability. I found it hard to get a good view of what was actually in the columns. And found myself wanting to use SQL Server Management Studio.
So I took a look at the stripped down versions of SQL Server, and decided that SQL Server Express 2008 was the one for me. Where SQLite comes out of the box both Python and requires no installation, unfortunately the installation process of SQL Server takes ages and if you have a shoddy Acer laptop like myself, makes it overheat. Two days later it was installed and working, because the first time I installed it I chose the wrong option, and working out how to change it after the fact or why things didn't work.. was a nightmare.
That's much better. Now, it is time to look for a module that will allow me to use SQL Server from Python. pymssql looks like the best candidate for this.
The actual data in the SRD database is just pieces of information stored in text fields. Any use of it, will have to be interpreted at the Python level, or abstracted through database views.
Most of the work I have done on the game engine itself, since my last post, has been bug fixes.
- For some reason Putty stopped working as a game client. It would not switch to character mode and stayed in line mode when I connected to the game with it. This also meant that it didn't switch to the correct character set, because the server was reacting to incoming sets of characters, not incoming full lines. This was because I was not doing the negotiation right, sadly I needed to run Putty under the Visual Studio debugger to find out how. Unfortunately, dithering looks crap in Putty, as the colours are ambiguous.
The yellow tile here is the "gelatinous cube". However, it still looks like a dithered yellow and white tile despite actually being straight yellow.
- Code reloading fixes. These are mostly make-do fixes, my referrer searching skills are deteriorating.
- Cleaned up key press handling, in preparation for the input queueing. Unfortunately, the input queueing requires game design related choices. Like how long an action takes, is dependent on what the action is and what it means in-game.
- The unicode character set display was broken, fixed it up and tried to get it to display various interesting unicode characters. A wider variety of tiles through use of unicode looks like more trouble than it's worth unfortunately. The number of unicode characters that have the correct representation when displayed in Putty are unfortunately limited. There are however Roguelikes that use unicode, but that's another project for another day.
Next post: Roguelike MUD progress #6 - Chinese character sets