Back! Long period of inactivity, indeed. This short update is meant to be followed by serious updates as the project is now back in development.

I have converted the project to .NET 2.0 Final, and Visual C# Express 2005 as an IDE (it's free). We might have a new coder soon, but more details on that later.  ¶ 11:57 PM 0 comments

  Reunion Just because I don't post anything here doesn't mean OpenTCG isn't being developped, right? ... Actually, it does. Unfortunately I haven't written a single line of code lately, because of accute lack of time (between work, d&d, magic, etc.).

But, there is a new and interesting development. Reunion.

Reunion

Reunion will be the most important Game System in OpenTCG, a completely original, highly-developped, trading card game that aims to offer as much entertainment value as MTG and other popular TCG. Actually, more entertainment value, because, as you will see, while we aim to mimic real physical TCGs in many behaviours, the computer medium, allows us to do stuff traditional Game Designers wouldn't even begin to consider. Ah, but I'm not going to reveal anything about that, because it's no longer my job.

Introducing Ahriman. The brand new Lead Game Designer for OpenTCG, and the man in charge with Reunion. As soon as we get a moderately stable core system (moderately stable = doesn't change in the next 2 hours of game design) I'll make him blog about it and developments about it. >:)

Anyway, all I'm going to say is that, already, it is a very different system compared to Magic (and the other 20 systems we've analyzed) and sounds exciting.  ¶ 12:29 AM 0 comments

  CardContainer This class represents a group of related cards that can be sent/processed as one piece of well-formated XML. It's purpose is to mimic the physical concepts of booster, card pack, and so on, and allow for an easy way to send a whole such pack to a client.

CardContainer creation is in no way restricted - while the cards themselves need to be validly signed, the container does not have a signature or any other authentication.

Besides the cards themselves, enumerated in the card container, it has the following properties:

Name - should be a word or two describing the type of container: "Booster" "Card Pack" are valid suggestions.

Description: may contain further details such as Expansion names or maybe, for fun, some flavor text :P.


Implementation status of feature:
* AuthClient can generate CardContainers for AuthPublished cards (via the new button Add to Card Container and the tool window "CardContainer"). Properties such as Name and Description are not configurable and container management is limited.
* Client can now add a whole container of cards at once (via the same dialog/menu option that is used for single cards).
* The CardContainer class is implemented in OpenTCG.Core assembly as OpenTCG.Core.CardContainer.  ¶ 9:58 PM 0 comments

  CardContentSelector The Authority Client now has a reusable window that can be used to select a card content from a local database. This is, of course, highly preferable to manually copy-pasting a card content id :P.

Other improvements include:
* AuthPublish requests fully working from the Authority Client
* AuthClient "Response" window for showing XML responses
* All untested features of yesterday were tested. Well, most of them.

I know slow day - exam tommorow. Oh and a first screenshot... I'll start posting more of these.

Screenshot of the new selector in AuthClient

P.S. : The AuthClient doesn't correctly set any Image Folder for CardView so the cards appear using no images (only backup elements). Because a lot of programs seem to need a dynamic Image cache for cardview I am considering starting a specialized project (The Global Image Cache or something :P) that will handle storing, finding, downloading, caching etc. images. Well, maybe.  ¶ 10:29 PM 0 comments

  Note: Authority and authority The game right now is obviously not very well thought of if the Authority of the game is actually formed of many people, which might happen eventually. Obviously it is a bad idea to have each one of them have the authority private key file - that file should be a very well kept secret - if one of them "leaks" it then it can/will RUIN everything. If someone can just pretend to be the Authority then OpenTCG must be, well, restarted with new keys - and if the game is developped that will be bad.

This is even more a problem for the Designer Key. Surely there will be more than one designer, but can we give them each the designer key? No!

Yet, having a dynamic set of keys be accepted as, say, authority, is not a solution - the game becomes more tied to a server that must now be checked for keys too. Therefore, the solution will be proxies.

Take, for instance, Authority key authentication. The key will ONLY be stored on ONE computer (well, excluding mine :P), a server. That server will emit all authority requests - those automated by OpenTCG Software (yes, a lot of the projects will make Authority Requests to other projects) and the manual ones sent by people who have the rights. For the manual requests, the server will have a separate mechanism for authenticating the ones he's proxying for.

This allows for security and flexibility while keeping things very simple where in matters most - in the main servers and clients: for those Authority is Authority.

In conclusion the idea is that none of the keys (authority, publisher, designer, server) will leave the opentcg servers at any time.  ¶ 12:00 AM 0 comments

  Authority begins... New Developments:

There is now a new subcategory of requests - the Authority requests (they contain an

<Authority>

token, have

<PlayerId>Authority</PlayerId>

and must be digitally signed by the Authority key which is embedded into the executable. Currently there is only one Authority request:
AuthPublish - authority request for a new card to be published. The publisher will, if possible honor this request and return the new card, as requested.

Also, there's a new project in OpenTCG (there's now 12 projects), the AuthorityClient. The AuthorityClient allows someone possesing the Authority Private Key (therefore me :P) to send authority commands to the services.

