Keeping the Lights On
over 8 years ago – Sun, Apr 17, 2016 at 05:45:25 PM

Shadow casting part II

Hello All!

We're well under way with our work on Shadow casting. The first round of beta testing went pretty well. A few bugs were found and subsequently squashed. We've also expanded the functionality significantly.

In addition to the work on shadow casting, version 3.6 will also include some usability updates as detailed below.

The main topics of focus were as follows:

• Performance optimization
• Shadow casting tools and toggles
• [Judge] Creature context menu for rapid light creation
• Ownership/Tethering of lights
• Features (Rules API)
• Global font selection with UTF8 support
• Independent chat font select with UTF8 support
• Mini-view visual improvements
• Mini-view based chat interface
• Bug fixes (snap to knot in edit mode and few others)

The current, soon to be released to testers, build of 3.6.x represents a major push toward a feature complete Shadow casting system. There is certainly still room to improve and some features folks have asked for are simply not going to make it into this iteration of development. These feature requests are noted, however, and are prioritized against the other tasks to be completed for the Kickstarter fulfillment.

Shameless plug time - we're looking for some extra hands for content conversions and QA. Check out the last two sections of this update for details.

A light in the darkness

One of the major usability changes we made to the shadow casting system is the ability to quickly create and manage lights from a context menu. This allows for the Judge to create and attach lights to any creature in play without having to access the Game Tools panel.

The basic functions of this menu are Manage Owned Lights, Create New Lights, or Remove/Clear All Owned Lights.

The top section, Manage Owned Lights, shows a list of named light sources the creature owns. Each light carries a sub-menu which allows you to toggle Visibility and Public flags.

• Visibility is a global toggle to enable or disable the given light.
• Public is a toggle which enables or disables the light source for creatures you do not own. Toggling Public to off for a light is a great way to model vision.

The Create button allows you to generate and attach lights to a creature from a common list of presets. The values of these radii are pulled from Pathfinder and Dungeons & Dragons alike. They are also fairly common for other game systems like Fate or Savage Worlds.

The notation for created lights is presented in Grid Units. In the above case 1GU = 5 Feet. The first number represents the Inner radius while the second, when present, represents the Outer radius. The intent is to model the visual effect of bright and shadowy illumination.

Currently the list is static, but as we progress with the Plug-in architecture you'll be able to edit this list and create new light combinations.

The result of a context menu generated light looks like the following. The creature has a 10'/20' lights source.

In addition to the context menu, we've vastly improved the ways you can attach lights to creatures or items in your games. Lights carry to properties, Ownership and Tether.

Ownership is pretty straight forward. It denotes which creature or item owns the light. However, it has the added effect that you can toggle the Public flag to prevent non-owners from seeing the light source. This can be used to model Blindsight, Darkvision, Low-light vision more.

The Tether property allows you to attach a light to a token. Doing so allows for lighting effects to be managed by one creature even when movement needs to track another. Some of the use cases for this include Scrying, Dancing lights, Flaming Sphere, or even Wizard Eye. Scrying or Wizard Eye are great examples as you can attach a light to a temporary token but maintain ownership of the light by a given player.

Forms of engagement

The REST API development is moving right along as well. Over the past couple of weeks, we worked to complete the creature template connectors allowing for token images, custom fields and more to exist in a web view template accessible from the Creature mini-view, a web browser or attached app.

In addition to accessing and managing creature/character data, the REST API now supports pushing to the Game Log in the various chat modes as well as requesting die rolls. These are creature context driven so actions occur as an individual creature or player/judge.

The UI for this is all still very crude so I'm going to refrain from screenshots.

Features

As the REST team finishes up, we have been moving our attention to the Rules API. The first tier of the Rules API is being implemented using a Features system. Features extends the Library to include a loadable list of feats, skills, abilities, and special effects. Using this system it is possible to distribute rules for a game as well as craft house rules and overrides.

One of the core aspects of this work is a major overhaul of the Special Effect/Ability system to include a more user friendly creation tool and the ability to share effects between Judge and Players.

A quick preview of the roughed in UI is shown below.

By mixing and matching Features it is possible to create a blend of systems and abilities. While this is a cool by-product of the system, the core reason for moving these definitions into the Library UI is to allow us to push content between Judge and Player while maintaining authority and ownership of the assets.

We should have more to report on this aspect of development later this month.

The [font] is mightier than the [main gauche]

For some time now, we have heard the rumblings from the community that, to quote the Lego Movie, our font "is the worst". While I don't think it's *that* bad, it is a bit dated -- like original Solaris UI dated.

