Closed ErikShively closed 6 years ago
JeffreyStrahm
commented
6 years ago The only thing that concerns me is the asymmetry you mentioned as it can make things unfair and the natural change in the environment. It's best to make all changes primarily player driven as changes that occur otherwise can seem random to theme even if you supply the code doing the changes.
Also, do all units share a heat pool? What does heat do?
ErikShively
commented
6 years ago Yeah the other faction was kind of a weak idea and I'm fine with not doing it.
Heat is specific to each unit. It causes systems to work slightly less efficiently and too much will cause the system generating the most heat to shut down. If there is even more heat, the unit will explode. If you wanted to self destruct a unit, you could order all energy away from cooling and Max power to the guns.
JacobFischer
commented
6 years ago Hey, your formatting was weird. Like you had embedded strikethrough characters and anchor links improperly formatted. I was having trouble reading it so I updated your comment to valid markdown:
JacobFischer
commented
6 years ago So standard disclaimer: These are comments to improve your game idea, not a personal assault on you or your ideas.
The terrain set will have very few (if any) impassable tiles, but they will incur other effects. This is done to avoid pathing You cannot avoid pathing in tile based games, it's how you move around. Furthermore even with variable terrain a good heuristic will take that into account. I'm not trying to say this is a bad mechanic, in fast I love the idea of players changing the map, but you can't eliminating pathing algorithms without removing movement as a mechanic.
I really like the idea of managing the inner workings on a machine, however I think there is a problem with information density. If there is a map, you need to render the map and all it's tiles. Furthermore you then need to render each machine on it's tile(s). Then how do you render their inner parts, their heat, and energy? That's a ton of information and there might not be enough pixels on screen to visualize it. This does not mean we can't do this game idea, but if there's so much data that it's hard for a human to understand, it will be hard for the human to write code to play it in 24 hours.
Overall I love the idea of a game where you can fine tune the inner workings of a unit. We had that in MMAI11: Galapagos where you could breed units with different stats based on your play style, and it was well received, so I've love to see it again.
After receiving a huge grant to space travel, corporations have sent machines to space to colonize worlds and to test out the emerging AI and robotics technologies. The goal of the colonization is to gather a new energy source for experimentation. Since there were so many organizations sending out machines, there was essentially guaranteed conflict when two organizations landed machines on the same planet. The new advancements in AI allowed the machines to adapt and hold their own against the challenges that faced them.
Gameplay Abstract:
Map changes over time (By "Nature or by player interaction).Possibly Asymmetrical (Players could choose their faction if it is).Victory Conditions/Base Concepts
The game follows many conventions of a turn-based military strategy game. There are resources that can be used to build units; victory is reached by destroying the opposing AI's key building; there are structures that can produce units and (probably) units that can build structures and units that can harvest resources.
Visual Aid
The Map
The map is a randomly generated grid with each tile sporting some sort of terrain. Certain parts will allow AIs to modify terrain. It can also be modified by certain events (such as a unit exploding or driving over a tile repeatedly creating a flat path that reduces movement cost). The terrain set will have very few (if any) impassable tiles, but they will incur other effects. This is done to avoid pathing but to still keep terrain a very significant factor in play. [Give an example size]
Visual Aid and Terrain List
Units and Parts
Units are composed of parts. Every part is available at the beginning with their base stats. New units can be composed at any time and saved as a blueprint. Unit constructors (or factories for short) can construct any of the blueprints. For the sake of simplicity amidst all of this, there should probably only be one type of factory as any more probably wouldn't add any significant amount of depth for the complexity it adds. There can, however, be multiple factories.
Example list of parts
Systems, Management, and Combat
Systems management refers to things like managing heat from a weapons or balancing power (like Mechwarrior or FTL respectively). Energy is generated every turn and distributed during the turn. The results of the distribution play out at the end of the turn. Certain weapons will need certain amount of energy to fire, and firing them generates a certain amount of heat. Engines can be made more efficient with extra power, and more power generates less heat (you're powering the cooling system on most of them).
If it costs 8 energy to fire a weapon, and 8 is allocated during the turn, the unit will fire at the end of the turn. If less than 8 energy is allocated, then the unit will store the energy for the next turn. If the energy goal is met during the next turn, the unit will fire. If there is excess energy, the unit will fire a strengthened volley. The more powerful the round, the more heat it will generate.
Heat exists as a way to balance excessive energy usage. Each unit has its own heat. Cutting power to cooling systems, overcharging your weapons ending a turn in a warm terrain tile will generate heat. There are three thresholds, and once the first one is passed, the system that generated the most heat will be shut down. Once another threshold is reached, the system that generated the most heat will shut down permanently. Once the final threshold is reached, the unit will explode, damaging adjacent units. A unit could be ordered to self-destruct by cutting energy to its cooling, then maxing energy to the weapons system.
Only the hull pieces of a module take damage under normal weapons fire, but you can dedicate more power to strike specific systems. If a system is damaged, it will generate more heat, work less efficiently, require more energy, and/or shut down completely depending on the severity of the damage. Certain terrain will change the energy cost for firing, targeted firing, or being fired/target fired at; likewise with detection or being detected and with movement. There will be a key at the end of this document for terrain.
Example list of parts and systems
Factories
Factories are handled separately than units, but they follow a lot of the same rules. They have limited customization (cheaper, less efficient generators vs. the opposite) and mobility parts that consume a lot of energy but allow your factory to mobilize.
As with the idea of another faction, if we wanted to go all out on the game, we could add a teching vs unit production (quality vs quantity) system to factories. Factories will have a pool of 5 (5 is arbitrary and can be changed) places to put energy. There will be a randomized (same for both players) energy goal for each value. It is hidden to the AIs As the factory values reach the goal, there will be improvements to unit production or unit stats which would clue the AIs that they are getting closer to the energy goals. Once the goal is met for all values, there will be a significant improvement in unit quality or production efficiency. Then the goals will change. There will be a randomized queue of values to ensure that both players get the same goals even if they reach them at different times. The goals don't change as a player techs, but they will have the same sequence of goals.
Example terrain effect legend