Table-top RPG (TTopRPG)

NOTE: If you're looking for a TTopRPG 2.0 download, go here instead! This page is a very old diary I typed up during my development of an older version!

This is a small developer diary describing my attempts at making a Visual Basic program designed to duplicate the activities of the tabletop for purposes of playing an authentic Dungeons and Dragons game online. This was sparked by playing World of Warcraft, when a guild member talked about missing playing the game. I've been playing lately myself, taking someone through Return to the Temple of Elemental Evil and him taking me through City of the Spider Queen.

I first wanted to see if there were any tools available that would allow me to play. So I downloaded klOoge. It had some interesting functions, but when I connected with my laptop, some of the functions didn't work, and when I moved some icons around in the primary list, they disappeared from the main screen, and I couldn't get them back. It wasn't very intuitive.

I also took a look at screenshots from OpenRPG, but didn't try to run it.

Both programs had a primary grid screen with the capacity to display a map underneath, and a primary chat area.

I figure if I develop my own, it will need the following things:

Other things to keep in mind:


What I've accomplished:

What I have yet to do, immediate plans:

Longterm plans:

I don't think the online program has to keep track of absolutely everything, just what it takes to get through a tabletop session. Much information only needs to be known at the player level. Sometimes the DM needs to look at player sheets to see if they have an ability, though.



Most of the items form 6/7 are done. Here's a new immediate changes list:

I just realized I could add something to the dice rolls to allow players to set up their own buttons with modifiers and send that across. For instance, Concentration checks, Attack 1, 2 and 3 for the primary attacks, Concealment roll, Reflex save, etc. So it would have a description blank, a modifier blank, and a button. Click it, and it rolls the dice, adds the modifer, and sends the result and the description. This would have to be set up on a per character basis, and sinze a single player could control multiple characters, they will need to be able to select which character they are rolling for (which will probably be enforced by whose turn it is in combat, but could easily need to support rolling out of turn, such as a Reflex save against a fireball).


I just added five description and modifier blanks to the dice screen to test out special rolls. They report the description and modifier to all the machines, now, too. But I forgot to show the actual dice rolls. That would be important for detecting possible crits. The program could probably be set up to automatically report a crit roll, too.

I've also started making a toolbar that will allow a user to place, remove or move icons (on a player's turn only, although the DM can do it anytime), do the same with markers (anyone, anytime), and hide/reveal the map (DM only). At first, icons can be dragged anywhere, but in times of combat, I want to enforce movement rate and let the program count down squares remaining based on movement rate (supporting single moves, double moves, and modifiers due to spells).


I took a break for a day because I was a bit burned out from programming, and I had a killer headache (not enough carrots in my diet).

Anyway, I got text working and can even calculate its size for centering. What I figure I'll do is detect the pointer moving over an icon, and if the icon it's on is different from the last one it was on, it will repaint the screen with the info of the icon (name, hp (DM) or status (player - they can see their own hp though)), or allow seeing all statuses and names for all icons always.


I wrote a little stub app to test placing icons, highlighting them and chaing their information. I'm realizing I may need a list of all icons to look up their information instead of highlighting each, much like I keep notes of creature's hit points on a scrap piece of paper while the fight is taking place.

It's important to make the program intuitive to how a game is conducted at the table.


The program now allows me to make markers, and drag both the markers and icons around.

I need to set it up for zooming and using map coordinates instead of PictureBox coordinates.

I also assume I'll need a Quick Marker function so when I ask where a fireball is getting cast, the player can just right click and select "Quick Marker" instead of having to type anything.

I'm also thinking about how the program will need to save these things, and send them across to people that are joining in the middle of a session.

I don't know yet what challenged there will be for people that get disconnected and have to rejoin. Perhaps they can just do a reload. If the master disconns, though, that pretty much messes everyone up, unless the master saves its information often. Perhaps it can save it in chunks (markers as they are placed or moved, icons as they are placed or moved, etc.)

Also, the master will be the one responsible for telling all machines what the id's are for created icons and markers. The client will tell the master it is placing the icon, then the master will choose an id for it and send it to all clients, including the one sending the request. That way, no id's will overlap.


I sent off the latest Alpha and am hoping to test it with two clients soon. I still haven't solved the problem of two machines on the same LAN communicating to a machine across the internet (the second machine on the LAN freezes and doesn't always receive system messages).

In order for the program to be usable next week, I need:

The final version should have:

Other things I've thought of:

6/15/2005 - #2

I just did an alpha test. The other user said he couldn't see the button used to resize the upper half of the form. I checked my code and found I that I was basing the new position of the button on the size of the map window, but I was repositioning the button before I resized the window. This caused the button to be a little off sometimes. So, I moved the button adjustment to occur after the map window adjustment, and it looks stable. Hopefully that bug won't happen again.

Also, the application errors out when you minimize the main form, becuase it attempts to perform a window adjustment.


Here's a link to the VB install package. Unzip this into its own folder and run setup. Choose an installation directory and click the computer icon. After it's installed, navigate to the installation directory and run Project1.exe. NOTE: This program will not work without the \map and \sounds directories.


I realized it might be nice in my box drag routines (which I have another app successfully implementing) to be able to set an enter group of visible squares to be visited, without replacing them. The only splitting would be where boxes are cut by the edge of the box. Perhaps it might be easier to flip a switch and just make all boxes visited, then the DM can set to visible whatever he likes.

I also have an icon displayer going, but the shrunk images don't come out very well. I'm sure if I upgraded to Direct3D, they would look much better. The way I have it will do for now, for testing.

Another nice function on the main map form would be to adjust the damage taken by an icon, instead of having to set its damage taken so far directly.

I would also like to display the app's version number on the main form, since it auto increments each time I build an exe from it.


I'm at the point where I'm ready to think about getting monster and character icons onto the map. It's presenting some challenges though, and I need to think about how I'm going tog et it to work. Displaying the icons and tracking their information is the easy part. The hard parts are:

Of course, it's probably just best if I work on one thing at a time:


I also realized that the best way to design the initiative screen is to allow the DM to auto-advance down the list with the click of a button (which then notifies everyone whose turn it is and activates/locks the appropriate icons), rearrange the order manually, and set it to be the turn of anyone the DM wishes. At first I was just going to allow auto-advancing the turns, but I realized that was too restrictive. This way, the design is a little more open.


Well, after a long break I decided to come back to it. Over the past couple weeks, I've added the following:

I did run into one problem, however: for some reason, sending the fog box data in a map down to a client across the internet occasionally causes a 80004005 error when the program attempted to do a Msg.Readstring on the packet. I haven't tested my attempted fix for it yet.

I decided not to lock and control things so much for simplicity, and the fact that if you're going to play a game like this with people, it should be with people you can trust and enjoy playing with, not just someone who sees your game and decides to hop into it.