Team C: Design Brief

By the way this is just a quick overview of the features and style of game play I have designed - I will be writing up a completely fleshed out document over the coming week.

This is really for you all to read points on, see what you like and what you don't like so i have a bigger better picture for what we all want to work with while I write up the main game design document.

SO dont be shy! hit up the feedback.

I like your ideas, especially the rotation of the planets in orbit. this will require the player to be careful while timing their attacks and adds a very interesting twist to the gameplay.

One thing that I am not so keen on is the resources and research stuff. My point being I think it would draw away from the defcon like play and lump it into the general RTS category (mind you I don't play many RTS games and when I do, I tend to lose).

I think if we have these areas we should try and keep them simple and not too complicated. You mentioned credit, energy, metal and fuel, the ones I really like are fuel and energy, these can easily just affect the speed of units as they move and their production, fantastic. If a player simply takes control of that area by having a base or whatever within range or destroying the enemy, therefore taking control of the region. I am a little bit worried that credit and metal may over complicate it. Same with the research stuff, I wouldn't want to see too much focus on research to make the units stronger etc. defcon is a timed game and I would like to see ours also very focused on time and destruction as opposed to research and upgrading units, although research and upgrades would probably lengthen the replay factor, which is good but it would also increase the length of matches. Defcon allows you to play at almost whatever pace you want, fast or realtime, this is another element I would like to keep.

Let me know what you think, these are only suggestions, I would like to hear what others think also. I think that the success of defcon is in it's simplicity, it eliminates a lot of the complicated things in most RTS games, I know we shouldn't be cloning defcon but I feel we should try and keep some of the core gameplay elements of defcon.

"I think that the success of defcon is in it's simplicity, it eliminates a lot of the complicated things in most RTS games"

Once the initial launch hype of Defcon was over, not as many people stuck with the game unfortunately. I think that can be pinpointed to it's simplistic gameplay (where it's carved out a niche of fans of that type). I've read so many comments from people who've tried out the demo and said it was fun for a few rounds, but it didn't create enough interest for repeated play.

I agree, Defcon wasn't set out to be an RTS, but I think there's a great potential to expand on the idea and add more strategy, depth and lastability that RTS elements would provide.

Due to the opinions here I went about adding depth into the design brief.

Suggo I agree with you too. One of the things I do not want to do was take away from the emphasis of the defcon game play by adding additional elements. Realistically what needs to happen is these elements; resources, research etc etc need to only enhance the core game play of timed, critical execution.

If we factor in the idea that we want to explore the possibility of added forms of gameplay then as we design, build and test we can work out whether they work, how effectively they support the core focus of the game and how best to iterate on it.

It becomes a lot of work but if we can solve the problem of adding these additional features without taking away from the core game play then we are ultimately sitting on a winner!

While looking at interplanetary Defcon you should also look at Planet Attack. It seems similar to what you are looking at here though it doesn't have defcons.

The game is based on population, there is only one resource and that also equals your score. Everything you buy costs X and each use costs X. It is hard to get the hang of (I hope your controls will be easier to pick up) but once you get there it is a good game.

first and foremost.. I'm glad you noted a planetary orbit system, it was one of the first things that came to my mind when the idea of defcon meets space was being thrown around. purely cause you don't often see it in space strategy games.

over all I'm very excited about getting started on this game just from looking at the basic outline, although like others the number of resources scares me a little. I think toning it down to 2 or 3 would be much simpler and less frustrating.

also i was wondering if there was any ideas for art direction or if anyone was in charge of concept art?

I've made a separate thread for discussion on the art. You can see it here.

To push the project along a bit further, could you break it down so that the types of vehicles and assets needed are listed? Just want to get a better idea on what's needed so we can allocate jobs to the artists and get concept art started.

Also, Roger, if you're reading, can you comment on the choice of game engine please?

Hopefully by the end of tomorrow I will have a fully fleshed out design doc for viewing. I'll include in it preliminary asset and feature lists for the artists to get that ball rolling then.

The next steps should really be to build a low level prototype of the game. I might try to do this on paper and I will post all the material I make from it. The game is heavily systems based so I want to get a really good idea of those systems flow and what areas need to be focused on the most.

