Jump to content

  • Log In with Google      Sign In   
  • Create Account

Orange Chair Software Development



Where has the Time Gone?

Posted by , in Portas Aurora: Battleline 20 August 2016 - - - - - - · 641 views
Portas Aurora, Space, Game, Life and 5 more...

While I have popped not the site from time-to-time over the last couple of years, just checked my journal entries and my last one was 2 years and a day ago, I have been stuck in a weird state of not being able to post much. To fill in the gap I thought I would write a post detailing it all out, then I thought it would be more fun to do kind of a Q&A session to see if I could answer my own hard questions.

 

Q. Why?
A. The project I had been feverishly working on Portas Aurora: Battleline came to a halt when I was deployed. Upon returning I had only a couple of weeks remaining before my move to Hawaii and rushed to get everything a move of that order requires.

 

Q.Why didn’t you continue on your game after your move?
A. I took sometime off to sort things out involving a girl and by Christmas I was hired onto a non game app project and no longer with the girl.

 

Q. Surely you were able to make some progress on your game ideas while working?
A. Originally, I was only working for a month on the project. It was kind of a job interview and prototype and idea of the company’s type of project. It included some bluetooth beacon technology I had previously worked with for the Air Force and the Army. If anyone would like to hear more about that I am game, it has some interesting possibilities for gaming. However, once the prototype was completed they need a lead developer that understood all of the problems the system had. I laughed seeing the issue I had created. Interested in seeing where this could lead I signed on for another 6 months of work.

 

Q. Okay, now it is mid summer and you have completed the side quest, what about a game?
A. Well as luck would have it, the company put in a bid to overhaul a game/social media app and was approved to tackle the rework. I signed up to lead the development, believing that I was coming for my game ideas and not the fact that I was more of a speed programer. The rework was played out to take 45-60 at most. In fact the in-house timetable was 37 days from receiving the source material to a final product. This would be come a grave misunderstanding between two companies as the iOS version was launched and then its completed development status stalled on minor changes that needed to be ironed out before the Android version could be build with speed. If you are curious about what a game / social app looks like check out http://jigsterapp.com. I will do a post mortem on the project in an upcoming article now that I have been cleared to discuss the adventure.

 

Q. How long did the rework take?
A. Technically, the company completed the work in April, but there is a maintenance period that is still in affect. The game/social media app came out leaps better than the original, but I still wanted to have done more with it. A fellow Developer on this site did a large chunk of the art assets upgrades, even if a good chunk went used for poor reasons.

 

Q. April was 4 months ago, where have you been?
A. After some issues of completion payments with the company I was working for a very random chance popped up at the beginning of May for me to attempt to launch a project of my choosing. I debated a bit and finally decided to throw myself to the winds of chaos.

 

Q. So…what happened since accepting the offer?
A. As life would have it about a million random things cropped up as road blocks. I had to move, take on some rush work to make extra money for the move and negations for the final deal on the project, like funding, goals, and timetables. In the first 2 months more than twice the number of things went wrong compared to right. Computer was stuck in Hawaii for the dumbest reasons, phone got taken, Family health issues. Time Warner issues at the Company house. Picking up a new game engine, the final deal in writing dragged on. When the storm clouds finally started to clear around 20th of July some of the people I wanted to group with were already involved with other projects. Still I have pressed forward and last night I returned to the site and interacted for the first time in 4 months.

 

Q. Does that mean that you have some game development news to share?
A. Yes. I have gotten the funding and the go ahead to launch forward with my game idea. Well some of the primary idea have changed, mostly to fit the new timetables and work with the budget, but I think I have a close to tight grip on the design and layout of the game.

 

Q. Okay, going to share anymore about this new game?
A. I still want to do the Battleline game, therefore I went in search of a new title and found: Precursor’s Dawn. The story behind the game is one of the other races have discovered a Dyson’s sphere encompassing an O type star and it is now a race to mining its secrets before they are used to destroy you. I will be doing a more complete article on it shortly.

 

Q. Final question, for tonight, does this mean you have returned to the site?
A. I never completely left it, but I will be posting once again. Excited to have something to add this site once again.

 

That wraps up this entry, but I am excited to see the site so live and I have a ton of journal entries to read and comment on. :)




First Look into Portas Aurora: Battleline Concept

Posted by , in Portas Aurora: Battleline 19 August 2014 - - - - - - · 776 views


This video highlights a few elements of the game and concept ideas.

Updated the graphics to a Standard resolution

Prototype Version of the Interface
Any feedback is helpful.
Posted Image



Graphics Now in 720p

Posted by , in Portas Aurora: Battleline 16 August 2014 - - - - - - · 759 views
Portas Aurora, Battleline, CCG and 3 more...
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.*

*Edit: Due to the introduction of concept art earlier than planned, we have paused production to adjust the current design layout and planed route. Stay tuned for further updates.

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.
Posted Image
Posted Image



Demo Now Visually Shareable

