• Register

Founder of Orange Chair Software. At Orange Chair Software we want to create games with great stories that are supported by the game play.

RSS My Blogs

Reduce the Scale or Create a Demo?

PortasAurora Blog

Scale of a project is often the weakest point in a game's development. The game I have in mind to create is no different. Battleline is a Collectable Card Game (CCG) with nearly 500 cards alone scale is a large factor in the amount of time it will take to rocket the game from a design document to a product lighting up screens. Therefore, to allow the public to get a taste of the game companies create demos and vertical slices. I have decided to create a demo in hopes that the limited scope would grant me the opportunity to complete a minor project and a peak into the possibilities of the full game.

After talking to a few people a rough draft of boundaries on a demo emerged. There are 7 planned playable Flagship Captains along with 4 battlefields, and approximately 500 cards. All of this leads to a laundry list of 800 art assets that need to be created and displayed. However, a demo would not need to include everything found in the final game. The goal of the demo would be to display the gameplay mechanics and generate interest into more content. With this in mind I have decided to create a demo of Battleline that showcases two of the Flagship Captains, two enemy AIs, one battlefield and around 90 cards.

Portas Aurora: Battleline Demo:

  • 2 Flagship Captains
  • 2 Enemy AI Settings
  • 1 Battlefield
  • 90 Cards

There has been some debate on whether the opponent for the player need to be their own individual captains or is it okay to just use the non selected Flagship captain as the enemy.

Portas Aurora: Battleline - Mechanic Terms Explained

PortasAurora Blog

As with any system there are keywords that allow more complex ideas or actions to be expressed. The following is a list of the terms for mechanics used in Portas Aurora: Battleline so far:

Active Defense: At the end of your turn repair 1 durability of this unit.
Auxiliary Power: Adds extra damage to Maneuvers that deal damage.
Charge: Can Attack on First Turn Deployed (Looking for a different Name).
Disable: Prevents Ship from Attacking or Defending for 1 turn.
First Strike: When this unit attacks its damage is appealed first. If the target is destroyed this unit does not receive targets damage.
Hardened: Ignores 1 damage.
Immobile: Unit can not move.
Indirect Fire: Unit ignores Battleline order when attacking.
Intercept: Forces Enemy Units to attack this unit.
Jamming: Removes all effects on Target unit.
Jump(x): Can move to location within range.
Maintenance(X): X is the amount of resource this is reserved for this unit and can't be spent on anything else.
Nimble: Ship has 1 movement action.
Rapid Fire: Attack Twice
Ranged(x): Can Attack without being adjacent.
Pierce: Damage above target defense is applied to units behind it.
Pursuit: Follows the movement of the enemy unit forward of it.
Scout: Can be deployed in either your Battleline.
Stealth: Untargetable until attacks.

Deployment: Action that occurs upon the unit entering battlefield.
Final Order: Action that occurs upon the death of the unit.

Graphics Now in 1280x720

PortasAurora Blog

After talking with a few devs in the chat here and talking to other team members, it was decided that the next logical step would be to upgrade the graphics from 720x938 of the image shown in the last posted to a more "standard" resolution of 1280x720.
With the change in display size I understood that the UI would need to be updated to fit within the new space. However, I did not think that the game itself would evolve a bit with a simple change of the display size. The battlefield changed, where there were once 2 rows of 5 columns for units to be deployed there are now only 9 total spaces. Comments I received noted that at first it was confusing on whether or not a player's units could move onto the opponent's side of the field. Therefore, we moved the point at which the two sets of Battlelines came into contact away from each other. The hope is makes possible movement and deploy positions more intuitive to new players.
Additionally, we are working at a feverous pace to have the possibility to open the Demo to a few players to test out this coming Monday.

Feedback is going to be key to tightening mechanics and grand players the best possible game. If anyone is interested in play testing please drop me a message or a comment.
Updated Graphic Resolution

Demo Now Visually Shareable

PortasAurora Blog

My last post, check it out, talked about the process leading to the creation of Battleline's Demo. Now 12 days into the Demo's development it has finally arrived at a point where, I believe, it is visually shareable.
The included Screenshot is of a game during the player's side of turn 6. The graphics are ALL placeholders with the white blocks being the target of future art assets. While I could talk about all of the things going on in the displayed image, I believe fellow developers would like to hear about some learning points that came up along the route to this point.

The planning period for the Demo took a full day. We, the team behind the project, have learned that it is often the case that 1 minute of planning saves 10 fold as much time in headaches and lost focus later. One point that came up a lot during the planning was the idea that images even placeholders would gate development. This did become a fact at a few points along the path to the Demo's current state. How and where the stat data for units would be stored effected more than a handful of decisions on how information would need to be handled. We were lucky that there was a cache of 300 cards to draw from for the testing. The graphic problem was a bit worst that "normal" due to the idea that the images used would have dynamic base images that would allow the demo to assemble the unit's image from data within the current game. The first version of the Token, the term we use for the unit on the battlefield, took about 6 hours. That is a lot for something that looks close to the level of MS paint. The key time saver came when we start tying more elements within the game together. A unit's stats could be changed and the image changed, not to another one from a library, but the core image. It also allowed us to play with size and spacing at an accelerated pace.

A second large point that may have cost us a day or even 2 was the decision to try and modify the prototype code of the Demo into the final version. There was a fair amount of back and forth, and in the end some hoped it would allow us to see more results sooner. Sometimes this can be a good idea, especially for teams that have worked on projects of similar types before. However, we have never developed a CCG and some of the crazy pitfalls that come along dealing with how cards that generate or use other cards throw some of the prototype's basic structure into a fire that consumer it.
Currently 95% of the prototype's code has been replaced with updated and tighter fitting solutions.

If the last 12 days had to be done over, I would do a few things different. First I would spend maybe another day planning the timeline between art assets that would act as time gates and have them knocked out ahead of when they would limit development, Second the decision after the prototype was deemed complete to continue used that code base for the production version, I feel was a mistake. Still hindsight being 20/20 I think 12 days is fairly fast for the current state of the Demo, but I will see what the community thinks.
Version 0.0.1