I also had a bit of a look at Unity over the weekend - its a beautiful little package and can work really well to support the location issues we will no doubt face. Everything works in and out of a meta data asset library; if we can set up a server that we can pass these assets over then a lot of those boundaries can be crossed. We can get more into this later; I still need to check out some of the other freeware engines mentioned.

No need to rush, just making sure everyone knows where we are at, at the moment.

I think the version control / asset management for teams thing is only for the pro license of Unity. Unity also has network functionality in the indie license which is something we'll definitely need.

a new design brief has been linked - im gonna make a separate thread for asset lists

Just a note, we should be getting industry feedback on your design document real soon.

He Guys,

Over the last couple of days I've been doing some basic prototyping on paper.

I drew up 2 solar systems with 3 planets each on three different orbits. The solar systems were roughly symmetrical with the planets roughly the same distance from each other with the same orbit lengths. Each planet contained a different number of moons or resource slots but the total resource slots were equal over both systems.

The flow of the game play was taken in turns by month - each aggression protocol having 16 months total. However I only got through the first Aggression protocol for reasons I will explain later.

Each month the planets moved around part of their orbit and updated the players resources.

I mocked up some basic stats for the resources:

Fuel stations gave 1 fuel(1f) each month
Fleet movement cost 2f per cm of travel on the paper.
each cm took 1 month to travel
home planets contributed 2 credit (2c) per month
Mineral stations contributed 1c per month

I set the game up with 2 players - both started with:

1 home planet
1 fuel station on their local moon
tax
1 engineer fleet
2 attack fleets
1 artillery fleet

As I started playing the game out two things became abundantly clear:

The orbital system is really awesome.
I sent player 1's engineer fleet to a resource node on the first month while I sent player 2's engineer fleet on the second month - both arrived at their destination on the same turn but because player 2 waited a month the destination of the resource node became closer by orbit costing them less fuel.
Other times a player couldn't afford to send a fleet to a given destination until the fuel consumption was efficient enough.
The strategy and forward planning there is excellent

The second thing I noted was just how taxing it was for me to complete the calculations on paper for things as they accumulated each month - keeping track of what was building, what resources were coming in, fleet movement. Even though I kept the numbers small this became difficult to manage.
Moreso, I found the initial figures I set for the resources, especially the fuel were too taxing on the player so I had to start again with a different set up.

In conclusion, given a set number of rules, the underlying systems of the game can work really well. I just need to set up a better way to prototype it that allows me to play around with the figures by inputting different numbers.

It will take me a few weeks I imagine to set up a working prototype in flash. If any of the engineers wanna give me a heads up and lend a hand to this prototype it will be more than welcome.

In the meantime I'm gonna mock up some basic UI sketches for Souri to work from and flesh out the amount of feedback that needs to be presented in the UI.

Cheers,

Ryan

'feedback' over states the notes i made whilst reading the design doc. More a list of things that triggered in my mind whilst reading that i thought I'd post in case they fired off more ideas for others. I should qualify that I'm not a RTS fan, so I rate some game play details as tedious rather than engaging, so if the goal is an absorbing RTS style game my comments on those details should definitely be ignored.

Okay here are my notes:
-------
Distances within system very small vs distance between systems = travel problem (more a general statement than addressing a game aspect). Decreasing time scale through game may lock in styles of game play rather than allowing variety of tactics to be feasible...look into other options?

eg: Slingshot ships around planets to accelerate them to the enemy system? Creates handy excuse to remove travel time between systems.

Potential micro managing game play (research, orbit distances, attacking sections of plants, resource gathering) may detract from key elements/novelty of game? Eg: Simplify to ships that are in orbit replenish consumables (ie.fuel/attack&defence energy) or all altercations are 100% win/lose outcomes.

Moons could represent resources/launch aid making planets with moons more tactically valuable (more moons = more valuable).

Imposing defence condition levels may lock in styles of play or restrict tactics unnecessarily? May be create game play that will naturally escalate progressively. Aggression level set by events, events are not set by aggression level.

'subdued home-world loss' pointless option for defending team – total destruction more dramatic outcome too.
---------
good to read you are doing some tests with the orbiting systems mulletdulla, I suspect if vaguely realistic travel is implemented jumping across a system might be super complicated!