Posted by , in Portas Aurora: Battleline 13 August 2014 - - - - - - · 834 views
Portas Aurora, Battleline, CCG and 4 more...
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.
Posted Image


A Week into Demo Development

Posted by , in Portas Aurora: Battleline 07 August 2014 - - - - - - · 788 views
Portas Aurora, Battleline, Demo and 2 more...
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.


Reduce the Scale or Create a Demo?

Posted by , in Portas Aurora: Battleline 29 July 2014 - - - - - - · 907 views
CCG, Battleline
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.

If there are any suggestions or insight into the creation of a demo I am all ears.


Portas Aurora: Battleline - Card Count After First Balance

Posted by , in Portas Aurora: Battleline 10 December 2013 - - - - - - · 557 views
Portas Aurora, Battleline
This will be a short update, I wanted to make it on Friday, but some of the fixes from the previous post had not been completed. Additionally, this weekend I have began to writing the Android app version of the game. I think the work I have done with build the Android app version is perfect for a post to see if other developers can share some insight on how to do it better.

Posted Image
This is the current Card Report. However, I am thinking about not including the 11 Battlefield Mod cards in the final 390 card collection, which would mean that there is 105 left to be created.
My two primary areas of focus for new cards will be Tactics and Equipment. While not every race will need Tactics I would like more than 20 total options to allow for more play and counter play. Second, with only 3 cards in the Equipment card type it will need to be flushed out.

If you are curious about the original posts related to the balance changes:
Portas Aurora: Battleline - First Play Test
Portas Aurora: Battleline First Balancing


Portas Aurora: Battleline - First Balancing

Posted by , in Portas Aurora: Battleline 03 December 2013 - - - - - - · 702 views
Portas Aurora, Battleline
Second time writing this post so I hope to cover all of the original powers, (power outage).
The first play test brought a fair number of questions up in the hour after it concluded. Interestingly a day later even more questions have popped up and after a meeting of the minds, a small group of friends I like to bounce ideas around, a few sweeping changes to the game came up as ideas to balance current issues. Some of them I supported and have continued to develop on.

CARD TYPES - (Have changed)
Maneuvers: A Maneuver card has as an effect and then it is placed into your Wreckage Pile, which is your discard pile.
Tactics: Are cards that are only revealed if they are triggered. Therefore, they operate like a delayed Maneuver. Tactics are designed to alter the way your Commander plays, the way your hand plays, or even the abilities your units enter the battlefield with. A Tactic card is placed to the left of the player's Flagship and remain in place until destroyed or their durability is reduced to 0.
Units: Units fight for you. They are deployed on to a Battleline and can be used to attack or block. Each unit has Attack, Shield and Durability.
Equipment: Are similar to Maneuver cards, but only affect the unit they are deployed on. Some Equipment have Durability, while most are effects focused on altering single ships.
Crews: Are similar to Maneuver cards, but only affect the unit they are deployed on. If you are familiar with Magic: The Gathering there are comparable to Auras.
BattleField Mods: BattleField Mods bring their own rule to the game. Battlefield Mods are selected by Player 2 at the beginning of the game. They affect the Battleline they are deployed in or the whole battlefield. They have Durability, therefore they can be destroyed by units or Maneuvers.

Balance Changes -
To help players that go second I am looking at having the option to select a Battlefield Mod. This Mod will affect both players equally. Under the this balance map players going second would have the option to select from 2 randomly chosen Battlefield Mods and a third option of no Mods and a resource credit. Additionally a few units will be created to suspend the Battlefield Mod effects to allow countering options to exist. To achieve this new balance map I have made a fair number of changes to the game.
  • All 22 of the Tactic cards have been divided into Maneuvers, Equipment, and Battlefield Mods. The move to divide the original Tactic cards was due the play testing showing that Tactics while powerful for their resource cost, were simply not working in a practical sense. To have an average chance of getting a Tactic card at a time that would affect the out come of the game required 2 copies of a Tactic card in the deck, but having 2 copies of a Tactic card or even multiple different Tactic cards would not be a smart play. Only a few Tactic cards had Durability, and with only 1 Maneuver card capable of destroying a Tactic card they were a more of a liability. If a player draws both copies of a Tactic card the second copy would be useless. Useless cards in a player's hand is a bad design.
  • After designing almost 300 cards only 15 Battlefield Mods were listed. On top of the limited number of Battlefield Mods during the play testing they did not have the desired affect on the out come of the game. At first I thought this was an issue of tweaking resource cost or their effect. However, after reviewing the combat logs it became apparent that players that used them lost their games and even adjusting the cards could not have shifted the out come. I went so far as to setup the results from using them in each game to see if using the perfect result would even help and the answer was, no. While I like the idea of the mechanic the original model it was not producing the result I had hoped for, leading to the about half of the Battlefield Mods being moved to a Unit type card.
  • With every card type being reviewed to see if they are working as intended or if they are having an impact on the game, the next type of card for review were Maneuvers. Maneuvers had a small sub-group that were not visible until triggered (Secret) with Tactic cards empty it seemed the perfect fit to shift the Maneuver cards that were Secret to the Tactic type. With this division I noticed that the Secret, or new Tactic type needs to have the ranks filled out.
