Thanks for the lengthy reply Hooman, I'll try and answer each point.
Yep, and tons more writing to go
I've only got about 10% of my writing up at the moment. Clearly I will need to consider making it less verbose and use fewer words to say more to make reading it not a chore, but I'll work that in as I go through it making changes.
Hmm, perhaps you are right, the game inspiration should be put in an index near the end.
What do you mean by the "context of the game" should be created first before listing inspiration?
I actually don't really know why I sourced the games as inspiration, other than when I see games on Kickstarters that are inspired by X, Y and Z, that I felt that I should do the same. As an example: the game Convoy is inspired by Mad Max and FTL. Though I suppose a feature breakdown from those games may not be necessary.
If you visit the Information Archive, I left an explanation of Tier 1, Tier 2, and Tier 3 there. However, I'll reiterate it here for convenience. Tier 1 (Planetfall) is where you land on a new world, and create your first colony. You have to struggle to survive, battling against disasters and internal strife to maintain your colony. The original goal of Tier 1 was to create a colonization convoy of vehicles and send it out to create a new colony on the planet. Tier 2 (Governance) is where the first colony has thrived to the point of creating another colony, and the need is for a Planetary Governor to control all the colonies, and deal with the logistics of supporting multiple colonies and creating new colonies. The governor would then get the colonies to work together to mutual goals. The original goal of Tier 2 was to construct an orbital space station and construct a new colonization starship to colonize a new world. Tier 3 (Presidency) is where you now have multiple colonies on multiple worlds, and thus you now take on the role of Empire President. You must manage the logistics of multiple planets, colonization of new worlds, and the construction of star fleets. The original goal of Tier 3 was to reunite with Earth, that you lost contact with and see what happened to them.
Yes, I am having some troubles being TOO ambitious with my first project... which is why I broke the game design idea up into the three tiers, rather than design from the beginning to include all of them in the base game. Though... my design may still be too ambitious. As I work through it, I'll likely find things that don't make sense and remove them or figure out a novel way of doing something differently to hopefully reduce complexity.
The name of the design document is after all, Unnamed RTS (Real-Time Strategy)
However, I am aware that putting too many features from turn-based games into a real-time strategy game is very dangerous, as it can increase the computations per second that a player must do to play the game (as described in the episode of Depth v Complexity by Extra Credits). So, I'm trying to only take specific ideas from it rather than the whole idea that wouldn't work in a RTS.
I also do agree, that often ideas do not mix well between genres, however, some ideas do mix well and thus sometimes its worth a person's time to see if something would work or not. I can always decide later that a specific idea is other a poor fit or would take too much effort to try and integrate it.
Well, the concept behind Adaptive Multithreading is where a program runs a "test" to determine how many cores and threads a computer has available, and then splits the work for the game among each thread. If a computer has 4 threads, this would utilize all 4 threads. If the computer had 16, it would utilize all 16. I suppose Game Foundation is a bit of a misnomer; perhaps Game Engine is better? The purpose of this feature would be to interact with the Main Event Loop, and reduce bottlenecks by distributing the work over more threads, so that more powerful machines with more threads could be fully utilized by the game and thus run far more efficiently on their machines.
Yes, I'll take some time when I have a chance to create a mock-interface image in GIMP to give a basic idea of what I intend to go for, once I've nailed down in a more permanent manner how I want the UI to look.
I didn't think of that (camera and minimap). It might not be useful to have a minimap after all then. Though, the only reason I felt that it might be nice is to give a player an early warning by briefly looking at the minimap to see if hostiles were nearby. Though that could also be accomplished by the player actively looking which might be a better use of UI space (as the minimap would eat up a portion of the interface to have it). Thanks for pointing that out, Hooman.
Hmm, another good point that I hadn't considered. It might be better to allow units to occupy whatever space their mesh occupies, while structures themselves occupy a set number of squares for simplicity. I had decide to do both, because I thought that if the structures occupy a fixed number of tiles, then units should as well. But, I suppose it would make sense that units shouldn't be forced into a single tile unless it was because everything was made of 2D sprites.
Yes, I agree that having a minimap filtering option might be a royal headache for all involved; the same goes for overlays for the main view. The intent behind these was to make it so that something was easier to see, by removing other things. Though, if you accidently did enable the filter without knowing the UI, then it would be a chore to address.
For multiple building selection it would depend on the button held that determines what happens. If you have multiple selection and click something, it overrides. If you have multiple building selection and shift click something it adds to the queue. If you have multiple building selection and you CTRL click, you erase everything in the queue, except the unit you clicked on (which may be difficult or impossible). Override simply replaces whatever the factory was doing with the unit clicked on. Addition causes the unit you clicked on to be created after the current unit being built. Selective Removal is where a queue has multiple different types of units in it (ie build tank a, build tank b, then build tank c and repeat) and you want to change it to only produce one unit and remove all the other units in the queue, rather than changing each queue manually.
Otherwise, you do make some good points on multiple building selection that I'll look into and consider. Thanks for suggesting them.
The naming option is there for some reason. Its clearly not something I thought through; I'll remove it.
Well, the reason I had wanted formations is so that all the units move together at the same time, rather than charging the enemy lines as an unorganized mess of units. Its hard to create a good strategy, if your units aren't behaving. The other reason is that the AI player is often not handicapped by the pathfinding system as it moves each unit individually, rather than moving all the units in a large clump with a single order for all the units. The formation idea is to try and overcome problems with any pathfinding system so that it is possible to maintain order and stability with your armies and ensure that a strategy you have can be pulled off. In any game I've played with formations, it is easier to control a large number of units and ensure that they all reach the destination at the same time. This is important for attacking a well-defended defensive line, where if you move in formation, you can overcome the defenses, but if your units decide to go there single file, one at a time, they'll get picked off. Thus I do see formations as a moderate to high importance to the game, as no pathfinding system is perfect and as more events pile up in the event queue, the longer it takes to process commands and thus the more likely units will pathfind single file, one at a time.
I agree AI Assistance could be a major selling point "if" done right. However, I also agree its not a massive priority either.
I like that idea. I agree multiple staging points could be a real burden on a player and be pointless complexity at the same time. It would be better if you could select all units of a specific type with a button click. I believe in StarCraft, as an example, if you double-click a marine, it selects all nearby marines. So something like that could be entirely feasible.
Yes, I like the idea of the rock-paper-scissors feel too. Though, I will need to balance it to ensure that each are powerful against their specific target, but not overpowered. But that's something that can be done later, when I actually have the units implemented to do testing with. The reason I did it this way was because in Outpost 2, hardly anyone would use medium tanks. This way now each unit chassis is important for different strategies, rather than players only using light tanks or only using heavy tanks. Its also so that if a player decides to focus solely on a specific strategy (ie mob rush you with Light Tanks), you could counter it with Heavy Tanks. If that player decided to mob rush you with Heavy Tanks, you could counter it with Medium Tanks. If the player decided to destroy you from afar with Medium Tanks, you could counter them by using Light Tanks. Should make multiplayer quite a bit more interesting.
The specific examples of robot multifunction are listed in the Unit Purpose section. As an example, the Robo-Worker; the Robo-Worker is basically the Bulldozer and Earthworker combined. Or the Robo-Explorer is a Scout and Surveyor combined (got this idea from Outpost 1 as the Explorer is just that, a scout and surveyor combined). Or the Robo-Hauler is a Cargo Truck and Evacuation Transport combined (depending on the cargo currently carried). This is so that there are fewer units that a player needs to learn and reduce the overall unit complexity by combining two units with similar roles together into a single unit.
The population model has gone through about 6 revisions already, and is likely going to be still revised. The most recent older population model was quite a bit more complex which caused the simplification here. The old model was where you had 8 colonist types = Children, Untrained Adults, Workers, Engineers, Scientists, Elderly Workers, Elderly Engineers, and Elderly Scientists. The idea was that Elderly people as they are older, are more likely to get hurt and thus should consume Medicine faster. Similarly Children get hurt easily as well, and thus they consume Medicine faster. I may revert it back, or make further changes. The main reason I had 8 colonists types was because I wanted death to be controllable by the player. And as old age often results in death the quickest, I felt that having an elderly category would be appropriate. However, it does cause a massive increase in complexity in having them. I'm not quite sure how I'm going to address this problem.
The Robo-Constructor can build a kit but isn't required. The purpose behind this is to address three major problems: 1) In initial planetfall, you won't have Robo-Constructors as they don't come with the Starship, and are designed on the actual planet. Therefore, you need a way to deploy structures without having a Robo-Constructor. 2) However, in order to create a new colony, a structure kit would have to travel quite the distance and thus building the tubes all the way there would be prohibitively expensive and thus a Robo-Constructor is needed. 3) Certain structures may be difficult to place via the tube-method, such as Mining Facilities out near volcanoes; the mine itself may be safe from lava, but the tubes will likely get destroyed. However, what this means is that instead of requiring tons of "ConVecs" all the time, you only really need them for initial base construction and the occasional structure off the tube network. However, again, the Robo-Constructor has other functions it performs such as repairing structures and demolishing structures.
Similarly above, initial planetfall means you lack a Robo-Worker and thus you need to construct tubes somehow without a vehicle present. I had thought that the Command Center "may" be a good choice for it as it would be one of the first structures built and thus it could fabricate the necessary parts to build tubes. Now, this doesn't mean that the Robo-Worker is useless when it comes to tubes. The Robo-Worker, can place tubes wherever it feels like, while the Command Center would only be able to attach new tubes to existing tubes, one at a time. Thus time-wise, it would be more efficient to build tubes with a Robo-Worker, than it is with the Command Center, but if an enemy destroyed all your Robo-Workers, you wouldn't be in serious trouble.
Structures do not come with free tubes. This is so that you have more control over placement. I hated in Outpost 2 where I'd want to put my Guard Post right up to a wall, but couldn't because the free tube was in the way.
Basically the intent behind both tubes and structures being built in two ways is to overcome the problem where a disaster or the enemy destroys your vehicles and thus preventing a "soft" gameover as you rely on those units. With two ways, you have options and it up to the player to choose which option is best for the situation.
Haven't figured out tube ownership yet or even what happens if you connect two enemy colonies together.
Thanks again for the input, Hooman!