So, without further adieu! I present to you the ability to Change the Font!

You'll be able to jump under your options->general panel and change the global font for D20PRO. Do not be mistaken. This is not localization. If you change the font to a foreign language font, it may simply not render some of the text such as menus, stats, and other minor aspects of game play <wink>.

In all seriousness, this change allows you to use any UTF8 font you can get your hands on, but, until we have time to work on a localization pass, you'll need to ensure that your font has latin characters in addition to whatever other elements you're looking to add.

To account of non-english native speaker/typers, we've also added a separate Font entry for the Game Log. If you do not set a separate font for the Game Log, the global font will be used. However, this is where you can change fonts as is appropriate to your language preference.

If you get into trouble, we've included a handle "Delete [Chat|User] Font" button for each category.

All the things

Finally, we get to the Mini view changes. We've added a couple of new features to this panel to make it easier to be a go-to for character data during play as well as for using the in-game chat functions without having to shift away from your character.

The updated Mini View gives you the ability to minimize or completely hide the large creature portrait at the top. This is to save space when using the Mini View as a main character/creature interface or an in-character chat interface. Keep in mind the Mini View is a tabbed space, so you can have more than one character or creature active at a time and switch between them very quickly.

As you can see from the screenshot, it is possible to chat using any of the standard methods -- Say, Do, *Emote*, whisper, YELL -- just like from the Game Log or from the Context Menu Talk option.

Pretty handy!

Wrapping up and PAX East (2016)

We've been super busy and will continue to be super busy as we move toward completion and bug fixes for features for 3.6.x.  We're heading to PAX East this week in Boston and will be showing the current build as well as some other software work from one of our other teams. If you're at the show, feel free to stop by and say "Hi".

Beta Testing coming soon!

We're attempting to debug a JavaFX bug on Mac OSX which is preventing us from releasing the above build to testing. Soon as we crush that, we'll be sending out an announcement with new download instructions for the most recent beta build. Early Access will be first round, followed by community if there are no glaring issues.

Looking for work or have some spare time to donate?

As our development speed and feature sets increase we're finding the QA tasks to be larger than we can handle with our current team. We are actively looking to expand our QA partnerships so as to get a larger group of first pass testing and acceptance moving forward. We're very committed to shipping a stable product which arrives bug free rather than with a known issues list.

Marketplace and Content Creation

Similarly, we're looking for folks interested in collaborating and/or contracting to build D20PRO conversions of 3rd party content. We're also very interested in adding your original content, maps, creatures, etc. to the Marketplace.

Keep in mind that a system like D20PRO works best when a large amount of content is quickly accessible to the community. If you're a content creator or interested in help us convert existing content to D20PRO formats -- thing Adventure League modules, Kobold Press, or even Legendary Games -- then please reach out and let us know what you're interested in doing.

If either of these sound like something you'd like to take part in please feel free to reach out to us at d20pro_support (at) d20pro (dot) com. 

- Owlbear and the D20PRO Team

The Luminous Truth
over 8 years ago – Sun, Mar 20, 2016 at 09:30:31 PM

D20PRO 

For the last few weeks we've been working in tandem across two teams. Team one has been working diligently on extending D20PRO to support an extendable creature model (characters, monsters and NPCs) as well as implementing a shiny RESTful API to access the creature model and more. Team two has burning the midnight oil working on shadowcasting and a handful of existing D20PRO bug fixes.

Shedding Light on Shadowcasting

I made a video for you which gives a brief overview of the system and some samples of usage on a few different maps. 

The nuts and bolts of the Shadowcasting system are the new Fog of War Regions and the introduction of Light geometry. 

Current StatusThe team is working on some fixes for known issues with the current implementation as well as adding in a last few details/features to Shadowcasting before we ship a second beta to Early Access users. I expect that we'll have a feature complete beta for Early Access by beginning of next week (March 28th - 30th).

How does this thing work?
Shadowcasting is, at it's core, a collection of updates to the Fog of War Region system. This means that there is some added complexity to the Fog of War set up.

To facilitate Shadowcasting, we've added the following Region types

• Walls (Orange Border)
  Walls are the framework FoW objects and act as fill for places you don't want light sources to go. They can be flattened out or made wide to cover spaces between rooms or swaths of untravelable map. Lights which travel into Walls do not shine (in or out), and Walls never prompt to be revealed or auto-reveal. Generally, walls should be "enabled" (green eye icon) at all times.  