Hey John, thanks for the feedback I like this.

First of all I'm not quite sure what you mean here,"Distances within system very small vs distance between systems = travel problem" by travel problem, what are you describing as the actual problem?

---

"Potential micro managing game play (research, orbit distances, attacking sections of plants, resource gathering) may detract from key elements/novelty of game? Eg: Simplify to ships that are in orbit replenish consumables (ie.fuel/attack&defence energy) or all altercations are 100% win/lose outcomes."

This is definitely something that I'm concerned about and there are a couple of steps to solve some of the issues presented by it

- things like researching, orbital distances, resource gathering and travel planning should be incredibly well streamlined.
- for instance, to set up a fuel resource on a planet or moon you will need to select a resource team carrier and move it to the resource node destination. This requires both travel time and then set up. The interface of the game should provide the player with streamlined information necessary to simplify these actions. With the fleet and the destination selected the interface should inform the player of the fuel/time to the destination as well as provide the necessary option to set up the resource station on arrival. All the player has to to is select their fleet, locate their destination and choose the appropriate option. Bang, you have resources gathering!
- further considerations to travel can be taken to provide optimal paths, a selection between the fastest or cheapest route etc etc

However, the idea of additional orbital territory interfaces and attacking sections of planets is something I'm not overly keen about but a feature I wrote in to provide the artists with an are to showcase awesome art, models and particle effects at a closer and more detailed proximity.

---

"Imposing defence condition levels may lock in styles of play or restrict tactics unnecessarily? May be create game play that will naturally escalate progressively. Aggression level set by events, events are not set by aggression level."

These features come purely from the fact that we are appropriating a game called Defcon. Defcon was heavily built around different aggression levels that restricted player capabilities.

It's also important to note that restricting a players abilities does not necessarily mean we are restricting their tactics. The core idea of the Aggression Protocols is to allow the players to set up and prepare for a final offensive through a strict set of governing rules. By providing gates game play the players now what they can and can't do and will inevitably hone into the most efficient tactics and strategies presented by these rules.

As a great example compare Team Fortress 2 to Call of Duty 4. in COD4 the players freedom is almost limitless, any combination of weapons and the multiplayer maps are always very open. In Team fortress players are restricted to the class they chose and it's abilities while the maps are generally very tunneled, leading the player to specific points. While Team Fortress tends to restrict the player more, the tactics are just as highly evolved because players have such a complete idea of the rules they are working with; they know what to expect or how to best gain the upperhand on the enemy etc etc.

This is one of the feelings I am trying to capture.

---

I hope this answers some of your questions. OH yeah and I agree with total destruction being a more dramatic outcome - I'll amend this in the design doco hehe.

I really gotta play the demo of Defcon. I down loaded but have had no time to have a look at it yet. I'm sure once I have looked at it the attraction of that style of game progression will become apparent to me.

My comment on the distances was really a general thought about the potential game play problem of travel between solar systems. The time to travel across a solar system will be negligible compared to travelling between two different systems. I was thinking the game might need a 'excuse' to reduce the distance/time between systems such as hyper-drives and/or worm holes to bridge the gap so to speak... May be a detail that could call into things to consider when looking at types of research can be done during the game or the likes.

more random ideas whilst I'm typing here:
*simplify resources but making fuel, attack and defence strength all tap from the same energy store a fleet has. ie the further a fleet travels the weaker it's attack on an enemy would be.
*Option to increase speed of travel at cost of increase energy usage.

don't know if any of that is really going to help but there it is anyway :)

"My comment on the distances was really a general thought about the potential game play problem of travel between solar systems. The time to travel across a solar system will be negligible compared to travelling between two different systems. I was thinking the game might need a 'excuse' to reduce the distance/time between systems such as hyper-drives and/or worm holes to bridge the gap so to speak... May be a detail that could call into things to consider when looking at types of research can be done during the game or the likes."

Spot on dude, thats exactly the sort of gaps in the game play i was hoping research will hopefully fill. Problem is I can only speculate the kind of issues that will arise from the scale of the game, so I can provide any answers yet haha. It should all hopefully full somewhat into place after some development and testing.

