Cardscape

From Arcmage Wiki
Jump to: navigation, search
   Ambox content.png Under Construction

These pages are under heavy construction & only intended for the developers. Notice that most of the info will change.
Please contact us if you want to help us out or join the dev. team.

Intro.

This is document outlines ideas and thoughts on what features could be implemented in Cardscape - the online php CCG creation & collaboration tool that's in early development. The two primary goals with Cardscape are to assist card game developers when developing new cards or sets for their game and to also function as a card database for the players. On top of those two main functions additional ones that could be useful in a card game community could be built. There are currently no open source tools in existence today that covers these functions, which in return is making Cardscape a pioneer and of great importance in its genre.

WTactics is an open source customizable card game that is in heavy development. We are in a great need of a robust system such as Cardscape in order to ease the development of our game. While we have longed for such a solution we also envision that Cardscape in the long run becomes a self-contained project that is coded in such a way that it can be of use to virtually any card game developers, and not just WTactics.

Currently it is only developed by Ravenchild (aka foodo on irc) that can be contacted via ravenchild (at) wtactics (dot) org. It is hosted on Sourceforge using GIT and uses the open source AGPL3 license. Ravenchild is our lead developer and should preferably be consulted before you decide to help out by joining his team or submitting a patch. Developers and contributions are of course more than welcome - if you know your PHP we would love to have you aboard - contact us already!

This document is not a roadmap or a similar list of what a developer must implement. It is a place to gather and archive useful ideas. When it comes to implementation each individual developer is his/own master and free to work with whatever is seen as interesting within the scopes for the project.

Each feature an idea will get a priority rating from I to V, where I is top priority and V something that can be saved for whenever there is time and possibility for it. These priorities are from the perspective of the WTactics project and our specific wishes. Priorities are mere suggestions and not binding for the developers of CS: As a developer you may implement features in any order you see fit and as agreed on with the lead developer.

Features

Customization

Game Customization (I)

While most card games are mainly composed of cards with rules and variables on them these variables have different names and exist in different amounts and types depending on the game in question. While most games have some sort of attack and defense value on their creatures, not all games have creatures and not all games that do have creatures have those two variables - they could have totally others, or have them but have additional sets of variables on each card (e.g. Dexterity, Life, Mana, Cooking). Furthermore, a game might have different amount of factions (if any at all), card types, identity numbers and so on.

Cardscape needs to be able to handle any game that it could be expected to be used for. By looking at a couple of already existing collectible card games like Magic: The Gathering, Yu Gi Oh, World of Warcraft, living card games like A Game of Thrones and much less complex card games like Munchkin and Chez Geek you can get a good idea of how customizable the database structure and fields should be.

Operational Customization (II)

Different developer communities will have different needs. An admin of CS should be able to turn on/off features that particular community want or won't ever use.

Examples:

  • If they are not interested in getting feedback on cards, the card commenting could be turned off and that feature would then be made "invisible" on their CS powered site.
  • Shut on/off the function that offers the public to suggest new cards.
  • Shut on/off some kind of captcha when unregistered users comment.

Themable Customization (II)

CS should be easy to theme so each games community can get it to look like they want. Use of standard and for the purpose invented methods as Smarty & CSS should be prioritised.

Text customization (IV)

No text messages should be hard coded in the CS interface. There should be an easy way for the admin to customize them so that the language suits the games overall theme. This also opens up the door for internationalization of CS and the translation of it into languages other than English.

Card Database (I)

Except for being a game developers tool CS should also offer a quite different face to the general public, where it doubles as a card database. Card databases are of great use and very common in different card game communities. A rule of thumb is that the larger and older the game, the bigger the need is for a decent card database. An example of one that has been around for long and shows of such databases primary functions is The Gatherer. Luckily giving CS the ability to double as a powerful yet user friendly public card database shouldn't be advanced since the developers already input and make use of the card data.

Search (I)

A database usefulness is determined by the data in it and the ability to locate that data. A good search that allows complex "custom" operations is of huge importance both for the players of the game as well as the developers of it. Example: Find all creatures of faction x or y that cost betwen 3 and 5 gold, and that are not of the Goblin subtype, and that have an attack value of 2 or greater.


