Team C: Production thread

Ok, I'm starting a production thread for Team C. This thread is where we will list current team members, frequently update what they're currently assigned to do, and any posts regarding who is or should be doing what, and what else the project needs in terms of content and resources.

Active team members, please check this thread regularly.

17/5/2009

Current Team members

kthuynh86, Project manager, game design (missing in action)
mulletdulla, Game design (Game Design document refining, simple flash prototype of ideas and GUI)
Roger, Programmer (Engine research and prototyping)
Sugo, Programmer (Engine research and prototyping)
CopyRay, 3D
ussmc2, Character animation
MattD, 3D
Briefcase, 3D
HemantD, 3D
OverActive-Imagination, Sound design
JohnN, Concept Artist (developing and refining concepts)
Souri, UI designer (acquiring engine licenses)

souri's picture

Guys, download the trial and give it a solid try first. Would love to hear your comments on it. I don't think we'll use the asset server options since that's a $599 or so addon extra for everyone. I might have to get a friend to install subversion on this server for our projects. In any case, I've read that the devs behind Unity have cvs capability in Unity's roadmap.

suggo's picture

EDIT: Sorry about the formatting HTML tags aren't working for me

I've been looking at the kind of data we need for game objects and how it could be structured in game.

I have put together some very simple and dodgy tables in a word doc but realised I can't upload it at the moment so for now I'll give you a quick run down of my thoughts and if anyone has any tips, go for it, this is very much a work in progress.
Different planets are going to need some common properties each planet with variations of the following fields, moons could also have a similar set up and both derived from the same base object:

  • # Health - to gauge destruction of planets
  • # Nodes - a list of nodes and what may or may not be built upon it
  • # Orbital Territory - this could be expressed as a radius from the planet center to check if objects are in range
  • # Speed - speed that the planet does in orbit (should we also be worried about planet rotation? or just leave that out because the scale here is so large i.e 365 rotations per orbit of the sun may be excessive)
  • # Size - size of the planet in diameter or radius, this could be just used as a scaling factor for models so multiple planets can be created from one model or also to scale health depending on size to give a population number like in defcon (size multiplied by health equals population, or something similar)
  • # Orbit Radius - the distances to the center of a planet or moons orbit (thought this could help in calculating fuel consumption based on planets while they are moving or some other calculations)

In the design doc I tried to find ways of measuring the individual ship properties, this could probably be fine tuned as we play test but the fields I thought we could have are below (let me know if I have left any out):

  • # Health - obviously to gauge damage
  • # Attack Strength - strength of weaponry
  • # Attack Range - minimum distance to engage enemies
  • # Attack Type - I thought we could have a way of classifying what a ship can attack as this was written in the design doc and I couldn't think of any other way to implement it, perhaps we could only allow certain ships to get so close to certain objects an hence some will fall outside the minimum range? or just have a list for each ship saying hat they can and can't attack? thoughts?
  • # Defense - factor by which to decrease damage for shields etc
  • # Speed
  • # Fuel Consumption - amount of fuel consumed while travelling

And of course star fleets are made up of a combination of the ships, the star fleet as a group will need a command field to maintain whether they are in an offensive or defensive state.

Hope I'm not just rambling and this makes some sense people. I believe we need to get a very clear picture of what each objects role is and go from there. Start with the physical 3d objects in the game then the entities that control them, it might be good to get a basic player system up also before introducing the objects, like player controls and camera movement and basic mouse picking etc.

For now I will try and get the research process straight in my head and think about implementation, it's a little fuzzy right now and I'll come up with ideas on implementing the other objects and get back to you guys with a bit more of a document.

Just a side note: for anyone who is interested I was looking at solar system images to see a true scale and apparently this is it
I really like the massive intimidating sun, I think this could be very cool. Not sure how it is in other games I haven't really played any solar system type games but seen as though "solar" is in our title we should make a big deal out of it ;)

fuedone's picture

i have been trying unity out over the last 2 weeks, done the basic tutorials, its fairly complicated to get a grip on compared with building your own engine, but im slowly getting there

