logo

products

about

roadmap

helping out

support

progress (feed)

contact

app.net apps facebook twitter

SweetRPG’s Niche

Posted: December 7th, 2016 | Author: | Filed under: Role-playing games, Software Development | Tags: | No Comments »

This project has been a long time coming, mostly because I’ve been trying to figure out what it should do, and, perhaps, more importantly, what it should not do.

There are a few products out there that offer a digital solution of some sort for playing RPGs: Roll20, D20Pro, and Fantasy Grounds, being the most notable. They let you setup a virtual table-top and play with people over the internet. Unfortunately–for me–those products don’t solve my problem.

You see, I have a gaming group that meets regularly at my house, so I don’t need to play over the internet. In fact, they don’t even want to play that way. And nobody wants to gather around a table with a bunch of laptops, or gather around a single laptop to look at a virtual table-top. We like to gather in the living room, where the seating is comfortable (especially when the session is 10-12 hours on a Saturday).

So, my problems are these:

  • I want to keep track of the initiative order, where necessary, and be able to show it to the group so they know when their respective turns are.
  • I want to show a picture or a map to the group, ideally without having to pass the book around to everyone, especially when it is sitting next to text that contains information they shouldn’t see.
  • I want to keep copies of everyone’s character sheets, so I have an easy reference, especially to background/backstory material, but also stats and other useful information, and I don’t want to make new photocopies every time the sheet changes.

I have an app called Initiative!, which is a stripped-down, system-agnostic initiative tracker. But it only (currently) works on the iPhone.

I own printed books of nearly everything for the game systems we play. Recently we went through Princes of the Apocalypse, a 5e D&D mega-adventure. The biggest problem I faced with it was the fact that there are maps scattered all over the book. It was very difficult trying to keep track of them, and I eventually printed out copies of each so I could find them more easily, but that was still chaotic.

Back to the living room, where there’s a big-screen TV.

It would be nice to display the encounter order from Initiative! on that screen, so everyone can see when their turn is.

It would be nice if I could import the data I need for each character (name and hit points) into Initiative! when I’m building the encounter. Or the same for monsters when I’m adding them.

It would be nice to slap a map on the screen when the players need to see it to figure out where they want to go next. And to be able to tag or group them so they’re easy to find.

It would be nice to display a monster image for the group to see without having to pass the Monster Manual around.

That’s where I see SweetRPG. It’s not a virtual table-top. It’s not playing over the internet. (Not that I don’t like those things. I just don’t need them.)

It’s a set of inter-related, inter-connected apps, each with a specific purpose that’s totally usable on its own, but where data can also be pushed up “to the cloud”, pulled into another app, and sent over to an AppleTV (or the Google/Android equivalent) to display on the screen for the group sitting comfortably in the living room to see.


Progress Report

Posted: November 15th, 2016 | Author: | Filed under: Role-playing games, Software Development, Technology | No Comments »

I’ve been working on a project called SweetRPG for a while now.

I have a love of table-top role-playing games, having played Dungeons and Dragons since I was 13, starting with the Red Box, and moving into 1st Edition throughout high school, playing with a group of friends nearly every weekend for 3 years.

I’ve been trying to find a marriage of RPGs and mobile technology, which has led me to where I am now. This project has gone through various transmutations, trying to find the right problems to tackle while not repeating or copying some of the products that currently exist.

I have a couple apps (Mac and iOS) currently on the store that were first attempts at addressing some of the issues I currently deal with.

The first is an encounter tracker called Proelia 2, a Mac app. It supports 3rd and 4th edition D&D, as well as Pathfinder, but it’s woefully out of date.

The second is a utility app for iOS called Counsellor; it’s something I wrote to help with trying to figure out which classes a player could choose given a set of ability scores. It’s a problem we experienced trying to play a 1st Edition D&D campaign recently with a bunch of players who had no familiarity with the system.

The most recent app is also for iOS, an stripped-down initiative tracker called Initiative!. It’s system-agnostic, with some built-in assumptions about how initiative tracking works on d20 games.

SweetRPG (it’s a word-play on a “suite of RPG apps”) came about as a way of bringing these apps (and some others that I’m thinking about or working on) together in a cohesive way, enabling sharing of data (game systems, characters, encounters, maps, etc.) between apps and with other users, mobility, and persistence so your data can go with you anywhere.

In the short term, there are two significant updates in the pipeline, one for Initiative! and the other for Counsellor. I don’t know when they’ll be done, but the hope is sometime within the next few months. There are a couple features to button up, artwork to finish, and, of course, testing.

In addition, my intention is to start posting weekly or monthly progress reports or thoughts on the projects, including some others in various stages of development.

For now, this is where we are.


A Bit of Kit

