Idle Hands Do The Devil's Work

I've garnered a wealth of free time.  So the development of RPChess has been revived, better than ever.  I'm still a lone coder, but I have a better understanding of C# and ChessWar.   I need to write out all of the things needed to bring the code to a playable level--I've already made the first step and there's a basic game menu and the begings of a 2d graphical UI.

Major changes to note:

• Model.cs is getting split up into separate source code files for easier management and readability.
  
• The Piece class now conforms completely to the ChessWar specification.
• Updated all arrays or lists to most effictive (that I have been able to discern) use of C# arrays and Collections.Generic's specifically the ReadOnlyCollection.
• Added more aggressive Interface use and still more to go, I'm going to be a standardization tyrant.
• Updated references to newest versions: Xna 3.0   .Net 3.5   and   NUnit 2.4.8

In other news, I am now on the GalaxyMage Redux developer team.  I will not let it die.  GalaxyMage will be finished before 2010.  And once it is and RPChess 1.0 is done watch for my GMR Python to Boo.Xna port.

I'll blog later about my Generics research.

Again Learning Modern Programming Techniques I Should Already Know

The majority of code already committed to the RPChess repository is data model classes and the code to turn them into or create from XML objects.  Today, I realized I was reinventing the-XML-serialization-wheel, which is a native part of the .Net framework in the XmlSerializer Class and can be seamlessly added to the code.  I first thought to myself, "Hot Damn!" then came a compuslory "Doh!"  Once I remove my custom XML serializtion code and tests, I should be back up and running.

In other news, I am now apart of the Galaxy Mage Redux team.  I am also helping out with Pyggel, a new 3d game library for python that combines pyopengl with pygame to create a 2d and 3d graphics system for Python in one includable library with a simplified API.

I'm on Ohloh so now you can easily track all of my open source programming activities in one centralized location.  I really like Ohloh; they provide a really cool social networking application for open source programmers.  They also aggressively added all projects from sourceforge.net and googlecode.com, which I just find funny.

DreamBuildPlay

I forgot about Microsoft's DreamBuildPlay Challenge 2008.  I registered last night.  The craziest thing is that they are giving away Creator's Club Premium memberships for free.  So I started tinkering around with running code on my Xbox360.  And while XNA may be somewhat crippling in certain areas, it is the greatest thing to have ever happened to a Game Console.  While Nintendo and Sony combat hackers in a silly war over running code on their machines.  Microsoft has created a way for them to manage indie/hobbyist code on their platform and soon make money for it. 
The submission deadline is September 23.  If only I had known earlier.  I'll be working on this crazy the next month. Wish me luck!

Thinking About Goals

I'm beginning to see lack a reason for the textual interface.  There seams to be too much work to get a functional "TUI" for the RPChess game that would probably never be used.  I'm thinking 2D GUI should be priority, then if in the future I have time to implement a TUI I will for all those crazy dudes who love MUDs and would be interesting in playing an rpg chess through telnet or ssh.
Furthermore! I would like to get a set of editors/utilities created as a way to test the model/view components with needing to worry about controller or actual gameplay.  This should be kept short and sweet, as to not veer off the key goal of creating a functional game.  So probably a Game Scenario editor, which would allow visual changing of particular game configurations: board size and shape, pieces per player ( and their respective properties ), then colors and images (aka skinning), and later game rules.
In addition! dynamic game rules seems to be the most ambitious portion of the project.  Games use scripting all the time.  Quake mods and Unreal mods are essentially large scripts.  I'm just unsure if an XML document can have enough power to create a functional set of game rules.  I guess it'll depend upon a strict xml schema that will make sure all necessary rules are inplace.

Update and Notes on IDEs

First the update.  I've worked out all the bugs from tests setup for the Movement class.  This may seem pretty basic (Movement being a very low level class).  But I have actually figured out how I'm going to implement the XML parsing.  This means very shortly I should have a sample RPChessConfig.xml and RPChessBoardState.xml created and able to be loaded very shortly. (Hooray).

I'm using NUnit to have automated testing for the project as well as speed up development through test-driven development.  What sucks is that Visual Studio Pro and Express don't have built-in support for NUnit testing, and even getting it to integrate with NUnit is a pain in the ass.  I started using Mono Develop on my Linux Desktop. Which had a great interface similar to Visual Studio, yet had all the built-in features I desired. I wondered if I could run it on Windows.  I didn't, or atleast not easily.  But rather Mono Develop is actually a port of a C# IDE called #Develop.  #Develop is great. Although it looks like a windows app, it's not bad for a windows app.  It has builtin NUnit and TortoiseSVN support, both of which I use.  It has more tool support that I may look into in the future.

Moral of the Story: Free and Open beats just Free.

Singleton and Threading

I've realized that the best(only) way to correctly implement the MVC + Log design of RPChess is to have each part Model, View, and Controller as a separate thread. And have the log be a singleton that all of the classes have as a member. Now, the problem of thread safety. I could get away without thread safety (or threads) in the current implementation, since it will be turn-based (and non graphical). But for future implementations the 2D graphics, definitely the 3D graphics will need threads and thread safety. Who writes to the Log? Who reads from the Log? How often does everyone read and write from the log? To signal the need for an update when a move is added to the log, an event should be raised so all the threads update their perspective assets synchronously.

The other issue. Do I really need thread safety now? I'm starting to like Test Driven and KISS based methodology. Like Extreme Programming. It's all about getting results now. I've always had a problem with adding to many features. I recently removed the BoardVector constructor in the Movement class, because a) anything you can do with BoardVector you can do with BoardLocation and 2) I didn't need it, it was making things confusing and bloating the code. I already needed to have XML Documentation for all public things, I don't need to be writing documentation for a hundred things. The documentation for all the BoardVector methods paralleled the BoardLocation. I think I'll start by reading up on thread safety and singletons, as well as their implementations in C# and then I'll make a better decision. But I feel like at least I'll start on the singleton interface.

[Update]
The way I wanted to implement the singleton pattern is actually called a Monostate. Here there are many instances of Log, but the important member data is all static. I am not implementing thread safety.

Move: Attack or Travel?

Currently I have piece Abilities and piece Movement as two separate classes. But If you think about regular chess, All pieces move and attack in one step. Should there be a special class called capture? Should the Ability and Movement be merged? Or should the Move class have a damage property that can be used in case of the original Chess rules?

Capture Class: First, lets think about the special class. There is very low flex ability in that case. You can't make a special class every time somebody wants something strange. Although, movement and attack may be the one other case besides exclusive movement/attack that deserves a case. And If those three classes cover all the possible creative ways people can think up to move or attack with a piece (reasonably), then it may be worth it.

One Super Class: This would take a lot of work and pending changes brakes the OOP philosophy. But if done right there wouldn't need to be any changes in the future. Although, I don't currently have plans for stat adjustments, or lasting attack effects (i.e. poison) but there may be a need for it in the future thus making the SuperMove Class very large and hard to manage.


Move.Damage: This is a very lightweight solution. But it also breaks the OOP philosophy. It isn't very dynamic. Same as the SuperClass. It isn't the smartest choice. But it is the easiest.

I think the best currently would probably be to create a Move interface that both movement and Attacks must conform to, so that adding new classes will be easier. So that the move/attack lists can be simplified and the global move log will have a standard to be built from.