Outpost 2-LIKE game - Community Input requested

[Hooman]

Yeah, that's what I meant.


I sort of feel like the Panther will be underused, much like in Outpost 2. They don't have a clear strong point. They're a medium blend vehicle, which makes them kind of uninteresting. If you have a choice of all 3 vehicles, it's likely a player will choose between fast vehicles or strong vehicles. The middle ground isn't compelling enough on either front. I suppose the weapons restriction might change that a little, though I don't know if that will be enough.

Having a drone that can drop starflares could easily become a bit overpowered, especially if they are mass produced. Maybe nearby exploding drones should kill other drones so they can't be swarmed so easily.

[lordpalandus]

I think it is a problem in general, for most RTSs, from Supreme Commander to Command & Conquer: When faced with the choice of cheap-fast units, mid-range units, or expensive heavy hitters, players will choose either a ton of small guys or one big guy. People generally only build the mid-tier units if they fill a specific role. Such as building a bunch of Hover MLRS in Tiberium Sun, because you can exploit the enemy's back door by sending a group of them over the water. Or, the enemy lacks much in the way of Tactical Missile defenses, and thus sending a swarm of T2 Tactical Missile units against the foe in Supreme Commander will work wonders.

Being that units typically in Outpost 2 are fairly generic; there isn't named foes and it is just the same weapon, just on a different chassis, this will be hard to make medium tanks useful for players. They almost need some kind of special niche that they fit into and thus the player will deploy them if they can take advantage of that niche.

I'm not sure my current idea for Medium Tanks is sufficient. The ways that I could look into making them better is:
1) A sensor suite; being able to detect stealthed light tanks from afar, to prevent ambushes.
2) Artillery; pound the opponent from afar and strip their defenses from them.
3) A second weapon system, such as a Laser, that has shorter range, but fires independently of the main gun. Much like how machine guns on top of modern battle tanks work, providing light fire support.

The simplest solution however would be to just eliminate Medium tanks, and balance the two remaining types with the Bots around this. I'd rather not do this, as I feel with enough effort, Medium Tanks could be made into something special.

---

As for the Bots, I figured that the Bomber Drone would function somewhat like aircraft in C&C. The Drone Factory has limited airfield space and if a Bomber Drone lacks a landing pad, it takes damage over time, until it crashes. I also figured that if the opponent had the proper defenses set up, most of the Bomber Drones could be eliminated before they hit anything important. However, like OP2, it might be best to restrict Bombers to EMPs, much like how Dynamix restricted the Plymouth player to only being able to build EMP missiles.

Not sure how I will balance them further. Anyway thanks for the feedback.

[lordpalandus]

Here is my proposed solution to Medium Tanks.

Summary: Fast Cheap Units and Hard Hitter units are often preferred, because they are used for a Rushing strategy or a Steamroller strategy. Therefore to make Medium Tanks desirable, they now fulfill the Turtling strategy.

When they deploy into artillery mode, this activates a few powerful effects to support this strategy. (Terrains.txt discusses holes and cliffs in better detail)

1) Armor shifts from Medium to Heavy.
2) If deployed ontop of a cliff, gain the cliff's increased ranged distance bonus, but your minimum range is equal to the normal minimum for firing on top of a cliff. Thus, from a cliff, you have a very good range increase with minimal penalty.
3) If deployed in a hole, gain the defensive benefits, and if another unit is being used as a spotter, you gain your normal range boost from deployment and ignore the ranged penalty for being in a hole.

This allows the Medium Tank to serve as an excellent base defender, hitting targets from afar before targets get close enough to the turrets/other base defenses, and also serve a role for long-range enemy base bombardment, to soften up the base defenses before sending in other units. Hopefully this would be enough to make them a very enticing unit to build, for specific strategies.

[Vagabond]

Are you trying to go for a hard-science feel in the game?