if anyone finds some mid level tutorials on it, let me know about it lol

Anonymous's picture

replying to your data propeties post suggo ive got a few additional notes:

Planets

• # Health - to gauge destruction of planets
• # Nodes - a list of nodes and what may or may not be built upon it
• # Orbital Territory - this could be expressed as a radius from the planet center to check if objects are in range
• # Speed - speed that the planet does in orbit (should we also be worried about planet rotation? or just leave that out because the scale here is so large i.e 365 rotations per orbit of the sun may be excessive)
• # Size - size of the planet in diameter or radius, this could be just used as a scaling factor for models so multiple planets can be created from one model or also to scale health depending on size to give a population number like in defcon (size multiplied by health equals population, or something similar)
• # Orbit Radius - the distances to the center of a planet or moons orbit (thought this could help in calculating fuel consumption based on planets while they are moving or some other calculations)

- Planet data table needs to list amount of moons inside the planet’s orbital territory
- in addition to this it may be worthwhile to provide the same table for moons
o Moon data table exempt from:
Orbital territory
Health

Moons

• # Nodes - a list of nodes and what may or may not be built upon it
• # Speed - speed that the planet does in orbit (should we also be worried about planet rotation? or just leave that out because the scale here is so large i.e 365 rotations per orbit of the sun may be excessive)
• # Size - size of the planet in diameter or radius, this could be just used as a scaling factor for models so multiple planets can be created from one model or also to scale health depending on size to give a population number like in defcon (size multiplied by health equals population, or something similar)
• # Orbit Radius - the distances to the center of a planet or moons orbit (thought this could help in calculating fuel consumption based on planets while they are moving or some other calculations)

Star ship data need to be divided into a few separate data tables:
Fleets
Ships
Weapons
Shields

Given that all ships are grouped into fleets, fuel consumption needs to be controlled at a fleet level.
Fleet data tables need to describe the type of ships in the fleet and the amount of each ship type.
We need to describe base fleet types, and describe the composition of each fleet. There should be separate data tables for each fleet type.

Fleet Data tables need to control the amount of Fuel Consumption during travel as all ships in a fleet can only
• # Fuel Consumption - amount of fuel consumed while travelling
• # Fleet Composition – types of ships in the fleet and amount of each.

• # Health - obviously to gauge damage
• # Attack Strength - strength of weaponry
• # Attack Range - minimum distance to engage enemies
• # Attack Type - I thought we could have a way of classifying what a ship can attack as this was written in the design doc and I couldn't think of any other way to implement it, perhaps we could only allow certain ships to get so close to certain objects an hence some will fall outside the minimum range? or just have a list for each ship saying hat they can and can't attack? thoughts?
• # Defense - factor by which to decrease damage for shields etc
• # Speed
• # Fuel Consumption - amount of fuel consumed while travelling

“Attack Type” needs to be referenced to the type of weapon the ship uses.

Laser – short range, ignore armour %, weak, fast rate of fire, double dmg against shields
Lasers are the base weaponry
Rocket – long range, ignore armour %, slow rate of fire, strong
Rockets are used to destroy high armour targets (artillery ships)

For now two weapon types is a good start, we can increase this later. This establishes some more dynamic combat game play

Defense needs to be divided into two properties: armour + shields

Armour is the base damage reduction percentage – can be set to light/medium/heavy (each state has a defined amount - ships reference these armour states)

Shields are force fields generated by certain type of ships
Have a flat dmg absorb amount
When dmg has been absorbed shields are turned off
Shields need have their own data sheet that describes:
Dmg Absorbtion – amount of dmg shields can absorb
Recharge – amount of time it takes the shields to recharge once down

Hope this helps, I've begun adding some of these features in to the GDD

~ mulletdulla

suggo's picture

Nice work Mulletdulla! I've been busy lately and haven't had a chance to get on here. Thanks for your comments I will try and put together some more info and come back and we can compare notes again and get the design truly laid out.