Posted: March 7th, 2015 | Author: | Filed under: Software Development | Comments Off on A Bit of Kit

One of the first things I’m trying to tackle with this update to Proelia is to make an official “SDK”.

It’s not obvious, but the game systems that Proelia supports are implemented as dynamically-loaded bundles, where some of the classes therein conform to some protocols that the main app defines. The point was to allow users to be able to make a “plugin” that supports their favorite game system, thereby allowing Proelia to understand some of the basic structure of the character data (namely hit points, or health tracks, or whatever the game system uses to determine whether the character is alive or dead) and how the encounter is run in terms of determining who goes first (initiative), what happens when a character’s turn begins and ends, how conditions are managed, etc.

There was never a publicly documented way to do this. At some point, I had attempted to demonstrate it by creating a GitHub project for a Dragon Age plugin (it’s here: https://github.com/pilgrimagesoftware/ProeliaPlugin-DragonAge). I don’t think it was ever completed. On top of that, there wasn’t a way to “install” the plugin without resorting to command line arcanery and knowledge of the directory layout of the app. Bad me.

There is now a GitHub repository for ProeliaKit, located at https://github.com/pilgrimagesoftware/ProeliaKit. This will be updated as development of the next release continues. Additionally, I’m planning to update the Dragon Age plugin to make use of ProeliaKit, and may even publish some of the other plugins on GitHub as well.


Dev Diary: New Project

Posted: March 2nd, 2015 | Author: | Filed under: Software Development, Technology, Writing | Comments Off on Dev Diary: New Project

Several months ago, I started on a new project. It’s not entirely new, because one part of it is an application that I released a few years ago. I’ve had an obsession with digital tools that support managing and running D&D game sessions, as well as things that help with character generation and tracking.

During the development of Vesper’s sync component, Brent Simmons presented his thoughts as a development diary. I’ve found in the past that trying to lay out ideas generally helps to crystalize them, so I thought I’d attempt to do the same thing with this new project.

 


 

The new project is a suite of apps, both desktop and mobile, that handle the various aspects of character creation and management, game session planning and running, and miscellaneous other tools. In addition, there will be a back-end service that each app ties into for storage and inter-app communication.

The apps that make up the suite have the following functions. Some have names, but I won’t include those here.

  • Name and biography generator
  • Character creation
  • Character sheet management
  • Character advisor
  • Role-play helper
  • Encounter tracker
  • Dungeon generator
  • Campaign manager

The plan is for each one of the apps to make use of the back-end service, mostly so that apps with the same role can share data easily across platforms (desktop and the predominant mobile platforms), and that the data has persistence outside of the originating device. This will also allow the various apps that contribute to a character to be able to share their data across roles; for example, the name generator can add that data to the character creator, which can then generate a character that can be managed by the sheet manager, and can be loaded into the encounter tracker during a game session.

Note that, while I mentioned D&D at the beginning of this post, none of these apps will be restricted to just that game system. I play a variety of editions of D&D, as well as Pathfinder and Numenera, and have dabbled in other systems. I also know players and GMs who like systems such as Shadowrun and Eclipse Phase, just to name a couple. These apps will either be system-agnostic or support a plugin-type system that allows rules of a particular system to be applied where appropriate.

Some of the work on the back-end has already started, a shared library is in the works, and a couple of the apps are in the early stages of design or development. In addition, I’ve just started work on updating Proelia (which will fulfill the encounter tracker role) to work with this system.

 


 

I hope that these diary posts will be enlightening to you and useful for me during this development process. It’s probably going to take a while, but the journey should be as fun as the destination.


A Ridiculous Proposal

Posted: October 26th, 2014 | Author: | Filed under: Technology | Tags: , , | Comments Off on A Ridiculous Proposal

Seventeen years ago, I wrote and released an email client, called Eucalyptus, for the Amiga. As part of the process of writing it, I had to become familiar with the RFCs pertaining to email formats and structure, sending and receiving protocols, security, etc. I also built into it support for PGP signing and encryption, because I believed that security, privacy, and authenticity were important with regard to email.

In my study of these RFCs, I became aware that the email system, while it has served us for quite a while, is fundamentally broken. How is it broken?

  • Email headers are forgeable. That means that we can’t really trust information in the message, such as the From header, or the series of Received headers, that those reliably represent the originator or path, respectively, of the message.
  • The SMTP protocol was not originally designed with authentication. It’s been subsequently bolted on, but the presence of credentials don’t ensure the identity of the sender.
  • The lack of inherent signatures and encryption have led to a system where privacy and security are an afterthought. The system was designed (one could argue, naïvely) where everything is transmitted in the clear. Hello, NSA.

Since writing Eucalyptus, I’ve often thought, mostly idly, about how I would fix the email system. It wasn’t until recently, when I was listening to the Core Intuition podcast (episode 158 or 159, I don’t remember which), that I started giving it some serious thought. 

A new system would have to address some important issues in order to be good and, hopefully, ubiquitous.

Accountability

A step toward addressing the spam problem would be to enforce identity and the ability to validate that identity. What this means is that, as part of the account setup process, a keypair is generated for the user, and every outgoing message is signed, and every incoming message is validated.

Some might argue that, by using keys and signing every message, the system is implicitly requiring the use of real identities. That is actually not the case. A keypair could be generated that represents a pseudonymous identity, and the purpose it would serve is validating that messages signed by that identity actually came from that identity.

Security

By building in, from the ground up, support for encryption, users are provided with the ability to transmit message content privately with little “barrier to entry”. The system, as it is, requires technical knowledge on the end-user’s part in order to setup keys for encryption and integrate encryption into their workflow. It also forces recipients to have a corresponding setup. By making it a foundational feature of the system, encryption of messages for the sake of privacy becomes a matter of flipping a switch (see also Usability below).

Usability

An essential component to a successful system is usability. Recently I tried to set up a local Tent node. I spent a couple hours struggling with obtuse errors from the “installer” (which turned out to be the cloning of a Git repository, a series of dependency installations, and then some terminal commands) before finally giving up, and I consider myself to be reasonably smart when it comes to that sort of thing.

In my opinion, the fundamental failure of Tent (as well as Diaspora and some others) is lack of usability. While their efforts are noble and laudable, the installation, configuration, and in some cases, simple use of those systems require far more technical knowledge of systems administration and software development than the average person should be required to have. Granted, the current email infrastructure requires as much knowledge (DNS records, configuration of the mail relay/host, account setup, spam filtering, etc.), but a lot of that is addressed by the presence of hosting services (Gmail, Fastmail, Outlook.com, ISPs, etc.) that take care of much of that. But the installation of a Diaspora pod, or a Tent node, or whatever, should be the matter of a single command execution, or copying an app into the Applications folder and then the entry of some basic information before the user is up and running.

Conclusion

The implementation of such a system is non-trivial, but is something that, in my opinion, is necessary if we are to move forward and achieve security and privacy, especially considering the current abuses demonstrated by our governments. The current system is insufficient for our needs. Other parts of the Internet infrastructure have been replaced with better things. The email system is long overdue for this change.


Education Assumptions

Posted: February 8th, 2014 | Author: | Filed under: Technology | Tags: | Comments Off on Education Assumptions

Originally posted: April 30, 2011

Anil Dash:

I didn’t go to college. It’s another facet of the flaw in drop-down identities that LinkedIn assumes someone in my social context had to have learned in a traditional way in order to participate in the career that I have.

I didn’t go to college either.  I like to think that I don’t need this kind of validation, but it’s nice to know that there are people out there whom I respect and consider infinitely smarter than me, that have made their way without a formal post-high school education.


Gambling

Posted: February 8th, 2014 | Author: | Filed under: Mac App Store | Tags: | Comments Off on Gambling

Originally posted: April 21, 2011

Proelia 1.0.1 was rejected from the Mac App Store.

(No, this isn’t that kind of post.)

This is my first completed application in recent history, and after going through all of the other distribution and exposure channels, I figured I would submit the application to the MAS.  In the back of my head, I thought that it would be cool if I made through on the first run.  You know, a little personal victory.  Silly, yeah.  I even thought it was taking all the necessary precautions.  I read Craig Hockenberry’s post on preparing apps for the MAS, I knew about the issues with BWToolkit using private APIs, and built a specific version so I wouldn’t get nailed on that, and I read over the rules multiple times to make sure I got everything right.

I guess I didn’t.

The app was rejected on two points.  First, it turns out that I linked against and bundled the private-API-using version of BWToolkit instead of my own clean version.  Gah!  Second, Proelia is “apparently” in violation of rule 2.30, the “keep your hands to yourself and off my stinkin’ filesystem” rule.  It’s this rule, or more specifically, my reviewer’s enforcement of this rule that this post is about.

After overcoming the twinge of sadness from being rejected (and not achieving my personal goal of making it through the process on the first try; oh well), I sat down in front of Xcode, set some breakpoints, and tried to find out where I was transgressing with regard to the filesystem rule.

Now, specifically, the reviewer pointed out that Proelia was writing to /Library/Proelia.  So I checked on my system, and that’s certainly not the case.  As far as I can tell, it’s not even possible without escalated privileges:

$ ls -ld /Library/

drwxrwxr-t+ 63 root  admin  2142 Feb 10 07:46 /Library/

Proelia does store encounter information in the user’s Library directory, i.e., /Users/awesomedungeonmasteruser/Library/Proelia.  In fact, I was pretty certain that I was determining the directory in the proper way:

NSArray *paths = NSSearchPathForDirectoriesInDomains(NSLibraryDirectory, NSUserDomainMask, YES);

NSString *basePath = ([paths count] > 0) ? [paths objectAtIndex:0] :NSTemporaryDirectory();

NSString* fullPath = [basePath stringByAppendingPathComponent:@”Proelia”];

I might be wrong; it happens more than I’d like to admit.  So unless this code does something other than what I expect (and it seems to work just fine here, because the files are ending up in the right place), I think my reviewer screwed up.

Now, I’ve read some blog posts about other apps that were rejected for a variety of what the posters considered unjustified reasons, and I’ve followed plenty of discussion on Twitter amongst Mac developers regarding the submission guidelines, and their experiences with rejection, and so on and so forth, so the pitfalls and gotchas aren’t foreign to me.  And I’m not declaring my rejection “unfair” or “unjustified” or whatever.  I also noticed a few developers today discussing rejections similar to this.

What occurred to me (and others before me, I’m sure) is that the process has an aura of whimsy and capriciousness about it, and isn’t entirely trustworthy.

Here are some of the things I’ve learned about reviewers and the review process:

  • Reviewers have a set of tools at their disposal that help them to determine things that would be otherwise difficult or impossible, such as private API usage.
  • Application aesthetics are judged subjectively, because a human standard is applied instead of a machine standard.
  • Reviewers don’t apply standards consistently; i.e., one reviewer might allow a violation of a particular rule while another doesn’t.

In a lot of ways, submitting an app to either one of the App Stores is a crap shoot.

In my particular case, I think I got hit by an automated tool that “raised a potential red flag,” but he or she didn’t take the requisite actions to validate whether my app had actually violated the rule.  Maybe he or she was having a bad day, or got distracted, or was just a little too eager to reject something.  When you factor human beings into a process, all kinds of crazy things can happen.

What also occurred to me about the process is how little it can be influenced or corrected from the outside.  Some behaviors change, and rules are modified, but it seems much more like it’s Apple having to discover their mistakes themselves rather than accepting input or feedback from the developer community.  As a parent, this strikes me as very similar to a 3-year-old’s “I can do it myself!” tantrum.  This is disturbing and discouraging, especially when I think I’m dealing with adults who are supposed to be professionals.

Alas, I’m going to fix my errors, and resubmit.  Roll the dice.


Work/life Balance

Posted: February 8th, 2014 | Author: | Filed under: Uncategorized | Comments Off on Work/life Balance

Originally posted: April 15, 2011

Brittany Tarvin:

A company at which employees must fit their sick days and personal time into a set number of days in a year does not have a work/life balance. A company at which employees must request time off and hope that they are permitted to go on vacation during the time they have selected, does not have a work/life balance.

This is some of the reasoning behind why I have decided to press forward as much as I can with my indie Mac software business.


Simple Things

Posted: February 8th, 2014 | Author: | Filed under: Uncategorized | Comments Off on Simple Things

Originally posted: April 15, 2011

Michael Tsai, on JetBrains’ new appCode IDE for the Mac:

It does clearly best Xcode 4 in one area, though: it can sort the file list alphabetically.

Why does it seems like improvements to some software result in simple (nearly essential) features getting cut?  I lost count of the number of times I’ve been frustrated because I can’t just sort the file list.


Who’s your blogger?

Posted: February 8th, 2014 | Author: | Filed under: Uncategorized | Tags: | Comments Off on Who’s your blogger?

Originally posted: April 14, 2011

As part of the exercise of setting up this website to support my fledgling-indie Mac software company, I followed the advice of several other indie developers I follow on Twitter: setup a blog.

So I did.

And then let is sit for a while, because I came up with a number of excuses not to write anything.  As a result of reading another blog (Justin Williams’ carpeaqua), I stumbled upon an article on the A Smart Bear blog that gave me the kick in the pants to write a second post:

But you still don’t blog, and for good reason, right? Blogging is work, and ten other things are more important. Writing is hard and takes longer than you think it ought.

And even if the blog works, the experts say you won’t be able to measure its effect, and it will probably take years to come to fruition. Years? Fooey. You need a sale today. You need a job by next Thursday. Who has time for “years?”

…but that’s like saying you’re not going learn to play an instrument because it takes practice.

…but that’s like saying you’re not going to start a company because at first it’s difficult and the payout — if there is one — is too far away to be tangible.

Not much in life that’s worthwhile is easy, especially at the beginning. That’s not an excuse to not do it.

So, I’m going to try again.  Wish me luck.