• Masks (Blue Border)
  Masks are your workhorse FoW objects. These fill all of the traversable spaces your players and creatures might travel through and you would like lights to be shown in. Masks have two modes, enabled (green eye icon) and disabled (red eye icon). When enabled, Masks prevent light from entering their space. They are nearly identical to Walls in their Enabled state. When toggled, Masks are consumable by light sources. In this state, adjacent disabled Masks will cover the negative of any light sources in play.
• Edges (Green Border)
  Edges are empty, non-filled objects which can have normals pointing inward or outward. An Edge with inward facing normals allows light to enter its space but prevents light from leaving the other side (mostly). This allows for placement over columns or statues or similar objects on a map where you may want a shadow but not want to occlude the art below. With their normals facing outward, an Edge is similar to a Wall except that light inside of an Edge will shine outward. When the normals face inward, light inside an Edge is trapped inside of the polygon.

We've also added a new Light tab to the Fog of War panel. This uses a new UI style we're working on which we plan to slowly implement as a replacement for other panels -- low priority vs. the feature advances however.

The final UI update includes a change to the Manipulate panel to rename it Mold and extend the functionality to allow for managing multiple Region types.

Okay, so what does this all do and what does it mean to your game? Let's start with lights and expand from there. A light source is currently defined as a radius from a point of origin on a map. The light radius is defined in Grid Units so a radius of 1 is 1 grid unit from the center of the light, or 2 grid units wide. The center of a light is a point with no width. This means that a light of radius 1, centered in a grid unit would cast light halfway into the next grid unit all around the unit it's in. This math jives with the shape system most D20 games use but has the added advantage that you can adjust the radius by decimal values -- i.e. 1.2, 6.5, 12.7 are all valid radius values.

Lights also have a set of properties such as Color and Ring Color. You can set the color of a light and it's ring color (outer edge color) independently. This allows for creating lights which have no fill color but outline their shape or have a fill and no outline or... you get the picture.

The example above shows a creature whose vision is outlined in yellow. The creature above and to the right is carrying a compound light source -- not that the image shows this well ;)

Currently the implementation doesn't differentiate between vision or light when attaching a view radius. We have plans to include properties which will allow you to configure vision vs light source and have game mechanics taken into account. 

An important item of note when using lights. Lights can only reveal Mask Region types. This is important to keep in mind when designing a Shadowcast map layout. I'm going to refrain from falling into the Update-turns-tutorial trap (made my reflex save), and stick to the overview.

Fog of War Regions primarily perform the same function they have in the past -- grant a GM the ability to pace their game by controlling what a player sees and does not see at any given time.

What the new regions provide is a clean way to put down shadowed areas which are static and cannot be revealed by a player (Walls); special spaces which prevent vision without occluding art (Edges); and interactive areas which hide and reveal map and monsters through play (Masks).

To answer the key question of "When do I get it!?" Shadowcasting is slated to be part of D20PRO 3.6. We are working on a new build to go out to Early Access and our internal QA/Beta testers. As soon as we've received approval from these groups then we'll push to public beta release. The majority of you will have access at the point we push to public beta. If all goes as plan, and you know how that can go, we should have a public beta release early to mid April.

Plugins and You

As we progress on our work with our RESTful API and Webview character sheets, the bones of Unlimited Creatures and Unlimited Rules are growing. The RESTful API team is making great progress toward a full featured system for pushing and pulling character data between external sources and D20PRO's core. I've already talked about what we're doing with the Webview so I won't spend a lot of time here today. Suffice it to say, we are going to be working with a web page author from Digital Agility to build out the shippable default character template.

On a technical side, the transport language for the data is JSON and the calls are managed by hosting a configurable Jetty server along side D20PRO. Doing so enables a Judge or Player client to allow connections to creature data through a web server (Jetty). 

Some of the items still on the plate for the creature/character side of REST are authentication of ownership, die roll triggers, chat log post/pull, and initiative data sharing.

This past week we started in on updating the Effects (Abilities) system to enable save and load between campaigns and clients. We're also working on introducing an event (trigger) system which will allow Effects to be attached to actions a creature can make such as Cast a spell, or use a Feat. These triggers will carry with them hooks to call effects if they are present. Doing so allows for both commercial and homebrew effect bundles. An example of a commercial bundle would be 5E spell compendium which adds non-OGL and OGL spell effects to all named spells.

What is particularly cool about this trigger system is the ability to arbitrarily assign effects to other elements. Want to create a custom staff which 8 spells in it? Or does your flametongue need to shoot a gout of flame?