Implemented Today:
* Additional check in TradeRequests - check if cards are expired. [Untested]
* PublisherDB - Maintains an in-memory database of all known card-contents. They are loaded on startup by searching a given folder for xml files.
* Publisher support for AuthPublish requests. [Untested as there is yet no functional AuthorityClient]
* AuthorityClient - Startup, basic UI and Authority Key Loading (does not yet test if the key is actually an Authority key, but hey.).
* New Important Key generated and stored - the Authority Key. Can be accessed (the public one of course) as OpenTCG.Security.CommSecurity.AuthorityKey  ¶ 11:50 PM 0 comments

  Where the project is The project has evolved a lot since when I started it. I haven't put anything new on CVS for some time because I'm very lazy and practically no one is interested in this besides me so what's the point? I hate CVS (love svn :)) and won't commit to it until I get really far or people will start wanting to see the code/project.

Anyway, here is the current status on main components:

• I. Server Side
  
  
  • I.a. OpenTCG Service
  
  Windows Service that handles complex, but less often used operations that cannot be handled by scripting languages like PHP.
  

  Current Features

  
  
  • Windows Service startup/shutdown/threading
  
  
  • TCP/IP serving, accepts connections on different threads
  
  
  • Parses XML client requests and responds in valid signed XML
  
  
  • Checks client signatures on request
  
  
  • Processes TRADE REQUESTS completely: security checks, card republishing, card registration, everything functional
  
  
  • Elegantly handles bad requests (partially) providing (for now simple) information to clients
  
  
  
  
  • I.b. OpenTCG PHP Scripts
  
  Handles simple server operations that are accessed often and are more essential to the game. They are all accessed via simple http requests, use little cpu and bandwith and depend on a MySQL db.
  

  Current features

  
  
  • Card Service - fully functional. Allows clients (and anyone in fact) to check if a given CardId is valid online - that is if the card hasn't been traded.
  
  
  • Player Service - fully functional. Allows clients to obtain any player's public key if they know their player ID. Essential for security.
  
  
  • New Player Service - fully functional. Allows clients to register a new player and be assigned a new player id. They must send their public key to be stored on the server
  
  
  • Player Name Service - fully functional. Allows clients to receive a player's name if they know his ID. Needed in some circumstances.
  
  
  • Private Scripts - fully functional, to a point. Allows authority clients to request some modifications of the database. Note: Not enough security yet: simple http authentication for now.
  
  Notes: Fully functional means it does what it's supposed to do. They aren't really secure/optimized enough. Also above here "clients" also includes the OpenTCG Service :).
  
  
  • II. Client Side
  
  
  • Official Client
  
  This will be the official client that players will use to play the game, trade cards, manage their card collections and so on.
  

  Current Features

  
  
  • Player Creation - functional: player key is generated, players are registered with the NPS.
  
  
  • Player Management - functional: player information (including the all-important private key that identifies him on the network) is stored in XML files (unencrypted for now). These files can be saved, opened and created.
  
  
  • Offline/Online Mode - functional: if the client is in offline mode no communication is made (or attempted).
  
  
  • Card Inventory System - functional: The client is capable of managing a player's card collection and present cards owned for each Game System.
  
  
  • Card View - functional: A tool window displays the currently selected card, using the full power of the OpenTCG CardView control. Card image download is not implemented yet.
  
  
  • Card Properties - functional: All card properties are available via a standard Property Grid.
  
  
  • Direct Card Adding - functional: Cards can be added by copy-pasting them in a dialog. If in online mode, all security checks are made. If offline, all-1 security checks are made
  
  
  • On-demand on-line check - players can request that a card in their inventory is checked with the CS and see the result.
  
  
  • Card deletion
  
  
  • Manual transfers - one or more cards can be transfered to another player. The XML is shown in a window and should be sent to the other player via e-mail, IM, etc.
  
  
  • III. Authority Tools
  
  
  • III.a. Designer - functional but limited. CardPrint design is especially unfriendly as it requires manual XML editing.
  
  
  • III.b. Publisher - functional but limited. Will be replaced by the OpenTCGService completely.
  
  
  • III.c. RSAKeyGenerator - functional, limited and won't probably get any better.
  
  
  • III.d. OpenTCGServiceTester - functional, dumb, and not needed any more. For now.
  
  

Important known issues:

• If a connection to CS fails during a Check on-line request, an user-friendly message is shown, but all subsequent connections will fail, even if the network becomes available, until program restart (Client). Reason unknown.

  ¶ 8:24 PM 0 comments

  Why it started OpenTCG has started about a month ago, from the wish that there was some real _free_ system for playing Trading Card Games on-line. Yes, I know there's Magic WS that you can use too play on-line but frankly it's way to primitive for me. First of all, there's no automatic judging at all - you have to do everything, and I mean EVERYTHING manually. Also, the game really lacks much of the Magic feeling. I realized that when I first started it and it displayed a big list of 11000 cards. A TCG/CCG is fun BECAUSE it's collectible, because you DON'T have all the cards.

Ah, there's a lot of reasons why I wanted to make this - a nice concept of it all can be found here.  ¶ 8:17 PM 0 comments