Definitely having an option to increase speed at the cost of fuel is a good one tho. I'll make a note of that.

Ok, got some great feedback from Steve from Infinite Interactive who's had a quick look at the GDD.

Hi Souri,

I've just been having a brief read through your design doc.

It looks very cool, but does have a number of what I would consider very hardcore & esoteric elements in it.
Nothing wrong with that.
The main thing is to gradually introduce these unusual concepts (such as Aggression Protocols) to the player and make sure there is a good (and I mean REALLY good!) set of tutorials behind it all.

My advice on the dev cycle would be NOT to develop the initial maps/systems first (which is often very tempting), but to do them last. Seriously, don't even try to write up the GDDs for the first missions... just leave them blank and revisit them when EVERYTHING else is working.

Writing tutorials is NEVER fun, but a game like this with some new concepts can live or die based on the quality of the player's learning experience.

I'll continue reading and will send you some more thoughts on the design details as I get time to have a look.

Cheers

-Steve

Hey guys I've done a major revision of the GDD for our game an so I've released a new version, 2.0, that you can grab here

Solar Wars: Armageddon Game Design doc v2.0

I took in a lot of the feedback you guys have been posting. Basically I think the scale of the game we want to make is too large, its beyond what we can accomplish. I also respect the fact that the majority of us want to keep this as a portfolio piece rather than a commercial game, so that has also affected the scale and scope of the game design.

I have also had a lot of trouble trying to effectively design a interface system in the game that allows for the artists we have working on the project to develop fantastic looking art while still supporting the large scope of a galaxy. I know there are ways to develop interface systems for this purpose, sins of a solar system is one great example but again, this is beyond our scope.

In light of this I've made the following revisions:

The scale of the game has been reduced to a single solar system. The solar system is divided into layers; with the primary, player owned planets in the middle of the solar system. The primary planets are surrounded by resource planets on the inside and outside of the solar system.

With one Solar system we reduce a lot of the need to scale the interface as much. It also provides a smoother flow for our orbit and resource systems making them easier to play. The entire game can be rendered in 3-D now with players moving around the campaign map easily. This gives our artists a lot more freedom. The interface will still need to scale to support the size of even a single solar system but this should be a lot easier to achieve now.

Previously the design only allowed a 3-d interface when in the orbital territory interface. This interface has been completely removed from the game now as combat should be supported directly on the main campaign map. In its place a smaller, simplified version of a planet's territory has been designed.

Version 2.0 also introduces a more in depth Node system. Nodes are the slots on each planet that allow for structures to be built. These nodes appear directly on the surface of the planet and detail what resources the planet has and what structures are built on the planet. Previously I had thought that the best way to represent the information of a planet would be on a side bar; this system reduces the need for a heavy GUI and an overload of information. It also supports the design of bringing combat directly onto the solar system campaign map.

The last design changes all revolve around bringing the other systems inline with the new systms; such as combat, features and more.

The next design changes will involve a major overhaul of the combat system. I don't think this is functioning to well. In line with this will be a proper write out of the games User Interface.

Any update on the licenses Souri? I'm really keen to get started on building this baby now :D

my head is still spinning from the potential complexity the game could involve. But I generally felt things are refining in a good direction. Does anyone else feel nervous about the scale of the game still? From a game play refinement and programming point of view I suspect the project might still be a monster!

