In the first part of a brand new series, I’m going to document the entire process of getting a web-app working.

I’ve been promising a new version of PFd4 for a while now. I have also been meaning to learn Python properly, so I’ve decided to combine these two projects into one handy package.

PFd4 was originally concieved when 2d10 – which my girlfriend and a number of my other friends were playing an RPG on – went AWOL for two weeks. At the time I was staying with one of the players and her (now) husband, who hosts both this site and my main site Aquarionics. So, Girlfriend, Provider of Free Hosting (both real and virtual), and small number of other friends need a web site. At the time I was unemployed, homeless and about to slide into the dark pit of depression, so I took on the project.

I coded the original version of PFd4 in three days flat, including one day designing the data structures, and as such it isn’t the greatest piece of coding I’ve ever done. The interface for the messaging was messy, and it only barely did what they wanted it to do well. Nevertheless it existed until the game ended a couple of months later, and during that time I consistantly promised myself that I would rewrite it. Now I’m unemployed again, although not homeless this time, and I want to learn a new language and skillset, so I’m using this.

The original structure for v1 is here.

These are the design principles for PFd4-II:

Technical

A new name.

I’ve never really liked the name PFd4, partly because my brain wants to parse it as PDF4. It stands for “Point First d4” (A d4 being a four sided dice) which is a play on 2D10 – the system it replaced – and the fact that it’s quick, painful, and RPGish. (d4s are pyramid shaped, if you stand on them it hurts).

python/mod_python

It’ll be written in python, built on mod_python, backending onto a mysql database – as the last one did. This is the tricky bit. I am a PHP programmer by trade – though I did both C++ and Java at University – and am just getting into this python lark. Most of the reason I’m doing this now is to learn python.

XML/XSLT

The python will generate XML, which will be fed though an XSLT stylesheet and passed to the user (Actually, I may not even do this to start with and leave the XSLT client-side, it’s slightly quicker)

In fact, even quicker would be to generate XHTML by default – rather than an arbitary XML form – and transform from that.

XHTML/CSS3

The XSLT stylesheet will generate XHTML/CSS3 code that degrades gracefully to older browsers (If it isn’t already, see above). It may also produce PDF versions of logs etc.

External Access

Allow XML-RPC interface, NNTP, SMTP access etc. Possibly

Gameplay

Campaigns

Games will belong to campaigns. Any number of active games can be in a campaigns. This may involve subcampaigns, though that might be a little too far.

Characters will belong to Games too, rather than campaign, meaning a character can’t be in two games at once. I’m open to negotiation on this bit, because whilst I can see that having three characters for “Bob the Avenger” is duplication of effort, having Bob level up in one game and suddenly be levelled up in the other two is silly. This is also an interface problem, since I don’t want duplicate names, but if they’re in the same campaign – though different games – and they are the same person (Say, Bob The Avenger aged 16 and Bob the Avenger aged 25) that should be allowed (Yes, I do like the idea of Bob the Avenger, why do you ask?)

Voices

When a character makes a “play” they can do it as a ‘voice’. So a thief pretending to be the lady of the person whose house she’s robbing would be “Bobette the Thief as Lady Fitzdamnation”, with Fitzdamnation as the ‘voice’. This concept was popular with those who understood it, but complicated to explain. It remains (I like the idea, and it’s my system, damnit) but may end up being on some kind of “advanced” system. Plus, I want to be able to use it so that GMs can use it without the players being aware of it, so instead of “GM as Lord Fitzdamnation” you just see “Lord Fitzdamnation”. In fact, it’s possible that all GM plays would be made this way, and make the GM register a character for any persistant avatars same as anyone else.

Other Players

At an option for the GM, no player should be able to see what other PCs are playing, or even whether a given play is made by a PC, NPC or GM. NPC is the tricky one of those, because PCs and GM characters can – and will – have profiles, whereas small NPCs probably won’t.

Artifacts & Encyclopaedia

Every campaign will get an Enyclopaedia where they can put articles (Text (& Images?)) relating to the campaign. GMs will also be able to upload “Artifacts”, a file – any type – which groups can view. (Needs to be worked on to avoid becoming arbitary gallery space)

Groups

Characters can be lassoed into groups, which can then be given permissions. For example, if the GM wanted the group to find an article in Elvish, s/he’d upload the file as an Artifact with the group of “Characters who understand Elvish” being the only group allowed access. Inside this group s/he’d put all the characters who – duh – understood Elvish, and only they would be able to read it.

‘Play’s can also be restricted to a group, or some groups, or a list of people (For example, all those didn’t fail an observation roll might see that the carpet by the bookshelf is trapped, nobody else would see that message), though the list of people might be better off as a message. A message then just becomes a play that only the other person can see, which neatly stops me having to write another bloody e-mail replacement.

Tasks:

  • Implement the database
  • Login system
  • first-cut templating
  • User add/admin
  • Campaigns
  • Message Events
  • Games
  • Characters
  • Plays
  • [1]
  • Groups
  • Plays Mk2 (With groups)
  • Character Profiles
  • Encylopaedia
  • Artifacts
  • Design Cut 2
  • Bugfixen
  • Release.

[1] is the point where the system is usable for testing.