Import & Export (V)

  • It should be possible to, with the push of a button for the admin, export all or selected parts (e.g. via doing a search) of the card texts in the database to standard and widely supported open formats like for example CSV. (II)
  • The same for import: Import should also allow admin to tell CS what is used as a seperator in the text file that is going to be imported. (I)
  • A user should have the option to export all comments he/she has written on all cards into a nicely formatted HTML file and/or a CSV. (III)
  • User should also be able to get an export of all the cards he/she has created.

Viewing cards

  • It should be possible to view a given subset of cards, by selecting single criteria and filtering the data. For example: Browse Gaian cards only, browse only cards modified since a given date.
  • It should be possible to change displayed order of cards - sorting it with time of last modification, card type or cost

Messages and event notifiers

I think we will need a simple message system - fully internal (without e-mail notification or rss channel) - just reminder and text-only message queue reaching year backwards or 200 messages, with trash reaching last 10 messages or emptied every Sunday.

  • There should be a notifying system that will make user be aware of events that will meet criteria he will choose. Examples: new card proposed for red banner, user's card (one he created himself) commented/changed, new gaian card moved to playtesting.
  • There should be limited ability to send messages to other people, like the reason for banning, or if you want someone else be aware of something. Example: This card needs your urgent attention, please playtest it ASAP, as it fixes some major leakage.

Registration (I)

  • Users should have the ability to register an account (unless it has beeen deactivated by admins). (I)
  • CAPTCHA: All new users must answer a simple question (Example: What is the name of this game?) that is asked to them to tell bot registrations apart from human registrations. In the config file the admin can define a list of questions that CS will randomly choose from and also define their answer. The CAPTCHA should be non-case sensitive. It can be turned on/off by the admins. (II)
  • Nickname, country, year of birth, e-mail, IM, super short presenation and huge avatar are fields that can be required (or not) or optional to be filled in.
  • E-mail verification is sent and should be clicked for account activation. (Again, can be turned off by admin).
  • Newly registered users get user role x automatically as defined in config.
    • Default: Normal role, able to post comments and use site normally, but never edit others stuff.
  • No IP tracking should ever be done by CS. (I)
  • Nick similarity check: A users desired nick is compared with already existing nicks. There has to be a difference between it and already existing nicks that is at least x characters. Example: If x is set to 2 by admin and the nickname "snowdrop" already exists, a user can't register the nick "SnowDropz2".
  • Nickname ban-list: Users are not able to register with nicknames that are defined in a list by admin. Example: Admin, Administrator, Webmaster, HugeDick, etc. (IV)
  • Minimum and maximum nickname length. (II)

Profile (IV)

  • Privacy: A user can define what portions of his/her profile that are visible or not. (III)
  • Show special titles granted by admins or by the system, for example when a user gets the translator role it should say in that users profile he/she is an x translator. Special titles can have spcific avatars associated with them such as "medals" etc. (II)
  • Shows the top 5 highest rated decks built by user, user favourite cards, user favourite decks, country flag and nation name.
  • Linkage to social networks like Diaspora, Facebook and/or Twitter API:s, announcing a players card creation on his favourite standard community. (V)
  • Buddylist: Ability to add/del people as buddies. This can enable stuff like notifications when buddies have created new decks or when you have something matching on have/want lists.(IV)
  • Wants & Have lists showing what cards a player has and which one he/she wants. (III)
  • Admins have the ability to see the date for a users most recent login.


Subprojects (II)

