clarifications on how the ship knows its attack state.

1. Is it the player's turn? yes/no

2. Has the ship attacked this turn alreafdy? yes/no

           a. if yes, does this ship have an upgrade that willo allow to attack again?  yes/no

3. Does the amount of CP required to make this attack exist within the player's CP total? yes/no

4. Is the ship under any condition which keeps it from being able to attack? yes no.

these are the requirements for a ship to be in a state where it can attack

In order to do this you'll need to build tables in order to tell the computer if those registers are in the on or off state.  I'll email you the excewl workbook where I compiled all the charts and tables for where to pull these bits ofm data from.

i.e. Player uses special ability, that special ability is then deactivated for x turns.

The computer must then reference equipment table section x,y then subtract the number of turns it has already been deactivated. Each action is linked to a bunch of different state registers,

ok, next we'll discuss battlezones and the challenges they impose to coding.

A battlezone is basically a self enclosed table that imposes certain variables onto a ship whose "location" register matches the name of the zone.

In the developer's manual a number of battlezone properties were listed. However for the sake of creating the game engine, I want to push the construction aspect off until an expansion.

So let's concentrate on what's left.

What properties does a battlezone possess that are important to the game mechanics?

Location associations. As the mission map is laid out in a grid, each zone can have associations with up to four other zones. These are represented to the player in the "movecard" as four possible choices for movement when the player presses the "movement" button on his selected ship.

For the programmer, first the zone in question needs to know its relationship to the mission map. So it must ask the question, "am i associated with zone x? if no, do nothing. if yes assign that zone to one of the four directional move choices on that ship's movecard. To assign the zone to the movecard, each zone must also have a linked association with a number of icon graphics files. Then for example: association to zone "carina nebula" yes, assign movecardiconcarinanebula.jpg to frame 1 on shipmovecard.ussvictorious.movecard.obj . Then on the ship movecard frame 1's properties are adjusted to: change ship location register to "Carina Nebula". If the player then chooses that location, the ship's location register changes to "Carina Nebula". Then x.movecard.obj initializes its secondary command which is adding shiphyperspacejump.leaving.animation.obj to the list of animations being stored in the procedural graphics engine database. Then it adds the tertiary command string to add shiphyperspacejump.entering.animation.obj to the stack of animations to follow sequentially after the shiphyperspacejump.leaving.animation.obj file.

Now that the basics of movement are explained, lets move to number's of ships allowed

Ok, the best way to explain this is with graphics.

here we have the beginning of the player's first turn. He has

10 Command Point

30 Defense points on his mothership.

He is at Arbitron III, his mothership coincidentally is also located at his start location.

he decides his best bet is to drop out multiple ships and move this turn. so he chooses his cheapest ship. a standard (lvl 1-4), common (grey bordered icon), frigate (type not displayed, maybe will be in final version), it brings up his confirmation dialog and he presses yes.

this is what the confirmation dialog looks like. To choose the ship top deploy, just tap one of the button icons in the staging area.

This is now what it looks like with the first ship deployed.

the ship icon has been moved from the staging area to the deployed area.

A green rocket icon has been placed on the mini-map to show that he is there.

both the icons are now indicated with a green color, showing that they are at full health.

The player's CP total dropped to 7, representing the CP cost lost by deploying,

the full size ship is placed on the screen on Arbitron III

As you can see, the turn is still far from over. The player still has ships in the staging area and a lot of CP to use.

he decides, that he'll bring in some heavier weaponry, he has a lvl 4 ship that costs 5.

he brings it out and is left with 2CP to use.

what should she do next?

On the bottom of the screen you see the deployed ship icons. Each of those is a pressable button, tapping those buttons brings up the ship infocard which allows you to attack, move, or use special abilities.

There is only enough room for 5 icons. We could make them smaller to get more ships in the game, but right now, they are the perfect size for being an interactive object.

Now that the player is down to 2CP, he can't afford to bring out any more ships.

So what now?

Both her ships are frigates. So that means they only cost 1 CP to move.

She decides she wants to move her strongest ship first.

Her uncommon lvl 4 is equipped with a triggered shield generator, so she decides it is more survivable.

She chooses that ship and hits the move button.