After Effects are updated, we'll be diving into the full plugin architecture moving many of the core game mechanics out of D20PRO's core and into the plugin structure. This will be the point where we introduce our plugin API and additional systems.

Next Steps

So our next steps are pretty clear. Team one will continue working on REST and Triggers for Effects while Team two works on completing Shadowcasting and updating our Herolab importer and some other bug fixes.

I'm anticipating that the next major release will be 3.6 with the following features

• Shadowcasting
• Herolab Importer via standard XML
• RESTful Webview support
• User fonts selection for Chat and UI

Mage Hand

In light of the above work, Mage Hand doesn't have a lot to report right now. Definitely still in the works, but on hold during the Shadowcasting work.

- Owlbear and Thraxxis

Post Holiday Dev Log (psuedo update)
over 8 years ago – Fri, Jan 22, 2016 at 10:09:04 PM

Hi All, Owlbear here.  Publication is off on holiday, much deserved I might add, so I'm going to abuse the update channel!

I've got news to share and updates to give. Let's start with News!

I've touched on this in the comments section of the kickstarter, however this is 100% worthy of a true call out. We have a team whom we've engaged to add 5e support to D20PRO Classic. The project is underway in tandem with our Mage Hand development. This work is targeted at enabling both 5e OGL and full 5e support for the current available version of D20PRO. In addition, we're pushing some additional changes into the next major build of D20PRO. 

Alright, now for some dev updates -- first Classic:

Thraxxis has recently added 2Byte language support to the Chat interface allowing for additional character sets to be used within D20PRO's chat interface. This feature will be available Classic users with the 3.5.9 release.  The feature also allows any true type font to be used in the chat interface, not just international characters!

Additionally, we've had a community add to fix some sounds which were "missing" from the interface.  This includes several missed attack sounds to flush out the audio offering.

In addition to these changes, there are several minor bug fixes and alterations being implemented which will allow for the 5e ruleset expansion.  I'll try to keep you all posted on these updates as they are reported to me!

... And now some Mage Hand dev notes.

On the Mage Hand front, we've been busy working on our map editing/creation module. This is a key part of any VTT and something that we want to put a decent amount of energy and time into doing right. 

For the most part, we're trying to maintain the same style of workflow which we introduced in D20PRO. However, with Mage Hand's map making we've had to take a slight departure as we are now able to work with both 2D and 3D objects now. 

Currently we have several test libraries of objects which can be used to build out levels of varying complexity. Let me state clearly that there is no requirement to ever use 3D objects for map making.

As you can see from the image below, this is still a work in progress.

So before diving into what still clearly wrong with this image, I'd like to talk a little about what's right!

Here we have our blend of 3D and 2D characters with their fog of war area exposed. We also have green movement range indicators show where the currently selected character can go. On top of the ground plan, we have a tree, a cube, a run down hovel, a fence segment, a blue light source and a wooden cart. These objects are full 3D models with textures and can block light, cast shadows, be set on fire (or worse) and the like. The light source can be adjusted for brightness, intensity, enable shadows or disable shadows, even the color can be set. All of this is functional now.

What is still in progress is the weird double grid you're seeing. The black grid is an alignment tool which doesn't want to go away. This allows for the editor mode to "snap" objects as tiles onto an arbitrary grid -- that part works by the way! The fun bug is that the snapping grid doesn't want to go away when we exit edit mode -- sigh.

Some of the other features we're still working are: group object painting, object scaling, snap/unsnap a placed object (to grid), and attach to object (grouping). 

To quickly go over these, group object painting is a process where you can paint more than one object at a time -- i.e. a group of objects. This is helpful for filling in rocky areas, or adding elements on both sides of a path, etc.

Object scaling is pretty self explanatory.  This one is low hanging fruit and simply lacks a tool to make it accessible at runtime.  Most of the dev time on this one will be in managing the visual tool associated with the scale mode.

Snapping and Unsnapping of placed objects is effectively a toggle to allow an object previously snapped to a placement grid to be positioned without snapping.  Currently we have snapping enabled for translation (movement) and rotation. You can set arbitrary values for degrees of rotation to snap to as well as grid units to snap to.

Finally, we are still working on the final mechanic for attaching an object, such as a torch, to another object. The idea is to allow for a creature to pick up an object and have it move along with them.

I'll record a video as soon as we're a bit further along on the editor section showing how all this works!

For now, signing off.