It might be hard to explain how hover drones work in a little to no atmosphere environment. There would be not enough oxygen to feed a typical engine (turbofan/jet or even a piston engine for that matter) and there wouldn't be enough atmosphere to produce typical lift off of an airfoil. You might be able to make a story about a super-efficient, lightweight battery to replace the engine on a helo or something, but not sure what to do about the lift problem.

-Brett

[lordpalandus]

Where possible, I'd like to do a hard-science approach, but only so far that it produces a fun and believable experience. Some games take the hard science approach too far and this results in a tedious, painful, grindy experience (ie No Mans Sky). I'd like to put effort and thought into things to make it believable, but will eschew hard science in favor of semi-realism that sounds like it could be possible, but probably isn't if someone crunched the numbers. I may tweak things if people with the hard science backgrounds gives me feedback, but as I don't know anyone with a Bachelors in any of the sciences, I'll have to go by my own personal understanding of how physics, biology and chemistry works (I took Phy, Bio, and Chem 12 in high school, so I'm not totally screwed on this front, and have completed Single-Variable Calculus in University with an A-)

As for the Drones themselves, I was thinking that they used a combination of jet-engines and turbo-fans; Turbo-Fans for hovering in a spot, while jet engines for moving forward. However you do make a good point, that in order to operate in a low atmosphere planet without much breathable oxygen, it would produce unique problems for hovering drones. I'll have to think on drones then...

-----

Also new file: Manmade Disasters! Summary:

There are three manmade disasters that are entirely avoidable with correct player choices. They each provide a sort of risk-reward kind of choice for the player. The three are: Rioting, Containment Breach, and Rain of Fire.

Rioting occurs when you have insufficient consumer goods to meet the entire colony, and then a check is performed to see if a riot results. If one does result, all structures take 10% to 20% of maximum HP as damage over time and you suffer a morale drop as this is a negative morale event.

Containment Breaches occur when a lab that is currently researching something takes damage. The chance of the breach is based on damage suffered + current damage taken. If a breach occurs, you either release a Plague, an Explosion, or an EMP, depending on the research you are currently researching. The severity of the breach is based on Maximum HP of a lab, and thus Advanced Labs are always worse as they have more HP, but also are less prone to them, as it will take more hits before it finally suffers a breach.

Rain of Fire occurs when you destroy an enemy missile or space-stuff with a mass driver or a hunter killer (survivalists). Creates a meteor shower that deals damage over an area, but no guarantee it will be over your base or their base; site chosen randomly.

---

Potential solution to the drone problem:

Bomber Drones have a special fuel mixture that would provide it's only oxygen (much like how thruster engines in a vacuum work to produce combustion-based thrust) but would need to refuel at a Drone Factory. This limited fuel would also limit their attack distance as if they ran out of fuel, they would crashland.

The other two drone types have battery-powered turbo-prop fans for lift. They also have solar panels on the roof to provide some power to restore the batteries (but not enough to keep them airborne), allowing them to field recharge their batteries. Multiple structures would be set up to provide battery recharging, when near a base. They would also have a thruster engine that could provide a boost in forward momentum, but would require refueling at a Drone Factory.

[lordpalandus]

New File: Exploitable Tactics, Summary:

So the two obviously exploitable strategies that I can see could be a problem with my game are swarms of Bomber Drones or Missile Strikes.

Bomber Drones are not directly controlled; you give them a destination and can recall them but otherwise have no control of them. They need a refuel pad at a Drone Factory, otherwise they will eventually run out of fuel and crashland. Three weapon systems that the Survivalists possess can hit Drones (Laser Beam, Acid Cloud, and Lightning Rods), otherwise can be targeted by Meteor Defenses. An observatory has a built-in radar system that will tell the player what the target(s) are of the bomber drones, allowing them an early warning of where they should send their anti-air vehicles.