Then the player is shown the shipmovecard. It shows all the locations that ship can jump to. Since this is a tutorial map, the initial space only has one zone it can move to. It is in the up direction towards what looks like an asteroid belt.

the rest of the directional options are clearly denoted as being unavailable.

The player chooses to move and 1CP is removed from their pool, leaving them at 1.

their ship jumps into the asteroid belt, but oh crap, there's another ship there!

The player wants to know what that ship is all about, so they hit their attack button to see if they can get targeting lock. (with the cloaking ability, even though the player can obviously see the ship on the main screen, that ship does not show up on the minimap nor can it be selected as a target on attack or special ability screens.)

Well, the ship isn't cloaked, and apparently it is pretty weak. only 1 attack, 1 special, and 4 defense.

They could choose to use their last CP to either attack that enemy ship, or to bring in reinforcements.

seeing as ships only get one move action per turn they decide its better to make the second ship move up this turn, so they get a full amount of move actions next turn. So they decide not to attack using their last, CP, but to end the turn having a decisive advantage. They move up their second ship and end their turn.

So now you've seen a full beginning turn completed.

Any questions?

here's some flowcharts

MOVEMENT GRAPHICALLY EXPLAIONED

if you get a chance it would be nice to have all the movement UI in a folder on the teams google drive, UI folder. and each one separated, into its own .png file so we can easily grab them and insert into the project. 

ok, it's been a while since anyone posted here. Before people start thinking we're vaporware, let's give some news on updates.

1. We've pulled together working code to link ui buttons to action scripts.

2. We've managed to turn the ship art into programmable asset files

3. A usable 2d/3d ship placement system is in place.

All very excellent work! now the programming team is hard at work linking those ship entities to weapons and particle effects. We should have a video of the working system in by next week...

So what will the video show? It is proof of concept that high quality 2d hand drawn ships on a 3d backdrop can still convey the epic scope that is essential to space strategy games.

So what's the plan moving forward once we know that these ships can indeed combat each other in the depths of space?

This is where we start entering the nitty gritty of what makes spacemasters different from every other game out there.

There is already code in place assigning each region of a battlezone to a box or cube. Now, to make the game epic, ships need to be placed in there in such a way as to move the story forward. (yes, story. more on that in a much more future update)

However much more basic challenges need to be overcome first.

Code needs to be generated that places those ship asset files into a list or roster. (I suggest starting small, with 3 ships at most.) Ensure those ships have register values assigned to CP cost, Attack value, and defense value.

This is the baseline for the second core segment of the spacemasters game system. Bringing in your fleet of ships to overwhelm the enemy.

Once the roster is programmed, a script needs to be written that links the pressing of a button on the ui with a set of actions. first it needs to bring up a secondary ui window, this ui window will allow the player a set of choices, a "yes/no" choice in fact. The choice the player will be faced with is, "deploy this ship or not?"

If the yes button is pressed, then another set  of actions takes place.

the game should automatically subtract the ship's CP cost from the player's CP total

Then the game must place that ship's asset onto the battlezone.

As the battlezone is divided into a set of receding gridlines, the computer must answer a question prior to placement. Is section x available for ship placement? if yes, then place shipgraphic.iconfile in section x. before all this happens the computer runs a random number generation sequence to randomly assign the ship to a spot in the battlespace.

Then the script needs to initiate the "hyperspace jump in" animation sequence in the battlezone section that ship has been assigned to, which will end with the ship's in game graphics file sitting in that region of space.

So the end state will be the player's cp total reduced by the ship's cp cost, and the ship sitting out on the screen.

That should be e bit to work on.

Framing and storyline is coming together. 

I will be working on a general bible for background development and as elements are concepted, developed and coded I will work with you all to integrate them into the storyline. 

If this is a centralized type of information, you should just use Onenote. That way anyone and everyone on the project could reference it at any time, and it will centralize the and streamline the storywriting process. I'll email you the link

Hey All,

here is an interesting document that provides some conceptual information for a payment system under review:

https://ripple.com/ripple-mm.pdf

Yeah, hold on to that design doc for sure, we will have to integrate a bunch of the Ripple services to create a robust transaction platform.