With all of these changes the progress of hitting the 390 card count is going to be delayed a few days. The hope is that by Friday I will have the current collection back to 75% and majority of the shifted card balanced before play testing again.


Portas Aurora: Battleline - First Play Test

Posted by , in Portas Aurora: Battleline 29 November 2013 - - - - - - · 496 views

Originally I had planned to write a post walking through the rule set of Portas Aurora: Battleline. However, after the first real play-thru I came to the conclusion that the rules need some re-balancing before they can be posted. While a few play tests should not be the ending word on some points in the game to not review them would only mean less fun for future players. Still this week's main goal was to post 1 journal entry each weekday and today makes me 5 for 5. I am happy for the discovery of these potential problems this early to prevent problems in the future that would be much harder to fix.

Today's Progress Chart:
Posted Image
Today was a very happy day! I completed the goal of having all of the individual race card groups at or above 55% (21 cards). Additionally, the collection of cards completeness is now at 75%, after a 5% boost today. There are still 34 cards that need to be sorted into race groups, which I think will be a goal for this weekend. Being 99 cards from my target size is a good feeling.

Development:
Today was mostly focused on flushing out the individual race card groups, but I had the conclusion that while I thought I had set some rigid standards that cards were created around a few that did not conform have made me switch to ensuring that the terms and mechanics behind each card is functioning as intended. I am sure this weekend will see the removal of a few mechanics and the addition of a few as a play test has shed some light on cards that feature similar text, but there is not a mechanic for the text.

The Mechanic Search Tool has been placed on hold as I am standardizing terms for the second time. Another tool, or an expansion to a tool I have already been using is the individual Race Resource Curve display. Having this will sharpen my attention to areas that need attention, which will be increasingly required as the number of cards to reach 390 shrinks.

If you have missed any of the series installments check the links between:
Announcing Portas Aurora: Battleline
Portas Aurora: Battleline - Card Types Explained
Portas Aurora: Battleline - Mechanic Terms Explained

Portas Aurora: Battleline - Races Explained


Portas Aurora: Battleline - Races Explained

Posted by , in Portas Aurora: Battleline 28 November 2013 - - - - - - · 496 views

First off, Happy Thanksgiving to all!
The Races in Portas Aurora: Battleline do not have names of this post. This is mostly due to a personal need to ensure that the races I select from the written lore line up with the game well. I have set the deadline of Dec. 6th to have the rough list complete and if there is additional required back story for a race I will by then.
Name: Color Battle Style: Unit Trends:
  • Blue - Relays on shielding its assets from damage while maintaining a vast array of options. Race 1 units will favor shields over durability and damage.
  • Purple - Maintaining numerical advanced is key even if they are fields few units. A large percentage of Race 2 units are in the mid-range of size and cost.
  • Green - Establish a solid defense to protect the Flagship and out last the opponent. Race 3 units are split into small forward deployers and massive ships of war.
  • Teal - Bait, Rep, and destroy is the most common battle story seen. Units are designed with the idea that their fleet will contain repairs.
  • Black - "Kill the mother and the children will run," summons them up nicely. Race 5 units feature collection of abilities to help destroy the opponent's flagship quickly.
  • Red - Race 6 commanders tend to lead from front and center of the fight. Race 6 units reflect the idea of close quarter combat and they excel at it.
  • Orange - With a strong focus on Resource control they often over whelm opponents with shear numbers. What they lack in individual offense power they make up for in the number of waves.
Today's Progress Chart:
Posted Image
Not a bad day at 5%, especially seeing that today is Thanksgiving. However, tomorrow's progress will be mostly focused on pushing the individual race tailored cards to at least a count of 21, which is about 55% of the current required level. At the moment there are 100 (81%) race neutral cards and if each race is not flushed out soon there will be a lack of flavor because of it.

Development:
I completed a new tool that allows me to see the number of units I have with different Attack, Shield, and Durability. I was happy to learn that there were a few holes in the current lineup. I was able to use the new knowledge to beef up some weak areas and provide some alternatives. There are still some thin areas, but this only makes me more eager to create another tool to see the number of units using the current list of mechanic that I explained in yesterday's post.
Posted Image
Sorry of the data not being the most artistic display, but the tool was designed to help me craft cards for areas that needed improvement.
Additionally, the link to the Card Creator is here. I am still updating it, but if you want to submit an idea feel free. Posted Image

If you have missed any of the series installments check the links between:
Announcing Portas Aurora: Battleline
Portas Aurora: Battleline - Card Types Explained
Portas Aurora: Battleline - Mechanic Terms Explained






August 2016 »

S M T W T F S
 123456
78910111213
14151617181920
2122 23 24252627
28293031   

Recent Comments

Latest Visitors

1 user(s) viewing

0 members, 1 guests, 0 anonymous users



PARTNERS