Subprojects are a nice way for developers to organize the creation of x cards. Example: Creating an expansion with only 15 creatures for faction y and 15 spells for faction z.

  • Admins can create subprojects and define what type of cards and how many of each type will be accepted.
  • Meters show how many cards have been suggested / accepted / are left into the project.
  • Several subprojects can exist simultaneousley.
  • Upon creation of subproject the creator can specify it's goal and other infotext.
  • "Project keepers" can be assigned by the creator: They have admin like capabilities but only for their subproject and the cards within. Normal admins always have their rights, even over the subprojects.
  • Once a goal is met within a subprojects no new cards can be suggested to that particular end in the subproject. Example: If the project only needs 15 creatures and it already has 15 approved creatures, users can't submit more creatures.
  • Possibility to set a project associated requirement so that for instance only users that already have at least 5 accepted cards can post a suggestion to the project, or users that hav been registered for at least a certain amount of time etc.
  • Subprojects have a configurable expiration date set by their creator.
  • Subprojects are listed in a special subrojects section on CS where ongoing ones will be highlighted. There are also archived subprojects somewhere half-hidden.
  • Each subproject can be discussed using commentary function, as if it was a card.

Misc.

Commentaries (II)

  • People should be able to comment and discuss a card.
  • Ability to (un)subscribe/(un)follow the comments and get notified when somebody comments.
  • Show posters avatar next to comment, along with timestamp for when post was made and when the last edit was done.
  • Only allow edits to be done for comments with x minutes after they have been posted, where x is configurable by admin.
  • Visually connect comments that are replies to other comments, for example by adjusting them x pixels to their right.
  • Censorship: Words that are defined in a censor list will show up as character x instead, if enabled in a users setting.
  • Visually mark out comments made by buddies with bg colour x as defined in CSS and also mark out comments made by an official developer of the game with background colour z.
  • Ability for the editor of a cad to leave a custom message in commentaries etc when the card has been revised somehow. If no custom message is left then the default one is written in the comments (Example: John Revised "Glorious Sword" to version 1.33)
  • Show version specific commentaries only: Each cards commentaries should be associated with a that cards specific version. If its a new modified version of the card, then the commentaries should be blank, unless of course, they are made on that version of the card. There is no need to see old commentaries that are un-understandable since card has changes so much, and that also clutter the screen and makes the discussion harder. Each card versions commments are of course also archived, nothing is erased. Readers of comments should however be able to fetch and see comments of previous versions of the card if they choose to by pressing a link, making AJAX being the stuff to them. Rinse and repeat to see them for yet another version backwards. Also, in the subject title line of each historical comment display, it should, before the subject, display what version that comment was written for. E.g. "0.5 The overpowered attack"
  • bb markup should be allowed, i, b, u, quote can be (de)activated from config file.
  • custom CS markup: Specifying x y z could for instance display a direct link to the card in the database if writing [cardsname] in a comment. [cardsname|i] would display the card in a textual form with all info such as name, cost, cardtext etc. [cardname|c] would display the cards name followd by its cost, linked back to the card in db... etc etc


Order card list

  • All lists/displays of cards in CS should be easy to order in relevant and various alpha or numerical orders, ascending or descending.



Favourites (V)

  • Ability to add a card to ones favourites list with the press of a button.
  • When viewing the players favourites they can be presented in various different view styles, like grouped by card type or faction or alphabetically. Maybe the search can be used on the players favourites list to generate these views?

Deck Creation (II)

A section of CS should evolve around letting the community users create and discuss decks, in a similar manner which they can create cards. The creation of decks is usually an important part of most advanced card games and is deeply connected with the meta-game. Deck creation is arguably one of the finer aspects of playing customizable card games and is of social importance for the community building within, but even more so for players with competitive ambitions.

  • Enable users to create own decks by empowring the database with easy to use tools/icons that allow a user to add a card either to an existing or a new deck in his/her collection.
  • Users can rate decks 1 to 5 with stars or whatever.
  • They can discuss each deck.
  • Deck revisions are saved.
  • Mark a deck you created as private or public.
  • Name of decks creator and creation date + brief intro of the deck + lenghty explanation of it is seen.
  • Have a section/page in CS that is dedicated to:
    • Searching for certain kinds of decks, decks with high ratihng or by certain authors, made between certain dates, containing x copies of card y in it but zero amount of card z etc
    • Showing latest decks created
    • Showing top x rated decks.
    • Displaying statistics of how many decks there are in the database.
  • To avoid a huge amount of shit decks to be created cap the amount of private and public decks a player can create to x and y. Settable in config file.
  • If a deck was built using a card that has been revised since the time the deck was built the creator of the deck is notified about it. The deck is flagged as "revision proofing". Only the creator and mods etc can take away that proofing status the deck is in. Idea is that people will check it and see if the changed card poses any problems for the deck.
  • Export deck to a format that can be loaded in popular clients like OTCGN2 / LackeyCCG. Usually these are pure text files.
  • Export deck to print ready PDF and/or HTML with card images or just a series of PNG:s etc so people can easily get hold of the cards for offline play.


