Skip to main content

Team C: Production thread

  • In my first and previous post in this game dev log entry, I had written that I wanted to do a game which was a collection of simple retro games. Unity released a new major release (2019.3) while I was putting the initial project together, and I…

  • Well, I'm making a game . I'm spending the next few weeks on making a small game to showcase the gamedev log feature on tsumea where any member can create a game entry and other members can post journal posts with art, music or just development…

  • Just a test #2. Still working on the new section.

  • So, I got a Commodore 64 when I was in the 4th grade. It came bundled with a Rolf Harris picture building program on casette tape which never loaded properly but from what I could tell by its box cover, you could build pictures from a selection…

  • Yes, the site looks very different and I've had to prematurely switch to this new theme that I'm working on for a few reasons, the main one is that changing certain aspects of the site to fit the new theme will affect how the old one looks for…

  • (this is just a test, please ignore this entry)

    Here is some of my old work.. the first pic is of a 3d model of a human head I was working on about 2 years ago in 3dsmax, using nurbs. If I had to do it again, I wouldn't model a head with…

Submitted by souri on
Forum

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)

Submitted by souri on Wed, 15/07/09 - 3:50 PM Permalink

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.

Submitted by suggo on Wed, 15/07/09 - 9:19 PM Permalink

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 ;)

In reply to by Anonymous (not verified)

Submitted by fuedone on Thu, 23/07/09 - 9:17 AM Permalink

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

Submitted by Anonymous (not verified) on Mon, 27/07/09 - 12:32 PM Permalink

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

Submitted by suggo on Wed, 29/07/09 - 7:57 PM Permalink

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.

Posted by souri on
Forum

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)


Submitted by souri on Wed, 15/07/09 - 3:50 PM Permalink

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.

Submitted by suggo on Wed, 15/07/09 - 9:19 PM Permalink

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 ;)

In reply to by Anonymous (not verified)

Submitted by fuedone on Thu, 23/07/09 - 9:17 AM Permalink

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

Submitted by Anonymous (not verified) on Mon, 27/07/09 - 12:32 PM Permalink

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

Submitted by suggo on Wed, 29/07/09 - 7:57 PM Permalink

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.