Steps to a Character Sheet

1. Find an image (PNG or JPG) that you want to use as a character sheet.  You can often get these from game PDFs.
2. Create a tabletop for each player.
3. Set the background to the image you selected.
4. Use text fields, image objects and drawings to fill in your sheet.

A Picture An Annotated Screenshot is Worth a Thousand Words

What’s Ahead

Character sheets will become fully supported.   That’ll mean…

• fields that you can lock in place or group with other objects
• the ability to clone a whole sheet so you can just have a template sheet that you clone for each player
• a gallery of Xs and check marks and similar things
• probably, more types of fields than just text and image—probably checkboxes and lists, even though you can get the same effect today with images and notes
• eventually, data-driven and calculated fields

		EpicTable Screenshots VIEW SLIDE SHOW DOWNLOAD ALL

These are also up on flickr and facebook.  One could reasonably ask “why here and facebook and flickr?”  Mostly, I just can’t decide how best to present them. I really like the way the Windows Live galleries integrate effortlessly into the site. EpicTable already had a facebook presence, but I like the way flickr presents them better, and I can’t leave well enough alone.  Count yourself lucky that I haven’t provided a link to these on my screencast.com site too.

It’s the same set of screenshots, so your choice:

• EpicTable screenshots on flickr
• EpicTable screenshots on facebook

Grid Improvements

There are a few bugs reported against grids–notably that changes to the grid don’t get broadcast and that grid visual settings, like color, aren’t saved.   Additionally, I have some support for hex grids that I’ll put in place while I’m tampering with grids.

Annoyances

I hate that the tab renames don’t get broadcast to the other participants.  I’m going to stop the hate.

Automated Reports

These are the result of the "Report this to EpicTable Support?" dialogs that come up when something bad happens.  These have been really helpful, and I’m glad people have been sending them.  Every release, I fix a couple of the things that have come in this way.  However, I’m getting to the point where the easy stuff has been addressed and the ones that come in now are more difficult for me to reproduce.  Tragically—necessary for your privacy, but tragically—there’s no email address or other identifying information sent.  That makes it impossible for me to hit you up for more info, even if you’d like me to do that.  I’m thinking about an “opt-in settings” page, where you can opt to share your email address with me, so I can contact you about your bug report.  Maybe I can contrive to ask during the report and let you choose to apply that response to future reports.  That way, you don’t have to go looking for the opt-in page.

What About The Sync’d View Feature Requests?!

This is the request to let the GM sync the players’ views to his.  There was a lot of conversation on the forum about how this might work and whether the GM could “force” players to his view.  I haven’t forgotten about this.  I’ve resolved to implement the feature. Plenty of people want it—including me.  It will probably be shortly after beta 13, just because I think it’s going to take a bit of work, and I don’t want to hold up this other bug work while I work on this new feature.  I think this one merits a short spec (maybe fodder for my first doc section!) and prototype, so I can get some feedback before it’s too far along.

Beta-12 isn’t a big feature release. It has some memory-related fixes that should help those on lower-end machines, some minor fixes to issues that were reported against earlier betas, and a set of fixes for the drawing tools–most notably issues with drawing when scrolled and/or zoomed. The memory fixes are what took all the time–well, that and taking my 3-year-old daughter to Disney World.

When Beta-12 goes up, I’ll write another post with links to the download and change notes.

The theme for beta 12 is “synchronization improvements”. A couple of the beta test groups have reported issues with objects disappearing mysteriously or object moves getting communicated to the players but not to the GM. The causes of these seem to fall into two categories:

1. Issues related to rejoins (deliberate or automatic)
2. Issues related to memory consumption

The first of these is somewhat random—except when it’s related to the second. Deliberate rejoins are when a participant restarts EpicTable and joins the same game. Automatic rejoins are when one participant’s EpicTable gets disconnected and rejoins automatically. You won’t necessarily even know about this unless you’re looking at the log or if the rejoiner is the host and thinks it has to rebroadcast the game state to everyone. This kind of rejoin can be caused by network errors. It can also be caused by high memory consumptions causing errors.