Admin Tools (I)

Admins of the CS site must be empowered to do virtually anything: Modifying or deleting info with ease, no matter what the info is. The only exception to this should be the password handling, which should never involved another human.

  • Edit user profiles & delete users. (III)
  • Edit, add or delete cards etc. (I)
  • Assign & change user roles. (II)
  • Block users: Ability to block a user from logging in and to leave him/her a custom message that they see when trying.
  • Push-of-a-button backup and download of the db.

Automation

Following should be done using fake crons or other means of automation every now and then. Time intervalls and/or triggers would be different for each individual task:

  • Compressed db backups.
  • Auto-purge of user accounts that have never been used and have been around x amount of days.
  • Auto-set a users profile to "currently inactive" if he/she hasn't logged in for x amount of days. Set it to active once he/she loggs in.
  • Password recovery: When user loses the password it should be easy to recover it and the process shouldn't involve any human-admin interaction.


Card creation

  • Spam/thought filter:
    • Possibility to set that a user may only suggest x cards per day.
    • Ability to block users that get x amount of card suggestion marked as "spam/not serious" by an admin/mod from posting new suggestions.
    • Ability to enable CAPTCHA even registered users upon card creation.
Adding image of card

Adding art when creating a card is the same as adding the image of the finished card. This should not be mistaken for card art, that is just the art piece that is later placed on the card along with the text and all.

  • To avoid legal problems admins must be able to shut on/off art upload altogether, only allow certain users like game developers etc to upload art, or allow any registered user to do so (unwise, but hey, could be good for some projects). Following will tale for granted that art upload is activated:
  • File extension check: Only allow uploads of filetypes x y z as defined by admins.
  • File size check: -- .. ---
  • Dimensions check in pixels.
  • Copy the file and let imagemagick resize it to generate the image displayed on the site when looking at the card in the database and various lists throughout CS. Pressing the image should however take the user to it's original uploaded and preserved hi-res size.
  • Each card image is associated only to the card version it was uploaded to and also to that specific language.


Translation

By adding a way of not only creating cards but also keep track and aid their translation CS makes it possible to port a game into any language(s), allowing the developers to reach a truly global audience with their creation, turning projects into truly cross-border collaborations and also making it possible to reach new groups of people.

  • Person that has translator role is associated with one or more languages.
  • Translator can see a list of contemporary untranslated cards that needs to be translated into that language. If card x exists in English version 1.0 and English version 1.2 and both those are untranslated the French translator will only see that English Version 1.2 needs translation into French.
  • Proofreader can see a list of unproofed cards that needs to be proofed into that language.
  • Translation is done from language x (games central/primary/official language, whatever it is) to y
  • Support for several languages
  • Translation rollback.
  • All info tracked & displayed in various places: Who and when rolled back, who translated, who proofread etc.
  • A user could, if the devs wanted to grant him those roles, be both translator and proofreader.
  • Admins can disable the the need for proofreading and make it so that once something is translated it is auto-accepted/considered to have been proofread.


  • Factoids & stats
    • Number of current version cards translated in total
    • Number of current version cards translated into language x
    • Number of begun but not proofread translations in language x, also displayed in % of total
    • Top 10 translators in every language
    • Top 10 proofreaders in every language
    • Names of all members in each translation team/language

Setup possible in config.php