Missiles are stored in a missile silo under the Spaceport and can be all launched simulateonously, but require a short period between each launch. The observatory will tell the player where the missiles will target and what missile is headed for that area. This makes it very hard to target vehicles and makes missiles only really good for targeting structures. You can destroy a missile with two meteor defenses, or a single shot from the Mass Driver. A single hunter killer will destroy a missile as well.

You can also construct Hunter Killers and launch them into space. These are used to destroy other Hunter Killers or Missiles and doesn't produce a Rain of Fire. They can also be used to destroy Starship Components and Satellites, but this will produce a Rain of Fire. These provide strategic options for dealing with your opponent, whether it is to slow down their starship, take out missiles, or eliminate valuable satellites. If there are other enemy Hunter Killers in space, they will automatically kamikaze with your Hunter Killer if you target a Starship Component or Satellite (but not  defend a missile). So keep that in mind when choosing targets. Hunter Killers will also automatically kamikaze with a missile, as the strategic benefit of destroying one is of great importance. Thus, if you know that the opponent has Hunter Killers, then it would be a bad idea to launch any missiles, at least until you got rid of their Hunter Killers. Hunter Killers are cheaper to produce than missiles, so it wouldn't be a good idea to waste a missile on a Hunter Killer.

Observatories also provide early warning of incoming meteors eliminating the morale penalty (unless the meteor hits one of your structures), shows you what stuff your opponent has in space and allows you to direct your hunter killers to attack specific targets in space.

[lordpalandus]

Been busy, binge-playing the newest Avernum 3 game, so haven't really don't much more on design document stuff, except for a question:

What is people's thoughts on procedurally generated maps, vs fixed built maps such as through a mapmaker type of interface? Fairness wise, a random map could be potentially bad, with distribution of resources or being spawned in an area with tons of disasters, but could make it so that you would have a fresh game experience every time. Whereas fixed ensures fairness, but often takes a lot of time and effort to build the map, but also requires that a mapmaking interface be built to facilitate the creation and modification of a map. What are everyones thoughts on these things?

[Hooman]

Procedurally generated maps when done well are excellent. They add to replayability, and when implemented in a map editor, make it much easier to generate new content. However, it is not a core game feature. It can take quite a lot of work and time to get it right. There's a good chance that working on it too early would cause development to stall out. It's also likely something that would be developed later, as part of a map editor, in stages, before ever making it into the game itself. I'd say procedural map generation should be largely ignored until you have other core game features working.

In short, if you want to make progress on the game, procedural map generation should probably be on your do-not-do list for early game development.


I had a similar thought about medium tanks being used for artillery, though wasn't sure if the idea was well thought out. In particular, what happens if a player spams long range units. This needs to be considered for both offense and defense. You don't want to allow too much turtling, otherwise the game ends in a stalemate. You also don't want too much steamrolling.

[lordpalandus]

Well, if I took my learning from generating maps in my roguelike, I could eschew the work of a map editor, in favor of randomly generating a map. Map editors do take a significant amount of time away from developing the game, as you'd need a GUI and a whole set of controls for the map editor. As far as RTSs go, the ones that offered random map generation, did it from within the Skirmish menu (ie Tzar Burden of the Crown), rather than a map editor.

[Hooman]

Yes, the user interface is nice and simple that way, though it hides a rather high learning and code development cost. Where is this on your roadmap?

[lordpalandus]

The map editor / map maker was not on my roadmap for the development of this game. That would entail a whole lot of work, outside of the game itself, as I'd have to learn how to create an entirely separate interface and control structure for the map maker. I had figured the game would use procedurally generated maps, rather than fixed maps; though if I created a "seed" generator, I might be able to keep specific seeded maps for specific things, ie a Campaign.

[Hooman]

A good idea, yes. Though, how are the maps currently generated? Presumably you have some way to create or store maps already. If so, how does procedural generation of maps fit into your timeline? It's cool, so I bet there is temptation to bump up this feature's place. This leaves me with 2 questions. The first is what does it cost you in terms of other features that must be deprioritized. The second, is if you work on all the cool features first, what motivation remains to do the less cool stuff (which might still be necessary). It might be wise to spread out the fun tasks as little rewards for working through tedious yet important tasks.