(sorry for the brevity -- working hard, but not a lot to "show" for the work yet. We'll keep at it!)

- Owlbear.

PS. map loading and saving is working too -- forgot to mention that :P

Mage Hand -- End of Year Progress Report
over 8 years ago – Mon, Dec 28, 2015 at 04:46:10 PM

Happy Holidays Backers!

For those of you who are currently using D20PRO with your group but have a few hold outs who need to get a license, we're running a Holiday/New Year special until the end of January.  

You can find details on our soon-to-go-live D20PRO web site, currently living here:

http://d20pro.magehand.com/redeem/

Please feel free to share the joy, as well as poke around the new site. We're planning to take this live in the next week and having a few extra eyes on it would be most welcome.

Mage Hand Status Update

As the year comes to a close we're making great headway on bringing Mage Hand in Unity to the community.

In order to accurately assess the project's timeline, the team and I put a few significant feature milestones on the table as requirements. These are as follows:

• Networking
  - Token location and tile location sharing
  - Asset sharing
  - Stateful data model synchronization
• Table/Grid
  - Hex
  - Square
  - Free
  - Multiple highlight methods for movement, vision, targeting, etc
  - Grid attached UI for on-grid notifications
  - Grid based event handlers
  - Zone definitions
• Lighting (Shadowcasting and Fog of War)
  - 2D/2.5D volumetric lighting (Shadowcasting)
  - History based Fog of War (reveal Map where travel has already occurred)
  - Multiple lightsource blending
  - Special lights which ignore blending (Darkvision, True Sight, etc.)
  - Token attached "light" event triggers
• Core Rules Engine (not WotC Core Rules...)
  - Trait based Rules Engine
  - Configurable world rules (Action Points vs Movement vs Inches...)
  - Data Model backed Trait Nodes
• Dice/Resolution
  - Core Dice (d#, d2, d4, d6, d8, d10, d12, d20, ad#/dd#, fd#, hmd#) Logic
     ad = advantage dice, dd = disadvantage dice,
     fd = fudge dice, hmd = hackmaster dice
  - Core dice calculator
• User Interface Basics
  - Simultaneous Touch and Mouse/Keyboard world interactions
  - D20PRO Classic medallion interface
  - Token context menus (attached)
  - Token context menus (detached)
• Runtime Map Editor
  - 2D/3D runtime map editing tools
  - Object control tools - scale, rotate, translate
  - Asset library browser
  - Asset importer

Bold entries are properly proofed and evaluated, standard entries need a bit more work before we're properly mapped out.

As you can see, we've already knocked out a large number of the core features from an assessment/roughing out stand point. Once the whole list is black, we'll push toward refinement. For those devs/non-devs out there, a list like this grows and shrinks as necessary along with the scope of the associated project.

Show and Tell Time

As some of you may have seen, Owlbear posted a quick grid based movement demo video to the comments before x-mas. Our internal AV smith has added some nice post-production to the video and reposted it for your viewing pleasure here:

In this video we show some of the 2d/2.5d shadow casting features and light based triggers which our new engine make possible. 

This is preliminary work proofing movement and a crude AI for random creature population based on map based zones. Additionally, the map uses the vector based light blocking method which will be available at runtime. All of the assets for this video were generated in Unity however. The runtime tools are not quite ready for the primetime show-n-tell yet -- soon!

I'll let the video do most of the talking for this one, but the key features which the video shows are:

• per character movement restrictions
• per character lighting events (range & color)
• map visibility and grid based history (just not historical visibility)
• per character range/targeting (red squares under enemy tokens)
• scriptable units to with map navigation capabilities
• scriptable random encounter and creature placement
• paper cut-out tokens in a 3d space.
• per token character sheets, stats, status and abilities

There are several other cool things going on in the demo which are non-obvious -- primarily because they're turned off and still buggy :).  The first is the ability to assign attacks and attack types to tokens; the ability to create hybrid creatures by assigning traits from one creature to another allowing for customization of abilities and properties.

For the purposes of the demo, owlbear removed the ability to attack from the player and creature tokens. When enabled, there is an option to animate the attacks using particle effects and/or sound effects. We should be able to show some of these elements in the next demo video.

Question and Answer

Going forward, we're going to try to field some of the more complex questions directly in the updates. Basically, if your question would be best answered with a video or a photo, then the Update will likely have the details you're looking for!

Q: [Jim Todd] Nice...do the minis have to be tokens? Can I sell 3d sculpts I create digitally in the marketplace?

A: [Owlbear] 3D and 2D tokens are interchangeable in the new engine. For 2D there are the full body type of images which ArcKnight does as well as the top-down images from Devin Night's works. For the demo, I was using the paper doll versions because they work well to prototype. However, in practice you'll have the ability to have a paper-doll or 3D miniature coincide with a top-down "sprite" token.

As to the the specific question of 3D, I have a handful of screen grabs from the most recent build.

 Above the skeletons are 3d models, while the orcs and samurai are paper doll. Additionally, you can see the circle cursor in the corner showing that if the samurai moves into the corner, he will have full cover from those two directions (the shield icons). The red squares indicate targets within range of an attack from the selected square. the highlighted green squares are his available moves. The door is currently blocked by an orc and the samurai cannot use tumble because it hasn't been implemented yet!  OhNoes!

 In this screen grab we have a female character in the foreground facing off with an orc and a skeleton sorcerer. She is a full 3d model with an idle animation -- she breaths and looks around while standing on her token base. The Skeletons are also slightly animated. When attacks are enabled they point their staves at their targets and fire a beam of energy. Then the system hangs while it tries to figure out how to do damage to the player characters who do not yet have their full data model attached.

Finally, both the Paper doll and the 3D models introduce a very clear way to identify token facing. At the moment, we haven't add an option to ignore facing, so attacks from behind are considered potentially advantageous attacks while being attacked from more than one side introduces a flanking state. These are not quite tuned to 3.5 or 5e rules yet, but they are certainly steps in the right direction!

<note: the question mark in a couple of the screenshots is a debug icon which I use to see what's going on in the active characters state. It is not something which will exist when we release>

So, in summary, yes! we support both 3D and 2D characters plus animation for said characters. All of that being said, we have not build the importer for 3D objects yet. An FBX/DAE importer is on the short list for pulling in 2D and 3D assets.

One of the UI elements we have planned is a Token Builder which will let you build paper doll and 3D tokens as well as assign animations, special effects and the like.

As to selling your 3D models on the Marketplace -- absolutely. We'll be able to support the original 2D assets which the marketplace currently has in addition to 3D assets. Additionally,you'll be able to offer particle effect packs through our Marketplace as well. Understanding that particle effects are for everyone, we're including a big shiny effect-free toggle in the core settings.

Q: [Nathan James Cassella] Now, the question...your are changing the platform which I am 100% behind...but what happens to all my legacy campaign data that exists in java?

A: [Owlbear] This one has been asked a few times and feel it's important to answer it every time it comes up -- to the absolute best of our ability, we are going to be building import tools to bring D20PRO Classic campaigns into Mage Hand with the D20PRO add-on. 

The questions is slightly more complex than it seems at first however, the current plan is to build Mage Hand as a platform first. We'll be building the D20PRO add-on in tandem as much as possible as the core principle is to bring what we have up to speed with what we need.  This means that while we're building Mage Hand to be system agnostic, we will be working on the current development path with 3.5, Pathfinder and 5e as our core litmus test. If we cannot support these games out of the gate, then we've done something terribly wrong.

The word of caution I want to put out there is simply this -- as we move forward, we may be ready to launch Mage Hand prior to the completion of the full rules engine for Dungeons and Dragons 3.5/4.0/5e and Pathfinder. This would mean that conversion of your existing, in-play game may have to wait until after the full rules conversion is ready to launch too.

Now the empathetic appeal -- we're in the same boat, both from a fellow GM standpoint, as well as a business operator standpoint. We have a volume of content in our marketplace which will also need to be converted to the new engine. In addition we're still adding more content every month! We have new vendors signing on at an increasing rate. We will want/need to make the move forward as clean and seamless for these vendors as we can. The advantage is that we already have this goal set for you and your fellow GM's. The vendors and GM's will both benefit from the business need to make conversion as painless as possible.

Short version? Yup. we'll be supporting conversion of your existing content.

Happy New Year

With 2016 around the corner, I expect we'll be showing you a lot of interesting developments in the upcoming months. We're all very excited about the progress we've made since the decision to switch over to Unity. Hopefully you're also seeing the potential this cut over brings to the project.

While this may not count as a new year's resolution, we will continue to be as open and transparent in our process as we can without giving away too much of the farm. One of the common reasons for an ambitious kickstarter to fail is revealing too much and having the project built by a bigger team.

I promise we'll get there from here!  Thank you all for your continued support. May 2016 be filled with excellent games!

- Owlbear and the Mesa Mundi family.

Networking
almost 9 years ago – Fri, Dec 11, 2015 at 08:07:19 PM