The high memory consumption is something I’ve observed on a few people’s machines. If you’re using a lot of maps and handouts, it’s not unusual to see EpicTable taking up 500-600MB or more. Clearly, this is undesirable, and it was surprising to me. Of course, I suspected very large maps were to blame, but by and large, I saw people using maps that were pretty reasonable in size.

Here’s what I was missing. I thought the maps were “small” because I was looking at the size of a JPG or PNG file. So, I thought I had a leak. When I got a memory profiler on it though, I found that I didn’t. I had a huge amount of “unmanaged memory”. It turns out, the images used to back maps have a large unmanaged memory component. This is because, unlike what you see on the file system, map images in memory are uncompressed. Save one of your maps as a .bmp instead of a .jpg and join me in recoiling in horror. Add three or four tabs with maps in them, and you can pretty quickly take up a lot of memory. That was why EpicTable took so much memory. What I’m doing now, and what I have proof- of-concept-quality code for right now, is releasing all the map images except the one in the current tab. When you change tabs, the map image for that tab is loaded and the last one is released. It had been the case that, once loaded, a map’s backing image stayed around. This change greatly reduces the incremental memory cost of adding a new map.

There are other, fairly minor, things in beta-12, like some bug fixes for automated error reports that have come in. I’m hoping to sneak in a surprise or two, but I really want to get beta-12 wrapped up this weekend, so we’ll see.

Thanks to all of those who have taken the time to report issues to me, open support tickets and gather diagnostics for me. It’s really helped.

– John

Brennen, Jeremy and I are back from Gen Con, and I’m hard at work on getting EpicTable beta 11 out the door. Beta 11 is what we demoed at Gen Con, and I’m pretty excited about a couple of the new features we were able to get in:

• ad-hoc drawing tools, allowing you to draw freehand on your map or tabletop
• lots of options for customizing your “plain” (until now) text objects on the tabletop

Look for details in the next couple days.

Here’s another exciting piece of news. We sold pre-orders at Gen Con! The beta has reached a point where it’s stable enough for our weekly game, so while it probably has about 3-6 months of beta left, I felt like EpicTable was finally ready for some limited, pre-release sales. So, we were offering special pre-release pricing on EpicTable demo at our booth. Don’t worry forum folks–I wouldn’t sell to convention goers without giving you guys a similar opportunity to pick up EpicTable before its official release. (Details on that later.)

Look for some new faces on the forums. I let loose the 3rd wave of beta participants, and of course, the pre-order folks have access to the beta.

Finally, if you couldn’t make it to Gen Con, you’re not out in the cold. I’m going to get a virtual demo booth going, and we’ll run a set of demos. Whether you’re in the beta currently, or just curious, you’re welcome to visit the booth. I just have too coordinate with my three year old boss, who was at home with her Mom while I was at Gen Con….

But then….

We found that it was possible to get into a cycle of infinite retrieval when multiple tokens on a map referred to the same character. To hit this issue, you had to drag a private character to the map and then do that again, or duplicate the token before everyone retrieved the image for it. The more players you have and the more times you duplicated or re-dragged the token, the easier it was to make this happen.

This never happened to anyone prior to beta-7 because you couldn’t drag private characters to a map back then. (Or rather, you could, but since they were private, no one would retrieve them and things got confusing but non-lethal.)

In our Friday night game, Brennen dragged a private zombie (a zombie for money…) to the map and started duplicating the token to throw a horde at us. (Okay, maybe not a horde, just a group, but it seemed like a horde to our characters.) At that point, everything slowed down. One or more of us had entered a cycle of endlessly updating the zombies. This hammered away at Brennen’s machine, making it lag relative to the other players’. Very nasty stuff, though a rather nice load test of the messaging layer, which it seems can run at a rate of at least 5 ZUPS (Zombie Updates Per Second) indefinitely…or until Brennen’s machine is brought to its knees.

After that session, I dropped what I was working on for beta 8 and turned my attention to these zombies. I’m happy to report that my group tested beta 8 last night, and its issue with zombie updates is fixed.

Beta testers: Look for a forum announcement for beta-8.
Others: Please stay tuned.