General mind-dump on what I read with ideas/question:
*home planet orbits are very close. On the assumption all planets orbit at different speeds will they pass in very close proximity to each other during the game(!) might this be the agression level 1 event? might this present a game play problem?
*a player based near the centre and a player on the edge of the system might reduce this issue -- and lends itself to an alien invasion scenerio(the GGD is game mechanics focused, a document on story/scenerio might help set some boundaries with things like this)
*6.1 units: the table needs some clarification :(
troop carriers are both a strength and weakness of defence stations? a good way to indicate the defence/attack differences between each ship type might be to make a (bigger) table. List each ship type in the x and y axis (in the same order). In each cell mark down the attack advantage the x-axis ship has against the y-axis ship. This should result in a nice table with some strong patterns running through it and will provide an accurate starting point to test fleet strengths within game play (I suspect).
*to suggest complicating the interface more after you paired it down: I was thinking about the idea of an interactive 3D hologram command map (think starwars where the rebels are planning their attack on the death star) wire frame planets in 3d could be a nice tipping of the hat to Defcon as well.

does that help, hinder? hope it at least fuels the fire of thought.

Thanks for the feedback Chris. I'll try to answer some of your questions and present some of my own.

"home planet orbits are very close. On the assumption all planets orbit at different speeds will they pass in very close proximity to each other during the game(!) might this be the agression level 1 event? might this present a game play problem?"

- This is something that does quite concern me and something I have not been able to accurately solve as yet. There will certainly be times that the planets will pass in close proximity to each other and there are a few potential ways to solve this:

> We can control the speed/starting place of each planet so that their positions during aggression level 1 is balanced evenly - though of course they will still be moving during this phase so they may come to closer proximity. This is a major feature of the game tho, a moving campaign amp that will force players to predict their strategies in correspondence to the location of planets well before they initiate their moves.
> Another way to solve this issue is the really extend the size of the campaign map so that the actual distance between planets is still large enough to not be considered close - this introduces more challenges to the travel time and distances between farther reaching planets.

- The best bet I feel will be to find a balance between these two points and see how it plays out. I certainly want to allow planets to pass each other on orbit and I dont want to hinder the travel times too greatly. This game play problem will really come under scrutiny when we have a prototype in the works where we can see just how it plays out.

"a player based near the centre and a player on the edge of the system might reduce this issue -- and lends itself to an alien invasion scenerio(the GGD is game mechanics focused, a document on story/scenerio might help set some boundaries with things like this)"

- The major reason I went for a three layer planet system was to balance the access each player had to resources. I initially redesigned the solar system to only have 2 layers, an inner and an outer rim. The player controlled planets would exist only in the inner rim while all the resource planets would exist in the outer rim. However, this presented a balancing issue as players closest to the sun would be at a disadvantage to gain resources compared to the player closest to the outer rim. To solve this I introduced the Primary planet layer and split the resource planets between the inner and outer rim.

- The system I designed, is designed to support multiple players beyond a one on one game and what I think you're asking for is to but the point I'm getting from you is to minimize the game to a 1v1 scenario of aliens vrs humans. This is definately a point not to be taken lightly for a few reasons:

>It reduces the scale of our game - making the development process easier
>By limiting the scale of our game to two team multi-player it also limits our opportunity to expand the game in the future. This could also work to our advantage.
>It allows us to create a story driven scenario of an alien invasion giving more depth to the art design
>It also means another major redesign of the game to cater for a two team affair rather than a death match
>Could return the solar system to a 2 layered affair with the alien race occupying the outer rim and the humans occupying the inner rim

So in light of these notes it may be required to redevelop the scope of the game once again. I actually think you're onto something here. By having a team based, alien vs humans affair it still supports all the major game play features but introduces new aspects and depth to the game. I'll return to this point at the end.

"6.1 units: the table needs some clarification :("

- thanks for your notes on this. I mentioned before that the combat chapter will come under a major redesign. I'm not satisfied with the current fleet archetype set ups nor with their abilities so I will take these notes on board when I re-write the section :).

"to suggest complicating the interface more after you paired it down: I was thinking about the idea of an interactive 3D hologram command map (think starwars where the rebels are planning their attack on the death star) wire frame planets in 3d could be a nice tipping of the hat to Defcon as well."

- You've really grabbed me with this idea. However I can't quite picture it. I get the star wars picture but I can't yet appropriate it to the look of this game haha. I've been looking at implementing a semi wire-framed HUD GUI. Perhaps when I've finished documenting that bit you can go over it and attempt to conceptualize and convert the ides further to a 3d hologram style.

So to return to the major point of redesigning the game to support a team vs team combat feature I am going to ask for everyone to reply to whether they support a change like this or not. The more I think about it the more I like it so I'm willing to make the change and I definitely think it supports the artists better while not taking away from the core strategy elements of my design. In essence it will be trading a death match style everyman for themselves strategy to team based combat where each player on each team supports each other. It also means we lose alliances - which I don't mind at all.

so everyone throw your input in for this one!

Sounds like you are across the details that grabbed me whilst reading which is good.
I'll do some concept arty stuff to illustrate with what I mean with a hologram wire frame tactical map.
I had lost sight of the expandibility to include more teams... I actually think designing to leave that option open is a good idea if possible.

...oh Just had an idea for the home planet issues that might be very scalable!:
All players are 'aliens' to the solar system (various races expanding territory). Each player has a Mothership rather than a planet as a starting point. Mothership navigation is decided at the start of each aggression level and travels through the planned navigation during that phase. Players can then choose their positioning in relation to planets and also dictate their proximity to other players for launching strikes, making allies etc. This would work for multiple players and even multiple systems I think.

you sure you dont want to design this game? haha

Thats brilliant! I like it a lot. When you first mentioned alien invasion I had a glimpsing thought of placing the alien race in a mother ship instead of a planet but didn't really explore the idea. It could definitely work but does introduce more complex elements. I'll have a think about it over the weekend write some fresh designs down and see what I come up with. At the moment my biggest concern is whats navigating the mother ships (player or system) and why. I feel confident that these issues can easily be worked through on paper.

Cheers for the idea.

You guys seem to be coming up with some great ideas. I am definitely all for the humans verse aliens idea or multiple races etc. Your mothership idea is looking brilliant. The motherships would allow for more diverse and variable game play experiences on maps which are essential very similar in terms of planet and moon placement. Rather than a player using the exact same strategy when he knows where the planets are going, motherships would add another variable to the map, making the same map almost different every time you play depending on how each player chooses to move. You could probably have a large number of spawn points for the mothership at the beginning of each level that would dramatically change the way the game is played out.

Hey guys,

I picked up Sins of a Solar Empire finally over the weekend and have been having thorough play through of the game. This is a game we can definitely take a lot of influence from in terms of user interface functionality. What I found quite is that a lot of the elements of our game are similar to Sins in terms of functionality while the game play still differs.

I wrote up a bit of a document about it including screen shots of all the major features that I think we should incorporate to a similar style into our game. It should also give a fairer idea to you about the game design I created. What I found most promising is that a lot of the systems I attempted to design are proven to work in sins of a solar empire. The document is pretty large but fairly informal, again feel free to post any questions.

Sins of a Solar Empire Reference doc

Going back to the progress of the design for our game. I started to explore a lot of the new ideas we came up with Chris but ultimately it was just creating more questions I can't answer just yet. I am more concerned now that we have our engine licenses underway with creating a working prototype. That should provide us with a platform to really test our major game play concepts and then incorporate any additional changes.

For now Chris I would definitely aim to conceptualize 2 races. The game will definitely be built around two races to support a whole aliens vs humans scenario. What I would really like to do in the end is actually build all forms of game play that we have mentioned into the game in the form of playable scenarios. So we would have a standard death match map with the players centralized and the resources moved to the inner and outer rim. A team death match of aliens vs humans with the aliens occupying the outer rim and the humans occupying the inner rim. And finally we could also create an additional scenario that uses these motherships we have mentioned. I'm a bit annoyed at myself for not thinking of this earlier when i mentioned how changing these aspects of the game play would limit the scale and expansion of the game haha.

I've actually been looking at Sons of the Solar Empire for art references, they do a pretty good job there too.

Hey hey hey another big update in the works here! Very exciting!

What I have for you today is the preliminary designs for the User Interface.

User Interface 1.0

also added a .rar archive of all the jpegs

User Interface Diagrams

This short doc is a brief of the User Interface section of the main GDD. It includes the overview of the functionality of the user interface; The HuD and the overlaying GUI, a look at how the Planet GUI will work and most importantly it has a story board of the User Interface in action.

The story board also details how a lot of the game play will operate so its good for everyone to read. I'm posting this out first so everyone can have a good read and hit me up with feedback before I finalize the details and add it into the main GDD.

There's a lot of work to be done with UI Souri. My first recommendation would be to organize with Chris N a unifying Art Direction for the game and start assembling the pieces from there.

There is a lot of Iconography for the UI that I'm sure you will need more detail on later but a great place to start would be specific iconography for the fleet types that would work in both the Fleet Listings, Build Menus and on the Campaign Map.

As always hit me up with any questions.