A Week into Demo Development
Portas Aurora Battleline Demo CCG Design Document
After setting some rough boundaries I drafted a Design Document for the Demo. This brought a fair amount of discussion over whether a different document was required. However, the basic logic of the Demo only covering a faction of the full game's scope and therefore would present some of its own unique challenges won the day. Because of this we are treating the Demo as an independent project.
The second step was to find a setting for the Demo. By setting I mean a language and possibly a platform/engine to create the internal framework. As part of the limitations the number of art assets available to the Demo were virtually none and we are not looking to create them first. (The actual game version has only a hand-full of drawings for board design.) Therefore, the Demo would have to be "playable" using quickly created placeholders.
We have a licensed copy of Unity and after seeing Hearthstone shine on the engine it seemed the perfect idea. However, after a few hours of tinkering it was found that using the basic placeholder object in Unity would not be a workable solution. I am not saying that Unity is bad. I really enjoy working with it and believe the final/full version of the game will be powered by Unity, but the current design listing of the Demo requires it to be created quickly and with few art assets something that slowed down Unity production. If we had most are or at least 50% of the art it would be the perfect solution.
Having just finished a fair number of Java based products just before shifting focus back to game development it was suggested that Java be tested to see if it fit our needs. While being a skilled programmer in Java it is not a favorite language of mine to write in. Still as a team project and the fact it was a valid idea a few hours of testing was spent. Again the same issue of being limited by weak placeholder objects began to slow development. After the results of the Java trail were sent to the group the matter of finding an artist to even begin the project was brought up.
Art is a very key element in a successful game and we have been looking for an artist with the vision and talent in the direction of the game. Still there is a need to move forward and this need finally broke the back and forth over the artist topic. We are mostly a group of people that do web development and it was asked if we could just make the Demo a web app. It would allow the highest percent of us to program and review the project compared to other platforms. In a massive burst of laughter it was decided that this would be the route to take. It did bring up a few question of why this was not thought of first, but I think because we are not full-time game developers we had brushed aside a large portion of the talents we used on a daily basis because of our rookie status.
The third step tends to be the one the most hair is lost over, construction. The full game had been prototyped as web based and we quickly went to the archives to see if there was anything useful. The first few days were a flurry of emails and Ventrilo comments of "Go to my url." The board evolved from a very basic table based layout to a colorful interactive sight. The Design Document was always open with people talking about how best to achieve the set goals or if some of them were a little grand for the current scope. The second pair of days didn't see the pace slow, but there was less enjoyment because there was a data structure issue that had been discovered because of the heavy traffic testing. The game board (Battlefield) had already seen a half dozen alteration and improvement because of testing, but this data structure issue was not going to be a low time investment issue. With hundred of cards in need of being moved to the new system there was a lost of steam.
Design Document saves the day. An early morning meeting over the newest purposed data mapping remained us that the Design Document only called for approx. 90 cards to be in the Demo. Either for the lack of sleep or the early hour someone made the comment that we select the Race with the least amount of cards requiring conversion. The idea was simple and became a fresh western wind into our sails.
For now the project has been divided into two subgroups Battlefield Data Tracking and Card Conversion. Both systems require that the other is function before they can be tested and in a few hours the latest build will be tested, but first I wanted to post this update. Due to the state of flux of the Demo's visuals, I will hold off on posting any images. Creating the Demo will require another week or so to account for all of the changes that are being made to the game and its data structures, but we are are all in good spirits even over some of the more challenging tasks on the list.