[lordpalandus]

My new approach to OP2-Like game has no code yet. Even if I were to use UE4 for it, I'd still need the main rig, which I currently lack access to.

My idea is to create very basic procedural maps initially, just to serve as a testing ground. Then I can look into which path is more difficult; better procedural maps, or working on a map editor. With my roguelike I have more familiarity with procedural generation, but I might like the challenge of creating the UI for a map editor. Hard to say at this point, as again, I need my main rig to do any actual code testing. I might be able write python code, but I can't compile it, which makes it a moot point.

[Hooman]

Ahh right, I was mixing this one up with the rogue-like.

Still, it may be wise to set a timeline for the feature(s). Starting out with just a single hardcoded level is an acceptable way to start.

You might also want to set different goals for different types of procedural generation. Base layer, terrain features, resources, bases/units, disasters, level objectives, etc. An initial implementation might start out as simple as clearing the base layer to a single terrain type, then placing hardcoded items on top. The harder/more interesting features can appear further down your development timeline.

[lordpalandus]

Well, one piece of good news is that I finally got universal c-runtime on my laptop, so I can start coding again.

Well, likely I would start with a very basic level, with just squares and rectangles representing structures, units, and terrain obstacles, for simplicity purposes. I would want to have that kind of angled visual approach that OP2 uses, but that would come later, as I'd want to ensure that the fundamental stuff functions correctly.

Well, as the procedural generation would have to be pretty good, to produce interesting maps that aren't purely random noise, I would definitely want to take time to have different goals to work towards.

[Vagabond]

lordpalandus,

A couple of thoughts on mapmaking.

 - If the map is for non-cooperative multiplayer (like deathmatch), then fairness is probably the number 2 design feature behind being fun. If it isn't fair, people will get upset quickly.

 - For storyline/campaign play it can be difficult to use procedural generation and still fit the story and objectives.

 - How many maps are you looking to produce by hand? Once you have a rough number in mind, you can use that to determine how polished your mapmaker needs to be. IE if you are making 24 maps and it takes roughly 2 hours each to produce, that is 48 hours of work. If you can improve your map editor with a new feature that shaves off 5 minutes per map, but it takes you 4 hours of development time to complete the new map editor feature, then it maybe shouldn't be developed. You are better off just eating the time producing the maps.

 - If you do not plan to share the map editor with others, you can skip a lot of design features in the user interface/commands that you don't need yourself.

 - Procedurally generating maps for a real time strategy game will have several unique and difficult procedural problems that will not be present in a rogue-like. Such as:

   - Managing bottlenecks for groups of units that will give the pathfinder trouble
   - Evening out defensive positions between base locations
   - Ensuring there is enough space between obstacles to build a reasonably sized base
   - Ensuring resource allocation is fair between base locations

Rogue-like games are particulary suited for procedural generation I think because there isn't a lot of high-level concerns with how the terrain runs together. A real time strategy game will be more difficult procedurally because you have to think about how the overall map fits together, which doesn't matter as much in a rogue-like. (Totally my opinion here)

I would try to avoid the trap of designing a GUI from the ground up on your own. It is a huge time sinkhole that doesn't advance your game in the least. There are some generic map editors that you could possibly adapt, or try to use something like note-pad to produce a working map from a .txt file.

Hope that helps,

-Brett

[lordpalandus]

Thanks for the insight in mapmaking, Vagabond.

=====

Updated file: Factions 2

Added a 7th point for their main goals and endgame victory conditions.

Terraformers must build sufficient Terraformers or develop and then control a "Blight"-like microbe to transform the planet. If they manage to do so, the Survivalists surrender to them.

Survivalists must either build a starship and leave, or destroy enough Terraformers to prompt them to develop the microbe, and then sabotage their space program ensuring they are stuck on the planet.