This is an incomplete list that can be built upon. It's main purpose is to give an idea about the level of customization we want to offer in CS.

  • List of languages we support translation to.
  • If translation of cards is enabled or disabled all together at the site: Games that aim to only exist in one language have no need of these great features.
  • If any user can translate a card or if it is users with the role "translator" or higher that can do it.
  • If proofreading is required or not.
  • If a card in any status can be translated (e.g. can concept cards be translated) or if only certain mature enough statuses can be translated. This defines which statuses can be translated or not.
    • Default setting: Only accepted AND official cards can be translated.
  • New registrations I/O
  • Min max nickname length


Message/notification system (V)

Notifications are internal and per default kept within Cardscape. They're indicated upon login. All notifications / messages are date and timestamped, and also hava a sender name and read-status associated with them.

  • Ability for CS to notify the user of different events, for example when somebody has commented a deck or card that the user has created.
  • Should the user want to certain types of notifications will be sent out to the player via mail as well or instead.
  • User can delete a message that has been sent if the sender has still not read it.

Patch creations

Cardscape should have the ability to easily generate patches so the cards and database created with Cardscape will result in a playable game using various software like OCTGN2 & LackeyCCG. Conventionally creating a patch/module that enables you to play virtually any card game using such software is a simple matter of manual editing of text files and supplying card images. The process can easily be fully automated so that a game developing team that uses CS to create their game can, with the push of a button, release a new or revised patch for their game.


Lackey patch creation (V)

What & why

LackeyCGG is a local card game engine client that allows players to connect to each other and play a CCG for free and p2p on a virtual table, with no rules or AI implementation. Lackey will let you play any card game as long as you tell it some basic stuff, settings and give it the card pictures. Thus, each CCG is considered to be a stand alone plugin that is loaded into LackeyCCG. The plugin is just made up of a handful of text files and card images.

Sadly the software is not open source and has a clunky old school GUI. It is however in a full featured state that goes beyond our own needs. Due to it's somewhat multi platform support (Win, OSX and Linux using WINE) and the ease of handling & learning LackeyCCG compared to e.g. gCCG it will be heavily used for online playtesting of the game, both between the WT devs but also in the public playtesting later on.

One of Lackeys better features is that it's very easy to get a game (plugin) installed. All that is managed by giving Lackey a URL from where it will get and install the plugin. From that point onward the plugin will use another file called the updatelist.txt. Every such list contains all the information LackeyCCG needs to decide which files has changed since the last update of the game. Whatever is on the list will be downloaded by lackey, and the plugin will become automatically updated accordingly.

Since cards will be updated frequently while we playtest, and also later on when releasing expansions etc, these centralized update features where Lackey gets and installs the latest stuff for the player with the push of a button is a terrific feature.

Creating the plugin

Creating the WTactics plugin for LackeyCCG is not a hard task. The process is explained in depth at the LackeyCCG site and is straight forward. The problem arises when we have a game in flux where many, or even a handful, of individual cards keep getting revised all the time, and/or new cards are added. This means that the plugin has to be partially revised or recreated every time there is a revision done to the game. In addition to that, the task of maintaining the WTactics Lqackey plugin becomes even harder if we're to allow the community to


Checksum code

LackeyCCG uses checksums to determine which files/cards has changed. We got in touch with Trevor, the developer of LackeyCCG got the code he uses to generate the file checksums. Trevor adds that he would have done it differently if he would be up for the task today, but that he has kept it the same because of backwards compatibility. The code literaly uses the sum of the data as the checksum:

int GetCheckSumFromFile(char PathNamePart[])
{
  FILE* fp = FOpen(PathNamePart,"rb");
  if(fp==NULL)
     return 0; // If there is no file, return with a sum of 0.
  long f1,f2=0;
  char TempChar=0;
  int Sum=0;
  do
     {
     f1 = f2;
     TempChar = fgetc(fp);
     f2 = ftell(fp);
     if(TempChar!=10 && TempChar!=13)
        Sum+=(unsigned int)TempChar;
     Sum=Sum%100000000; //modulo to prevent memory type overflow               
     } while(f1 != f2);
  fclose(fp);
  return Sum;
}
// Copyright notice: This particular piece of code was written by the developer of LackeyCCG and is copyrighted by the same project. It is not open source or copyleft, and is used here at the courtesy of LackeyCCG.

See Also