Outpost Universe Forums

Outpost Series Games => Outpost 2 Divided Destiny => Topic started by: lordpalandus on August 12, 2015, 03:00:29 PM

Title: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on August 12, 2015, 03:00:29 PM
Hi all,

I am in the process currently of building the Design Document for "The New Terrans". I do not know when I will build the game, but I do have a lot more confidence in accomplishing such a venture now that I've been working on my Roguelike in Python for a while. I am going to do the design document differently this time around. I learned a lot from my previous attempts at it and have taken those lessons to heart. I'll produce individual files first, get feedback on them, and then transfer the finalized ideas to the Design Document.

Here is the preliminary Design Document, with only an appendix of mechanics and jargon that I do not think will change significantly. If people feel differently and want to discuss it, please do. I'd like to create an authentic, but yet fresh approach to Outpost 2. It won't be a 1:1 copy, but I do intend to take significant inspiration from it.

EDIT: Added a last-updated date to the top of the design document. You can use this to determine if it is worthwhile to recheck the document in case anything changes.

EDIT2: Been busy lately focusing on getting my Alpha V12 release ready for distribution, and thus haven't touched the DD or the other files at all for at least a week. When I get the build out, I'll likely take some time to review my files and release updated ones.

Here is a link to the new DD = https://docs.google.com/document/d/1pk5r5mocvam2xEikMXU492cbe290T4YhC2gDh-1SMAE/edit
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Highlander on August 13, 2015, 03:50:55 PM
1) Stick to the over all feeling if OP2. I've always liked the extensive tech tree's of the game, the multitude of buildings and the setting on a desolate planet. Back in the earlier days I always dreamed of a more extensive tech tree, more weapons and more factions. An easier way to make maps and missions would also be great.

2) Various bugs, lack of balance between the two factions, lack of balance to multiplayer maps, poor AI, more single player scenarios, easier to make maps/missions. Probably a bunch more.. I also wish that the research was a bit more important and that several routes might lead to success to a larger degree than it currently does.

3) The storyline I think was pretty unique, I always felt it provided a solid background for what happened in the game. I also liked reading the novella as I went along the missions - though, honestly, my English at that time probably wasnt so good, so I didnt understand all of it (But it was a good read years later). Like previously mentioned, the extensive tech tree and multitude of buildings all add to the realistic feel of the game - and also the research seems more or less bound by science not just free imagination (No super weapons which seem a bit far fetched). I also like that building one building doesnt automatically unlock another building which in turn unlocks 2-4 new weapons - you actually have to research them (and the research has little explanations of what can be expected and also what actually was researched when it was done). I also like that you have to balance both colony and weapons management (and research) - neglect either and you might be in trouble. Also I always felt the music was pretty good, and I always enjoyed the little sounds and animations of the buildings.

4) I havent actually played Outpost 1 o_0

5) -
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on August 13, 2015, 06:56:42 PM
Thanks for the reply, Highlander.

Some additional comments for brainstorming:

1a] For the extensive tech tree, did you find that the short blurb of text accompanying the research topic helped to create the overall feel for the game, or do you think it was an effort that was wasted? Additionally, did you find the extra blurb of text that accompanied the finished research topic (available for perusal if a person wanted to read it) helped or was a wasted effort?

1b] For each building, they had several static animations that played for each structure, with each structure having unique animations. Did you feel that these added to the overall feel or were simply a nice novelty or added touch... or possibly all of the above?

1c] Which structures did you like the most, and why? Any structures you felt were useless and any idea of how to make them useful? (I don't know about you, but for me I found the Light Tower to be basically useless)

1d] If there was more that you had wanted the tech tree to do, what would you have wanted to add to it? For example, something simple like additional numerical upgrades (+HP, +Armor, +Speed, +Damage) to specific units, or something more complex?

1e] Well with UE4's Cascade Particle Creator and Editor, creating new and interesting effects shouldn't be too difficult. Were there any particular kinds of weapons that you wished the game had, and lacked?

1f] For easier map making, would having simply a Procedural Map Generator, that creates maps based on mathematical algorithms be sufficient, or is direct manipulation of terrain and objects preferred?

1g] I'm not aware of the difficulties of creating missions in Outpost 2. What are some of the hurdles facing mission creation?


2a] Can you list of some specific bugs, that for example the unofficial patches haven't fixed yet?

2b] As for the balance issues, I had considered (still a bit WIP on the numbers but...) that Penetration Damage fully penetrates armor, while Concussion damage deals extra damage to None or Light Armored targets, while very little damage against Heavy Armor targets. Do you think that this is a good way to manage the two damage types. Thus in early game, Concussion would deal more damage, but mid-late game, Penetration would deal more damage. Do you think this would be an amicable solution for the disparity between these two damage types? Or perhaps, having only two Damage Types is the problem? Thoughts?

2c] Besides Weapon Balance, was there other balance issues between the two factions, Plymouth and Eden?

2d] Do you think mirroring a map would solve multiplayer imbalances, or could you elaborate further on this point as to multiplayer's issues?

2e] The AI is definitely a sore issue of Outpost 2, being that if I recall, the AI wasn't really an AI but just a preset set of tasks that it always implemented in the same order. The AI system for UE4 is fairly extensive, especially if one uses the Environmental Query System (EQS) for the AI. Is there any specific things that you wish the enemy AI could do?

2f] On the same note, is there anything you wish that as a player you could do to improve your  own unit's AI. Or do you feel that the only problem with player controlled units is there pathfinding ability?

2g] For the research tree, would you have preferred a research tree where you could choose several paths that could lead you to the same destination (so Dual Weapon Systems could be unlocked for researching by researching any of the three techs = Reinforced Vehicle Construction, Reinforced Turret Construction or Advanced Vehicle Plant), or did you prefer the research tree in Outpost 2 where you had to research specific prerequisite techs before unlocking the ability to research more techs? (I might have explained this poorly, so I'll clarify when a larger example if it isn't understood)

2h] Quote "I also wish that the research was a bit more important and that several routes might lead to success to a larger degree than it currently does." I don't quite understand this. Could you elaborate further please?


3a] The storyline was definitely unique as this is the only game I've played that has done a story in such a manner. It wasn't forced on the player, but it provided a lot of insight into the background game by reading it. Do you feel that having all the story concentrated in the Novellas was a good thing, or would you have also enjoyed it more if there was more story in the actual campaigns as well?

3b] The fact that the research did seem to be ground in realistic fact I would say helped a lot to add to the game's realism for me. The only issue I have is how would someone such as myself find the appropriate information on technologies ground in realism? Read extensive scientific journals? I personally don't know where to begin on this point or how I would go about researching that kind of information. Thoughts?

3c] Yes, I agree the whole C&C way of unlocking techs and buildings by creating a building always confused me too. However, are there any structures that you can think of that would work well using this kind of system (ie You build a building and it unlocks other buildings to be built or possibly a building that unlocks additional research that could be researched)

3d] Did you feel that the balance of combat and colony management made Outpost 2 the game it is? Or did you feel that one or the other felt tacked on? Or perhaps that one or the other didn't feel as deep as it could be, without being needlessly complex (ie Air/Oxygen Management might have been a pointless complexity, but what about Water Management... especially for Hydroponic Food growth in Agridomes?)


4] No worries. Neither have I, but from my brief reading of a few reviews of it, it seemed to have some interesting ideas to it, such as getting to choose your own planet, rather than being forced to choose New Terra.

5] Also no worries. Nothing has been heard from that development team in months since the kickstarter failed and the only two reasons I heard that they might have failed was because the developer was arrogant (though I couldn't figure out how he was arrogant) or that they barely posted on the kickstarter, which also doesn't bode well for a kickstarter (but is easily remedied; post more often and be more active).
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Highlander on August 14, 2015, 03:49:00 PM
1a) I think it added a bit of realism. Often the research text add's a little something to where the technology is coming from, rather than being just a topic to research with a resulting new & unexplained technology when it's done.

1b) I think it adds to the overall feel - your colony becomes more than just static structures on the map. It probably isn't necessary for the game, but it's one of those things, that for me, makes OP2 a nice game..

1c) Spaceports! They just looks cool. Otherwise, Im a Eden fan, more than Plymouth. Plymouth GORF, Forum and the MHD Generator looks good though. Eden structures that I think looks good/cool are the Observatory, Meteor Defense, University (looks like a normal uni), EMP/Acid/Rail Guard Posts.
Recreational facility/Forum's are pretty useless - if you dont research them, they dont screw up your morale.. Plymouth Solar array is pretty useless.
Light towers are also fairly useless, unless your aim is to create a nice looking base..

1d) I dont have anything specific I guess.. It always feels a bit empty when you complete all research options. I guess one could add more structures and units to the game that could be researched, but eventually you would always run out of options for things to research I suppose. I think it would perhaps be more interesting if the tech tree provided several routes to success (Right now on the weapons front you either rush for advanced weapons or you go with increased armor and ore improvement and fight with initial weaponry).

1e) I once had a list with many weapons imported from other games - which I thought would have looked nice, but I've forgotten most of these im afraid - only one i can remember is some sort of artillery (very long range weapons), which would come in handy if you need to break open a well defended position.

1f) When considering map-making I always found the map maker that went along with 'Heroes of Might and Magic 3' very simple and userfriendly.

1g) Like maps, they require some coding I believe - I lack knowledge here and someone else can probably describe the process better.

2a) Bugs is perhaps the wrong word - weak features of the game is perhaps a better term. From top of my mind: If you in a campaign or scenario blow up all your weapon units, the AI will only send a tiny force against your base. Differences in ore in multiplayer maps - a 2 bar is not always the same.

2b) My approach would perhaps be differences in research to the two - like upgrades or duration of each research topic, or different cost of units. Though a more careful balance of the two damage types might also work well.

2c) Eden can have near perfect morale with the Consumer Factory.

2d) Precise mirroring is not necessary, but placement of base vs placement of ore on the default maps could be really horrible. The same could be said about random ore placement - like 1 base area on say La Corrida could in 1 corner hold several 3 bars, while in another corner there was 1 guy who had to live off a 1-bar rare ore. Another thing with the default maps, is that many of them has 1 really good base area, while leaving the rest of the map less defended (Around the World - fortress in south below the "arena"). This could be solved by playing Landrush, but starting points and availability of well defended bases agains comes into play quickly.

2e) React to the human player(s) - not just run off a script i guess. I also much prefer to fight against a physical enemy (base) rather than only having raiding parties coming in from set points on the map. And maybe not have the AI cheat in the same way - unlimited ore and what not. Possibly a lot more to add here

2f) Pathfinding seems to be main weakness. Though with a RCC, much is improved. Just avoid locking up Cargo Trucks on mines/smelters.

2g) I think I understand, and I'm not sure. I think it could work somehow, but some lines of tech should be sort of specific I think. Depends on the topics - in real life people might arrive at conclusions following different paths, but the research should be logically connected somehow.

2h) With this Im trying to say I wish there were more ways to victory. As it stands, it pretty much pays off to follow 1 path of research (For both colonies, but particularly Plymouth) -> Get advanced weapons asap. Only available alternative is to get ore processing and advanced armor and spam micro lynx instead of costly advanced weapons. I would like to see more alternative routes in this setting.
As Eden you pick either Acid Cloud or Thors hammer - another division point in the research which require time and alters the play style used. (If you have a 3 bar rare easily available, it pays off to go down the Thors Hammer route, if rare is a 1 bar then Acid Cloud might be a better option)
I guess if Research had a few more steps involved and took more time, this type of strategy would come more into play. Right now one can see a bit of this, but it takes only a short time to cover all weapons. I think it would add more to strategy if you had to spend more time and effort getting to the endline technology/weapons and getting each would be more of an investment. Then adapting your strategy to your position in the game/map/resources/opponent would have more depth to it.
- If this makes it any clearer ? (This also goes for civilian research/technology, where for instance Medical Centers and Consumer Factories can really pay off in some gametypes/setting)

3a) Retrospectively, I would have loved to have the gameplay more tied in with the novella - though without making it locked too hard in place. Maybe have a 2-3 places in the story line - where the players choices or scenario outcome sort of dictated the future novella/storyline. That could perhaps add a bit to replay value - so that you would check all options sort of ?
That being said, not everyone has been into the storyline, so perhaps keep it a bit in the back ground.
I would also have loved to see a short intro/exit video specific for each mission in the campaign - perhaps even a brief something for the differen scenarios ?

3b) The realism of the research certainly adds to realism of the game. Where to find it though ? One would have to look into papers or research articles maybe ? Interview some experts ? Probably quite extensive work either way hehe.

3c) The Basic Lab / Standard Lab / Advanced Lab system seems to work ok - maybe add some more interactions between the 3 ? Where one research in one lab would spark new topics in the others - not just standard lab -> Advanced lab. Maybe some "test facility" would be necessary for some research just to give an extra example..

3d) I think here is the beauty of the game - that it allows you to play with steady morale, which makes it alot easier for action hungry players to duke it out in a matter of minutes. While if you turn morale on and add in Day and Night, then suddenly there is some extra depth to the game.
I think both O2 and H2O management (And possibly other systems) might have it's place in a game such as this, but I think it would be good to have options to automate these, so that the players that looks for the RTS action might find that, while those that prefer a slower pace and more depth of strategy might find that as well if they wish.
(As it stand, if morale is turned on, then rushing weapons is still a viable strategy. But if maps are large and a position is easily defended, then rushing for weapons will leave you with lower pop, and if the other player instead focuses of pop growth and colony management, then suddenly weapons rushing is not a winning strategy any more)
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on August 14, 2015, 07:44:07 PM
A major reason why I am looking for community feedback is because I know from lessons learned over the past several months that just because I've played a game for a long time doesn't mean I will be able to notice every single detail. As an example, back in April-May of 2015, I had been designing an RTS using Majesty (A base-building sim, with indirectly controlled heroes) 1 as inspiration. I had thought that since players lacked a lot of ways of managing their heroes, I felt that if the base-building aspects were removed so that the player could focus entirely on managing the heroes (as managing heroes and trying to motivate your heroes to defend your base could be troublesome). So I had designed out basically every feature for that game idea by the start of June 2015. However, a few days after I had finished the Design, I ran across an old forum post discussing Majesty 1 and made a startling discovery. Apparently, the aspects that players loved the most about Majesty 1, was the base building aspects and absolutely hated the indirectly controlled heroes, many wishing they could have directly controlled the heroes instead of indirect control. It was mentioned that they don't like having the illusion of control and that if they had to deal with indirectly controlled heroes without the base building aspects, the game would have been a boring game rather than a cult classic. Thus I realized at that point, the game I had designed would unlikely sell and discarded that game idea. I learned much from that mistake, and at the time after learning this I switched gears to go for a RPG instead (which was most of June, all of July and part of August, with in August realizing that I don't really enjoy the RPG genre as much as I had thought).

This is why I want to engage the community NOW, rather than put a lot of effort into the design and then ask.

Now as for the game idea itself, the game will be designed into 4 tiers (tier 0 - tier 3). At each tier, the player can play the game basically like Outpost 2 is played; you control the aspects of a colony on a single map, managing resources, morale, people, disasters and likely (I haven't yet figured out the enemy yet) combat as well. (Bit pressed for time, but I'll explain these in greater detail later) So the tiers:

Tier 0: (Planetfall) = Here you take your colony ship and pick a planet (or one is picked for you; undecided at this point). Then you pick a landing zone to land your colonization convoy. You then, take your convoy to any point on the map (each landing zone is a separate map) and you deploy the convoy into temporary structures.

Tier 1: (Colony) = Here you have a colony with all fixed structures, just like in Outpost 2. This tier plays almost identically to Outpost 2.

Tier 2: (Planetary) = Here you have multiple colonies throughout the entire planet. You can leave a Local Mayor AI in charge of each Colony, which each Colony being in separate Zones on the Planet. You can of course go out and create a new colony yourself, or leave the AI to do this kind of work and instead doing the tasks of the Planetary Governor, that oversees the entire planet.

Tier 3: (Empire) = Here you likely have multiple planets, with a Planetary Governor for each Planet, with Many Local Mayors for the various Colonies. You can take on the role of A Governor, Mayor, or the Empire President, while AI handles all the others (The AI will be designed to handle each role).

Now, I don't intend to build all of these at once, but, I did intend to get a prototype put together dealing with Tier 0, and part of Tier 1 and then going to look for Funding, to fund the rest of the development of the game.


1a -> 1b) Thanks!

1c) I found that to be the case with basically all of the Morale-based structures; if you didn't research them, they didn't screw with your Morale. Though, the structure that always made me curious morale wise, was the GORF. Without one, you get a Morale Penalty, but with one you get neither penalty nor benefit. Here is a question though, did you find Morale was easier to maintain once you had recreational facilities / forums than if you didn't have them researched at all?

1d) I felt that way with the Tech Tree as well; once you finished all the topics, it did feel empty. However, at the same time, I've seen some games like Alpha Centauri try to get around this by having a research topic that could basically be researched as many times as you wanted, but none of the times it was researched provided any benefit. Preferably, I'd prefer a research topic like that to provide some kind of benefit, but I'm not entirely sure what. Maybe "a leaf" could be taken from what online browser-based games do (like O-Game) where you have topics like Energy Research which provides a benefit of +10% power production, and it could be researched as much as you like, but takes progressively longer to complete with each iteration completed.

Would you prefer to simply have a longer tech tree, or an infinite research topic like in Alpha Centauri with no benefits, or an infinite research topic like in O-Game, or preferably a bit of all of them?

As for sticking for low-end firepower over more powerful weapons, I think part of that problem comes with the fact that Microwave and Laser are both immensely cheaper to produce, and the more powerful weapons often requires a lot of Rare Ore, even at Lynx Level, and thus you could produce 2-3 Laser Lynx for the price of one Thor's Hammer Lynx. The Thor's Hammer might deal more damage per target, but it is more likely the 2-3 laser lynx will destroy the Thor's Hammer Lynx faster, and thus are more economical. I think there are a few ways one could balance out these kinds of weapons, but I doubt it would be possible in Outpost 2. As an example, for Thor's Hammer, the Lightning Arcs, and hits additional foes near the initial foe, for say 50% of the damage dealt to the first foe. Or Railgun could penetrate a target completely and hit a target directly behind it for the same damage. Or Supernova could knockback any foes not destroyed by the explosion quite a distance (and thus break up a vehicle formation, in addition to damaging vehicles).

If weapons did more than just damage, and had after effects, that the initial weapons didn't have, then people might prefer the advanced weapons over the less advanced ones. Though, a Laser Lynx rush at the early game when you lack defenses could still be effective.

1e) Well, I've created a long list of various weapons from many different games myself, and I'll readily admit that there is a lot of interesting ideas from other games that I too wouldn't remember offhand. If any do come to mind definitely mention them. Now as for the artillery weapon, I think that could be possible if it had a minimum range and thus faster units could get close to it and destroy it (much like a Howitzer)

1f and 1g) Thanks!

2a) I didn't know about the fact that destroying all your turrets and vehicles with weapons caused the enemy to send a smaller attack force. That is a very interesting point. A design oversight perhaps where the calculation to determine what size of attack force was based on how many turrets and vehicles you had. Personally, I'd have the attack force size designed based on how many resources you have stored up, more so than how many attack-ready units you had. Though... that would require coding in stealing mechanics as if they were raiding you based on your stored resources, then they'd want to grab those resources in said raid. Hmm...

As for the Yield, if you look in I believe the Mines.txt (in Sheets.vol) you'll notice that each yield has 3 different possible outcomes for the 1 bar, 2 bar and 3 bar. As for getting around that issue, I had considered using a system like in Earth 2140, where you could put a mine wherever you wanted, but based on where you put it determined if you got resources or not, and how quickly you got those resources. I had wanted to create a system where you could set a mine anywhere, and based on where you put it would determine your resource yield. I also considered having the Surveyor and Scout unit merged into a single unit and use it to determine where resource rich areas were. Still a WIP on how the player would know what areas are better or not (ie color-coding specific areas) and if the yield was variable like in Outpost 2 (where it initially goes up, reaches a peak, drops, until levelling out)

2b) Well I had considered having multiple labs all working in tandem to research a specific topic... which would be more frequent in Tier 2 and Tier 3 (as mentioned above), though it could be done in Tier 1 if you had the scientists and the labs.

I had also considered for the two damage types to expand them further; concussion damage applies a slowing effect on the target based on damage dealt compared to their maximum health in a slowing percentage for a few seconds (ie if dealt 100 damage to 200 max hp, would be 50% slowing effect) and penetration damage causes the projectile to penetrate the target and hit any targets in a line, dealing damage based on 50% of the previous target in damage (ie so if you dealt 40 damage to the first target, the second target would take 20 damage, and the third 10 damage, etc). Does that sound like a good idea, or more likely needless complexity? Or perhaps the complexity would be best suited to individual weapons over giving that advantage to all weapons doing that damage type?

2c) Good point well made. Its funny, because I thought Plymouth should have had that factory as they were the ones better at managing morale. Though, as Eden was the more technologically advanced group, I would have also thought that they would have utilized Arachnids moreso that Plymouth would have as the Arachnids seem pretty technologically advanced compared to wheeled units. Hmm...

2d) Fair Enough.

2e) Yes, I'd also want to be sure that any rules the player must abide by, such as storage of resources and research times, the AI should abide to as well. So the only way they'd be able to build a building is if they had it researched already and had the resources.

2f) Would it be even better if pathfinding wasn't locked until having the RCC or do you feel the RCC should remain (ie it's pathfinding improvement should be kept)?

I'm assuming by locking cargo trucks on Mines and Smelters, you mean that if you have too many in a route then they have a major traffic jam resulting in no one getting out of the smelter and none getting in?

2g) Fair Enough.

2h) Alternative victory conditions are always nice to have.

I also agree that if you need to spend a lot of time getting to something, that something should provide a return on your investment. Overpowered weapons can be a nice return on investment, as long as they aren't too overpowered. Or weapons with additional features that lower-tech weapons don't have.

Part of the reason I wanted to break the game into 4 tiers, is because I want specific research to take longer, and to address the added length, you need many labs all working jointly towards a goal. Like in today's world where many labs all over the planet are working on a cure for cancer. And of course, if you have multiple labs, you'll need multiple colonies to support those labs and such forth. The farther in the Tiers you go, the more rewarding each new Technology is, but each takes more time than the last.

Yes thanks for clarifying your points. Much clearer now. If I missed something though, do mention it.

3a) That might be hard to do if the player was forced to read the Novella to be able to make those decisions.

However, the player could be given specific choices during the campaign that would affect which parts of the Novella are readily accessible to the player. As an example, say you have two choices in Mission 3. Each choice unlocks a different Novella for perusal after the mission is completed. Thus if you chose the first choice, Novella 3a would be available. If you chose the second choice, Novella 3b would be available. Then, at Mission 6 you again have two choices. This would mean that there would now be 4 different Novellas (since there are two choices in Mission 3 you have to account for those paths as well) so: ac, ad, bc, bd (where a and b are the choice paths for mission 3 and c and d are the choice paths for mission 6).

After you complete the Campaign, all the remaining paths could be unlocked, so that the player could find out what would have happened in the Novella if they had chosen a different path OR like in many Visual Novels, those Novella paths could remain hidden until you redid those missions and chose the different path. Thoughts?

3b) Yeah, I'll definitely think hard on that. If I can't figure out how to find that kind of information or if it might take too long to research it, I might do what most developers do and try to make it sound realistic when in fact you likely have no idea what you are talking about.

3c) Well, as for this, I had considered three ways of continuing to use these labs:

1] The Lab could be used to work in conjunction with the University to reduce training time, as some practical experience in a lab would likely be a greater learning experience than just classroom work.

2] Scientists in a lesser lab could research safer components of a more advanced topic in their own lab and add research data points to the primary lab researching it, or help out in other ways such as data recording, or performing statistical research on the data to help the other lab out. So this could provide any scientist working in the lesser lab could provide 50% the research data as a single scientist in the primary lab (ie The Advanced Lab is researching Dual Weapon Systems, which I believe requires up to 18 scientists; The standard lab, could host another 18 scientists that works with the Advanced lab, where each scientist in the standard lab provides 50% the benefit of a single scientist working in the advanced lab, so effectively, there would be 27 scientists working on the project (18 * 50% = 9 effective scientists)).

3] My tiers would have labs of the same kind working on the same project together. So say three Advanced Labs could jointly work on Dual Weapon Systems, while two standard labs are working on Reinforced Turret Construction.

3d) One poster from a while back (I can't remember which or which post it was on) felt that the game is best played as a game where you micromanage things and felt that automation would turn the game into a macromanagement type of game and thus defeat the core mechanics of the game and turn it into something it is not. Thoughts?

Personally, I'd think with automation, it would allow the player to micromanage the things they wish to micromanage, while the things they don't want to micromanage could be handled by the AI. As an example, if people loved micromanagement so much, then they shouldn't use the cargo truck mining route. If a player had to manually send the truck to the mine and back to the smelter and back to the mine always, they'd have no time to micromanage anything else. Thus, I do feel that automation is necessary... but how much automation is too much... or is there too much?

To elaborate further on this point, there is a game called Tzar: The Burden of the Crown. It has a unique feature called AI Assistance. AI Assistance has 4 options: Off, Economy Only, Military Only, or Both. When it is turned on, you can always still grab any unit and have it do whatever you specific want it to do. However, the assistance provided allows you to say run an economy, while the AI builds up a military and sends it off, allowing the player to focus entirely on the economy without fear of being attacked because they aren't working on the military. Alternatively, the AI could be left in charge of the economy, while the player goes out and attacks the enemy. I feel that a similar feature would work well here in this game as well.

Because, lets be serious, if an enemy is attacking your front door, you aren't going to be able to micromanage your economy, building more units, repairing structures and attacking the enemy with any semblance of tactics all in real-time without some amount of AI Assistance. Thoughts?
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on August 16, 2015, 10:54:19 AM
Wow, that's a lot of writing.

Best of luck with this.

I always liked the sombre mood of being at the edge of extinction. It was almost comical in a way, like the victory message "You have done well, our colony is surviving". It wasn't quite Marvin the manic depressed robot kind of comical, but it was good.

A few things sometimes annoyed me about Outpost 2. One was the excessive amount of management required. Having to set mining routes took too many clicks, and never seemed to provide any real benefit for doing things that way. Factories and labs had no queueing system. There is no point having scientists do nothing once they finish a research topic, so why not have them automatically start on the next? And why is research progress discarded if you switch research topics? Why not just put the progress aside for when you continue on it. It's not like scientists would burn their work if they had to switch topics to work on something new. Similarly keeping factories producing was near impossible if you had something else taking up your attention, like a battle going on on the far side of the map.

A few things in the game seemed to serve no real purpose. It probably would have been better to not have them. Like supernova and starflare guard posts. Light towers were also pretty useless. Robo surveyors were useless once mines were surveyed. Scouts had little purpose other than self destructing. If you could steal research or something it might have been cool, but likely that would have upset game balance, and doesn't always make sense when your opponent is a different colony with a different research tree. Panthers were too middle of the road to see much use. They didn't do anything unique, they weren't the best at anything, nor did they provide substantially better value than the alternatives. Forums and recreational facilities were a largely pointless distraction. Don't research them and you don't need them. It was easier to manage morale when you had one less factor that could affect it.

The arbitrary mixing and matching of chassis and turrets didn't seem to work out that well. Maybe restrict the mixing so it made more sense. Self destruct options for Lynx only, heavy weapons for Tiger or Panther only. And do you really need Laser Tigers?

I liked the comment about merging the Robo Surveyor with the Scout. That makes a lot of sense. It's still a bit of a useless unit though, that is likely to just sit around doing nothing most of the time.

Robo Dozers seemed a bit pointless, especially since a Convec would auto doze any area it built on. They weren't completely useless, and I guess I did sometimes enjoy using them. The Earthworkers took too much effort to manage. They could only be told to deploy relatively short lines of tubes or walls. They also only let you build in a straight line. It would have been nice to specify an outline for a wall, and they'd just go build it, and possibly maintain it.

The cliff hugging path finding sucked. Having the RCC was a neat idea, but I think removing the pain altogether might provide a better player experience. I'm not completely certain on this one. I think pain is not synonymous with challenge.

Having to manually load Convecs, and then once they were finished loading tell them where to go and deploy a kit was a slow process. You sort of had time to do something meanwhile, but then you might forget to come back, or you might be delayed completing a build command. I didn't mind the process so much as the user interface for directing the behaviour.

Running out of tech to research kind of sucks. I liked how in Civilization you could research future techs that would add to your score. It didn't really do anything, but it at least kept that aspect of the game alive indefinitely.

The novellas were fun to read, but they didn't seem to integrate with the game very well. Switching from playing to reading then back to playing was a bit strange. I sometimes felt impatient trying to read through the novellas between missions. I was eager to play, not read. Or if I was reading, I didn't want to interrupt my reading to go play. Also, the story didn't much affect how you played, or necessarily tie in all that closely. I enjoyed the novellas, it was just a little strange how they integrated into the game.

I guess my thoughts are, every aspect of the game should have a purpose. In the case of Outpost 2 there were many things that didn't seem to have much of a purpose, or at least didn't tie in very well with the rest.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on August 16, 2015, 02:35:42 PM
Thanks for the reply Hooman.

And yes thanks for the wishing for luck; I know it is a huge undertaking, but I've been preparing for the long haul and that it will likely take me at least a year to fully complete... with funding and hired help; longer without. Thus why I intend to build a prototype and use it to look for funding. If that prototype fails to acquire funding, then work on it quite a bit more, learn from the funding drive mistakes, and try it again later; why try again later? Sometimes a funding drive fails because you neglected one or more details, or the word didn't get out as well as you hoped and thus it didn't get enough people coming to see it, and thus invest in it. Or they might think it looks too crappy and thus you need to spend more time on the visuals. Generally, there is reasons for a Kickstarter, or Indiegogo failure and thus learning them and learning from them will increase the likeliness of success. Though, I think the biggest hurdle in a funding drive would be to prove to possible investors that you aren't like so many other developers with great ideas but cannot implement them or developers that have an idea that isn't well thought out. Some ideas might be very good on paper, but not really all that fun in game and all games need to be fun to play them; some games like Dark Souls are fun because the challenge and overcoming the challenge is fun as an example of a game that some might not think is fun.

Some comments:

You know, I also liked that comment at the end of a mission too, and I totally forgot about it. It does add a really nice touch, and it adds a bit of urgency to the game as you know that taking too long could mean a Volcanic eruption going through your base, or the Blight catching up to you. Ah, good old Marvin, the manic robot; I think I preferred him in the original movies, rather than that more recent remake (I've not had the chance to read the books yet though... though I also can't find them either).

Yes, the excessive amount of micromanagement is something I do want to address in the game. Some micromanagement is good, but realistically a player can only micromanage one thing at a time well, and not micromanage anything else while they are busy; the AI on the other hand isn't hampered by this and thus has a massive advantage on the player. Even the easiest AI will be able to manage multiple bases, units, and constructions while the player is stuck micromanaging one thing.

For the mining route, something similar could be done here like in C&C games. When the Smelter is built, cargo trucks could head to the nearest mine, grab resources, and bring them back to the nearest Smelter. Any cargo trucks that are idle at the time of the Smelter construction, would have to be ordered to a Mine, but after that would go to the nearest available mine. Or just simplify it down to two clicks (one to mine and one to smelter).

A queuing system is definitely desired for both factories and labs; having to micromanage these is a real pain, as I found for myself that I would forget to reassign them to a new task. I liked how in games like Alpha Centauri and Civilization that would prompt you to change the project the moment it was done, but I don't think a system like that would work too well in a RTS (as the popup or whatever it is would likely break immersion and your concentration). But, maybe have a "tick" report that tells the player when their queued job has been completed, or the Savant AI telling the player when research queue or production queue is completed.

That is a good point about scientists throwing away good research if you switch topics. I didn't remember that. Thanks for bringing that up. I see no reason why people would throw away good research, unless of course the notes took up several TB of information on their harddrives and they ran out of space. Though, even in that case, why not use things like storage discs to store it in that case as Backups.

I concur that supernova and starflare guardposts severed no real purpose, other than to discourage foes getting too close to them; it might have been different if they had a mechanism that could be used to fling their explosive device on say a catapult mechanism as a one-use guard post and then the guard post is heavily damaged afterwards (repairing it give it a new explosive device). Though, this would be needlessly complex.

I also found Robo Surveyors and Scouts to be useless. Especially the Robo Surveyors once you built an EDWARD satellite (I always wondered what that acronym stood for). Scouts might have been more useful if they had twice as much vision range or that the minimap radar didn't make them basically useless as you could see all enemy movement on it.

I also concur that Panthers didn't get much use from me either. The added Rare Metal cost, coupled with their lack of mobility compared to Lynx, and their lack of firepower compared to Tiger, made them a fairly useless unit. I've been thinking of some preliminary ways of making them more ideal to use, but many of them are still WIP. Also, I don't know if it is a coincidence, but the naming scheme for Tanks in this game followed the same naming convention the Nazis used to name their tanks. The Panzers, are roughly translated as Panthers, and the Panzer VI and VII, were known as the Tiger Tanks.

Good point on the Recreational facilities and Forums. I had thought that with them active they made things easier, but it seems that the reverse is true; if you don't research them then they have no effect whatsoever. Would a good way to make them useful would be to cause them to have a larger effect on morale and thus justify their value to the player? (ie You'd think that recreational activities would make people happier than no activities)

I personally found the Self-Destruct option fairly lackluster. I'd think that the higher the maximum HP of the unit, the more damage and the larger the radius of the damage effect when self-destructing. And then add in the starflare or supernova that could have their blast radius and damage increased based on this formula. Thus even though a Tiger Supernova is really slow, it's regular self-destruct might have the blast range of a Starflare and the damage on one, but coupled with the Supernova effect, it's blast radius could be as large as an EMP missile's radius of effect. I also found it was fairly lackluster because if you destroyed a unit, you'd expect it to cause the same damage effect as if it had self-destructed (thus destroying a Tiger in a tightly packed Tiger assault column, might heavily damage all the Tigers if one is destroyed). Thoughts on this? (The idea for this is from a game called Dark Reign 2, where the Sprawlers basically had a Nuclear Bomb on Treads, and had about the same blast radius of the one I just described)

Interesting point with having Lynxes with less powerful weapons, and the Panther/Tiger with only more powerful weapons. That would keep Lynxes as a good early game unit, or stopgap for an enemy assault, but prevent you from spamming Thor's Hammer or Acid Cloud Lynxes. While at the same time, avoiding weak weapons on Tigers and Panthers. For me, I actually loved Laser Tigers, as one with the Firing Speed upgrade could obliterate an RPG Tiger or a damaged Microwave Tiger.

Well, for my idea for the Scout change, they would have the highest visual range of any unit, and they would have stealth detection as well. In Outpost 2, if you had your units turn off their lights, they became effectively invisible on the Minimap; you could still scroll over to them and see the targets moving, but if you didn't look you wouldn't find them. With the Scout, they can detect units with their lights off, and display them onto the Minimap. Plus, if they are the only unit / structure in the game that could do that, you could find a use for them no matter what stage of the game you are in. Plus, there might be research that allows those Lynxes to "see in the dark" and thus be completely unaffected by having their lights out and thus move at full speed.

For Bulldozers, I had considered having them have several features: 1) Level Ground, 2) Push Soil into Soil Piles, 3) Push Junk into Junk Piles, 4) Dig Trench and 5) Fill Hole. 1) is self-explanatory. 2) I had considered that for the early game, you need Soil to create Food (at least until Hydroponics is researched), and you can use Soil to create an early resource could Concrete. Concrete would be used to construct early buildings and defenses, at least until you could acquire enough Common Metal (or just Metal) to construct structures out of Metal instead of Concrete. Junk is created from destroyed units and buildings (yes I would like units to leave a corpse), meteors, and garbage piles (created outside of each structure indicating waste products). Junk can then be "mined" by cargo trucks later and delivered to a GORF or similar recycling facility; once you have a GORF, those garbage piles wouldn't be created anymore and instead be automatically converted back into useful resources. A dug out trench, can be used to divert Lava and thus create an impassable fiery moat at the same time or the trench just slows down units that are forced to enter it or decide to find a different way circumventing the trench. Fill Hole is simply to fill those ugly meteor holes on cleared ground, or fill a dug out trench.

Earthworkers are getting a complete overhaul, and are basically going to become units capable of laying down all defenses, including turrets, as well as a variety of other things. Once I figure out exactly what I want them to do, I'll mention them. Of course, if you guys think that making them capable of doing this isn't a good idea, please mention that as well. Some things I had thought of was: Bridge (over the dug out trench; can be raised/lowered), Gate (Open/Close, Automatic/Manual), Walls, Guard Towers (attaches to walls or Gates), Detection Tower (Spotlight and Sensors), and Pavement (Increases building's resistance to disasters, increases build speed and increases vehicle movement speed). You could also queue up as many details as you'd want, much like in Supreme Commander.

I actually never understood why they did cliff hugging. I also never understood why they would lava hug either... especially when the lava is still expanding. I've been thinking also that crippling the units with bad pathfinding to make a RCC like structure useful isn't a good idea either. However, what I did consider is that the RCC like structure doesn't improve their pathfinding directly, but gives the player added ways of pathing, such as Waypoint Paths (Travels to Waypoint 1, then 2 then 3, etc), attack move, or multiple patrol routes. Or possibly gives access to other AI based abilities, such as Seek and Destroy (which causes units to wander around, looking for targets, and then once finding one chasing it until it is destroyed)

For ConVecs, I had considered having an option that causes them to return to the Structure Factory that they got a Structure Kit from after building it. Additionally, I had also considered having a way to specific the construction zone that you want, when you click to build the structure kit in the first place. Thus, once a ConVec grabs it, then they go to the place where it was supposed to be built, builds it and then returns. I also considered that any free ConVecs will head to the Structure Factory and grab a structure in storage and go to build it. If the structure lacks a designated construction zone, then the Savant computer could state that a ConVec is waiting for construction site. This does sound quite complex to me, so I'll need to think about a way to do this. Because, I find that the ConVecs and Structure Kits are one of the most unique things in Outpost 2 and thus I would want to keep them. Its just that they require a lot of micromanaging and thus the player needs ways of automating them.

I agree, that running out of Tech is fairly bad, especially as the player gets used to it and that research provides such a large morale boost as well. I had considered at one point (though haven't thought too much on it since) of having "blind research". Blind research would involve scientists researching and the blind research would result in some kind of small bonus to something. So, they could do Blind research, and make a discovery that increases laser damage by 5%. It is small, but it would give Blind Research some benefit other than just doing research for points. Thoughts?

Good point on the Novellas. I had realized this as well. Unfortunately, I don't know currently of any way of tying them into the game without forcing the player to read them OR doing something cheesy like C&C does and having dialogue between people you really don't care about forcing the player to wonder why they had to listen to it in the first place.

Were there other things in Outpost 2 that you felt lacked purpose? For example, in Multiplayer games did the Trade Center get much use? Or did Evacuation Transports have some use in Multiplayer? Or were Scorpions used much by Plymouth players in Multiplayer? Or was attempts at stealing vehicles with Spiders used in Multiplayer? I ask, because it seems like strategies involving multiplayer simply revolved around either clashes of early units or tank columns of powerful units.

Another two points:
1) Did playing as humans affect gameplay as much as it did? If you played as some weird alien race, would it have had the same impact, if they were on the brink of extinction?
2) Did you feel that during multiplayer or colony games, the sense of urgency or the feeling of coming doom was as noticeable as it was in the Campaign? By this I mean, in the Campaign, you are constantly reminded that extinction is chasing you constantly during the campaign, and making the wrong moves could spell complete disaster for your colony... especially if you took too long, or didn't anticipate an enemy assault at the last moment (ie having units come out of a Garage was a nice touch that surprised me during the Campaign). I ask because the theme of the campaign is one of survival, and was wondering if the same applied to Colony and Multiplayer games... or a better question, should that theme be present in those other two modes?

Keep the comments coming guys, this is very helpful for me!
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Arklon on August 16, 2015, 04:03:30 PM
A few things sometimes annoyed me about Outpost 2. One was the excessive amount of management required. Having to set mining routes took too many clicks, and never seemed to provide any real benefit for doing things that way. Factories and labs had no queuing system. There is no point having scientists do nothing once they finish a research topic, so why not have them automatically start on the next? And why is research progress discarded if you switch research topics? Why not just put the progress aside for when you continue on it. It's not like scientists would burn their work if they had to switch topics to work on something new. Similarly keeping factories producing was near impossible if you had something else taking up your attention, like a battle going on on the far side of the map.
Well, keep in mind a lot of conventions you'd expect from more modern RTSes, especially anything to do with automation/queueing, didn't really exist so much back then. For example, StarCraft (which came out ~6 months after OP2) had no factory queues either, and unit command queueing was primitive (but maybe a tad bit better than OP2's). Total Annihilation (which came out a couple weeks after OP2) was the game that revolutionized the genre with automated factories, robust command queuing, etc.
Some people argue in favor of minimal automation simply for the added difficulty, but really it's artificial difficulty. Adding factory queues, etc. lets the player focus on actually substantial things, like microing units in a battle, which can still have a quite high skill ceiling.

The cliff hugging path finding sucked. Having the RCC was a neat idea, but I think removing the pain altogether might provide a better player experience. I'm not completely certain on this one. I think pain is not synonymous with challenge.
Funnily enough, OP2's pathfinding is quite good compared to StarCraft's... even though it sucks. But really, pathfinding is computationally expensive, and you're talking about a pathfinding solution designed to run on really old hardware. You can't expect any miracles.

Having to manually load Convecs, and then once they were finished loading tell them where to go and deploy a kit was a slow process. You sort of had time to do something meanwhile, but then you might forget to come back, or you might be delayed completing a build command. I didn't mind the process so much as the user interface for directing the behaviour.
Yes, I think it should work more like, you assign ConVecs to a Structure Factory, and when you build a kit you also select where the actual structure will be built; when the kit's done, an assigned ConVec picks it up and builds it where you selected earlier.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Highlander on August 16, 2015, 04:22:37 PM
1c) No After you research those extra buildings that will impact your morale and take up some workers, it becomes harder to deal with morale.

1d) I'd prefer the diminished returns version I think. Gradually smaller improvements, while taking longer and longer time to have them researched.

The thing with advanced weaponry, it yes, they have higher damage output, but that is not the big benefit - Range is the important factor. Sure, 2-3 lasers/Micro's can take out that Thor's hammer lynx any time, but unless they can corner it, they are never gonna get near enough to fire. Add in weapons combo's and this become more evident - Like Sticky/RPG. Get the opponents vehicles stuck, then take them out with with the long range of the RPG. Suddenly it doesn't matter that the upgraded lynx can almost go head to head with the RPG, because again, the Micro will not get close.
When you add in area damage from ESG and Acid (Hide those behind a wall for defense), then it doesn't really matter how many Laser/Micro lynx the enemy have, you can take out their entire army.

Extra features of the weapons might be an interesting idea, just make sure it's not over the top..

2a) I'd prefer to keep Scouts and Surveyors separate, as they both fill their niche roles - more later in my post.

2b) The damage types seems somewhat excessive. Why should concussion damage slow a vehicle ? And to successfully shoot through several targets, you'd need pretty strong materials in the missiles ?

2f) The wall hugging is annoying and we can probably do without that even without the RCC. However, I like the idea of the RCC, so maybe it could provide some other benefits somehow ?
And yes, I was thinking about the traffic jam :)

3a) I would keep the different paths of the story hidden, so that the player had to replay and chose the other direction to figure out what would happen. Add's a little to replay value i think. Probably it wont matter as someone will post the difference at some point anyways, and people will just chose accordingly :P

3d) Probably there is a healthy mix of what can be micromanaged and what can be left to automation.


In response to Hooman

Lots of good points there Hooman :)

I) I like the mining routes, without them, getting resources would be a full time job. Trust me, I played the game like this for a long time before I figured out about how to set the cargo trucks to automatically go to the mine.

II) Queueing systems would be nice - especially for the factories. With research, you often want to follow up on the new topics you unlocked from a completed research topic though - so Im not sure if queueing would work as well for the labs ?

III) Useless things:
Yes, Supernova and Starflare GP's are quite useless. People have often suggested they work like mines instead and be hidden, but not sure how to do this practically, though I like the idea.
Robo-Surveyors are ok I think, they sample and determine ore value and in that way serve a purpose - until of course you have every beacon surveyed or send up an Edward Satellite.
Scouts also have a purpose - a pretty important one actually. Firstly they can steal some info from the enemy, which can come in handy, but which is rarely useful. However they also give a warning when enemy units approaches your base - and that is perhaps their most important function - to give early warning of an enemy attack and give you time to react to it.

However, I do like the purpose of scouts we had in "Survival" game mode - where mining beacons where not immediately available, but had to be found by scouts first, then surveyed by the robo surveyor.

Panthers - agreed. Never saw much use - either you wanted the speed from Lynx and the Armor/double turret of Tigers.

Robo-Dozer - again yes, a bit useless. But not because what they did was that useless, more because they did it so slowly. If you set it do bulldozing the ground where you want your base, then construction is faster.. Not by that much, but it helps. Unfortunately the bulldozing itself took loads of time. I would like to see this unit getting some additional work/roles though.

Earthworkers - I like Hooman's idea's where you could outline what you wanted built instead of having to do 10 squares at a time.

Another comment on Scouts - once you turn on Day/Night cycle or start enganging your opponent(s), then you wont have time to watch all entrances to your base or the minimap - and it can be quite easy to sneak a few units past your defenses and into your base. A lot of games have ended with a Flare taking out an Adv. Lab.
The scouts give off a verbal warning, so you have 1 more way of detecting a sneak attack at night or through your back door (or both).

Germans had Panzer tanks and Panther/Tiger tanks. Panther and Tiger tanks were advancements made throughout the war.

Convecs - A bit slow to use, but i think they are fine. It gives the player the option to chose what to build when and where and i what order. Suddenly you need a Guard post buildt or an agridome or a tokamak. Would not be so good if the convec just went to get some other useless structure in that case.

Trade Center is fine I think - it serves it's purpose.

Evacuation Transports have generally been useless - but in Flashy's scenario, they could be used to transfer colonists from your base, traded via Trade Center, then released at the receivers Command Center. Which I think is the best use for the Evac Transport - being able to pass colonists between two players in multiplayer.

Garage - Another pretty useless building. It just takes too much time to load and unload vehicles into it. The building makes perfect sense I think, but it needs some automation to it.

With Multiplayer, I dont think the game matches the description or the feel of the description of the game - there is simply too much ore in many cases. One one hand it says that it is a desolate world and hard to live there, while in Multiplayer you can build massive armies several times over without any problems..
(As a sidenote to this, how about mines running out of ore eventually ?)
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on August 16, 2015, 09:53:43 PM
I would prefer C&C or StarCraft style mining. Being able to specify waypoints is a feature you almost never need. It shouldn't be the default way of interacting with the game. Way too many clicks for something that should be simple. It should be one click to set your trucks auto mining.

I liked the research system in Pax Imperia: Eminent Domain. Research was divided into different categories, such as Weapons, or Colonial. You could specify what kind of tech was your priority. When research finished on one tech, it would automatically start researching the next. It would choose the cheapest next tech for that research topic, as the cost to research each tech increased exponentially with research level. It also wouldn't forget progress if you switched research goals. Granted the percentage of research points going to each category is probably a bit too much control in many cases. I usually set one category to 100%. You might as well focus on one tech until you get it, rather than divide your efforts and end up with two half finished techs.

The math behind morale calculations is a bit stupid. That's what makes the rec centers useless. It calculates your total morale effects points and divides by the total possible, based on what techs you've researched. I believe it does this so it won't kill you for morale early game when you have nothing researched. I think a better approach would be to simply increase that denominator for the number of possible morale points over time. That way it forces the player to eventually research those techs if they want to have decent morale. Basically slowly raise the standards over time, based on the elapsed game time, rather than what the player has chosen to research.

I agree with the building placement, and auto-deploy with a ConVec. That might be a feature enabled by an RCC. Increased interface automation. Instead of building a kit, docking a ConVec, loading a kit, moving a ConVec, building the kit, you can just specify a structure type, and where you want it, and have the game built the kit, find the ConVec, load the kit, and go deploy it.

For end of game scientist use, perhaps have a number of special techs that temporarily increase something while the scientists are working on it. Like increase power output by 5% while scientists are working on an energy project. If you move the scientists to a new task, you lose the older temporary benefit.

I loved the C&C cut scenes. The Red Alert ones were also pretty good.
"When you kill one, it is a tragedy. When you kill ten million, it is a statistic."

The garage definitely needed some automation. I think an auto load, just by moving a unit or group of units onto the dock should work. A button to unload all, having each unit clear the dock after coming out would also be nice.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on August 17, 2015, 01:16:23 AM
Here is a thought I've been toying around with: Raid Sirens. Basically when a Sensor Tower or Scout close to the base detects an enemy unit, it relays a response to the raid sirens to turn on. So, think of it like standard air raid siren; loud, obnoxious, maybe even with flashing lights, alerting a player that might be far away from their base of an imminent threat. Maybe even with a Savant comment when it happens incase you are too far away. And if you found that annoying, you could turn off the sound and/or light effects for the siren and stick to the Savant comment only. Thoughts?


My memory might be a bit fuzzy, but didn't Warcraft 2 come out before Outpost 2, and didn't it have unit queues? However, you are definitely correct that we are kind of judging Outpost 2 poorly for its lack of automation because most games didn't have that yet. I also agree that using units properly in Outpost 2 took quite a bit of skill. Do you think units should require that level of skill or should it be better documented / a tutorial given explaining how to use them properly?

Pathfinding is definitely one of the most computational expensive things there is for AI to work with. However, I do wonder if there are ways of reducing that computational cost, without making the AI dumber or less able to properly path.

Finally, that sounds like a pretty good idea.



1c) I almost feel like Morale is made too simplified in Outpost 2. What I mean is that instead of each event only providing a one-time bonus, what if some had a bonus/loss that was distributed over a period of time. As an example, take a Child Born; the initial event would provide a morale bonus, but you'd also think that over a short period of time, there would be additional morale bonus provided over a few ticks. Similiarly, take a Child's Death; the initial event would provide a morale loss, but you'd also think that over a short period of time grieving would take place and thus lose more morale over a period of time. If certain morale events occurred in this manner, having simple and steady morale such as from a Recreational Facility would be a way to combat the extreme lows and extreme highs of morale over time. However, I also agree that the loss of Workers to the Recreational Facility would be annoying still. Hmm...

1d) I didn't think of that for weapons. Good point; range is extremely important as well as the utility provided by stickyfoam.

2a) The only issue I have with Scouts and Surveyors being a separate unit is that Surveyors have very limited usefulness, while a Scout would have a greater usefulness even into late game. I had considered though, that a player could build a special "refitting" building that could swap the Surveyor's equipment with a Scout's equipment once you didn't need the Surveyor for that purpose anymore. Or have that option for other vehicles as well, such as converting one vehicle into another if you are desperate for them.

2b) My thought behind concussion damage is that it is applied force against an object moving in a specific direction. Take a Modern Tank firing a cannon at another tank. If the other tank survives, and was moving forward at the time, getting hit would cause it to recoil backwards from the blow or cause them to lose forward momentum instead. The slowing effect is supposed to emulate that rather than having a more complex effect that is a knockback effect which would likely require physics to determine how it affects the units velocity. Thus I took a simpler approach by saying it applies a slowing effect instead. However, I'm not completely happy with my idea either, so I'd welcome more input on it.

As for penetration, it is less to do with the materials in the missile, rather how fast it is going. A penny accelerated to Mach 5, would slice right through a Modern Tank; doesn't matter that the penny is made of inferior materials, it is going so fast that the kinetic energy is enough to cause it to keep going despite colliding with solid material. However, penetration damage in this manner would only really make sense for a Railgun, rather than as a damage type all of it's own, because your logical argument is quite sound; most weapons wouldn't be able to penetrate armor in the manner that I was thinking of.

2f) I've not noticed (mostly because I've never tried moving a massive army of units around) but do your combat units suffer from traffic jams as well, when travelling / fighting like other units?

3a) Sounds good.

3d) Indeed. Now the trouble is figuring out what that healthy balance is.

II: I believe I remember playing a game where (believe it was StarLords) once you finish a research topic, it would automatically start up a new one. However, when it completed the project, it would provide the player a chance to change the topic before it continued. Would something like that work, where it would continue to research if you let it, but could choose to follow up with the next project? Or, alternatively, what if in the Research Description, it told the player what tech would be unlocked, allowing the player to state that the next topic to research should be one of the topics that will be unlocked?

III: How does one hide a guardpost sized mine? I'd personally prefer just having a minefield type construction with different kinds of mines depending on the minefield.
What if the surveying equipment was also onboard a Scout? Would that then make the Surveyor as a separate unit obsolete?
Can Scouts steal data in Multiplayer? I know in the Campaign they were used for that purpose, but it never worked for me in Colony/Starship missions.

Another feature that scouts had in the campaign on Medium or Hard, was that they were used to find the Wreckage locations. I wonder if one could utilize scouts in a similar manner where they can be used to look for "treasures" in the ground for other units to recover and process.

Earthworkers, so something like that in Ludeon Studios, Rimworld, where you can put down construction outlines so that you can design the base without necessarily having the resources? Or something more like in Supreme Commander where you Shift+Click locations, and it shows a transparent facsimile of the building that will be built there with a blue outline of the location of the structure that will be built there (so that you can't build there and screw with the building queue)?

Mines that run out of ore, would force a player to realize that they'd have to keep building mines and surveying. I like the idea, as it would likely prevent turtling a base.



The only problem with the one-click system is what happens if you have two smelters, and you have many cargo trucks, and you want both smelters to be used. If one-click is used, they'd likely only go to the closest smelter and cause a traffic jam. If it was two-clicks, then you could specific the smelter. Unless, you can think of a way to allow one-clicking to be better. StarCraft isn't a good example, as at close range near the dropoff point, SCVs, Drones, or Probes can technically occupy the same space and thus no traffic jams occur. C&C also isn't a good example, as I've actually never tried having 6 or more Harvesters to one Refinery, so I don't know if you could or couldn't have traffic jams there either.

Actually, I do think of one way: What if instead of the cargo truck's back being removed underground, it instead dumped its ore into a pile, and multiple trucks could dump at the pile at the same time? This way, there would less likely be traffic jams, and you could pile up raw material faster. Then the smelter just sucks resources off of this pile and processes them. Thoughts?

However, if you could clarify in greater detail how you think a one-click system could work, I'd love to hear it... as it sounds like it could be far less complex than the two or three click system.

A very interesting and unique way of doing research in a game. Thanks for mentioning that one. I believe Alpha Centauri had a sort of similar system, but not as indepth as Pax Imperia. Was there anything else in Pax Imperia (as I've never played it... or heard of it before) that struck you as interesting and might be could in an Outpost 2 like game?

Also a very interesting way of doing morale; having the game require specific morale-based techs later into the game when you could spare the colonists. Unless I'm misunderstanding that?

Also an interesting way of doing ConVecs and structure kits. However, by structure type, what do you mean by that? If you meant say, Guard Post type, how would you ensure that it built the correct Guard Post that you wanted? Basically, what happens when there is multiple possible structures in a type and you want a specific structure to be built.

That is also an interesting endgame tech usage. However, how many scientists would you need to get that bonus? (ie you Have 10 standard labs, with 1 scientist per lab, each doing a separate topic) And could you have multiple bonuses, or have multiple labs researching the same topic, to get cumulative / multiplicative bonuses?

I agree that C&C cutscenes were good. Though Red Alert 3 started getting a bit too corny for my liking.

For the Garage, what about some AI complexity? What I mean is say once you have a Garage built, you can put in an AI control, that forces a unit to go to a Garage when it is at a certain percentage of HP or less (say 30% or less) and when the vehicle arrives, it automatically gets loaded in and then also automatically is pushed back out, when repairs are complete. Or too complex AI wise?

Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on August 17, 2015, 06:24:35 AM
Raid sirens can be bloody annoying. If you include them, you *have* to have a way to turn them off. It could be neat though, and would add a sense of urgency. It might also be the most despised feature of your game.

Starcraft had build queues, Warcraft 2 did not.

Morale in Outpost 2 has two components. One is colony state, which is instantaneous, the other is events, and provides a lasting effect. Indeed, children being born or people dying falls into the event category. Each event has an amount it contributes (or subtracts) from morale. The total event modifier slowly decays to 0 over time. I think it halves every few ticks or so.

Use of things like rec centers are not particularly useful in the morale system because of the way the two are combined. The colony state aspect is basically from 0%-100%. (colonyStateMorale = currentMetDemand/totalDemand). The denominator only increases as you unlock more techs. Thus the two ways of keeping morale high are to keep the met demand high (by building morale buildings), or to keep the total demand low (by not researching morale techs). If instead the denominator slowly increased over time, regardless of research, that would provide more incentive to increase the total points you could accumulate for the numerator, and also remove the penalty from doing the research. Thus you'd have incentive to research and build morale structures. You'd have to cap the increase though, or it'd be impossible to maintain morale late game if demand increased without bound.

Colony state morale is also scaled depending on difficulty setting, so at harder settings having everything met might scale down to say 87.5% morale, thus requiring positive events to push it up towards 100% (temporarily).

Some of the morale penalties for sacking your enemy's base are very high, depending on the structures you destroy. If you destroy a lot of civilian structures, expect your morale to plummet to 0 and stay there for a very long time. Adding a very large negative bonus of a few hundred or a few thousand takes a while to wear off, and completely obliterates your colony state morale, which is capped between 0-100.

Why would you build a whole new building just to refit units? That would rarely ever be used. Especially if you're just trying to refit a single robo surveyor to become a scout. And a scout only costs what, 250 ore? Just self destruct and built a new unit. It'd be cheaper than building a new building. I suppose if you wanted to add a feature to an existing building, like a garage, it might make some sense, but I have a feeling this just adds needless complexity without any real benefit. Increase efficiency by reducing waste in the game's design and selection of units, not by refitting them.

If mines run out of ore, then perhaps meteor mining could be implemented. Every time a meteor impacts the ground, you could send a truck over to collect the debris. I think the idea might be popular in theory, but you'd have to be very careful about the implementation or it'd be a major pain for players to obtain ore this way. It'd also only be viable if mines ran out and there was no higher income alternative. You'd need to find some way of automating the procedure though.

I'd also thought of just having trucks dump their load in a pile. Maybe have robo dozers push it into the refinery. Or just have a pit down into the refinery, which the cargo truck just dumps things into without stopping to detach and have the tail end enter the refinery. Why did they ever do that? It was silly. Besides, have you tried dumping a cargo truck's contents on the ground? Look at the animation. That would be a much better way to drop off the ore at the refinery. Less time consuming, and fewer traffic jams.

As for C&C, you can get traffic jams with the harvesters, but if a refinery is busy unloading a truck, the next truck will just find the next closest refinery. They sort themselves out. That would be a nice way of handling it. There isn't really any pressing need for more than one-click to start harvesting. Especially not if you have a basic AI that distributes trucks between smelters, or possibly even between mines.

Pax2 was a very different game from Outpost 2. I'm not sure how you can relate much of it, but I always liked their research tree. It was more of a galactic empire building RTS game. As you grew, your power increased exponentially, which meant things like techs also needed an exponentially increasing amount of work to complete them. That aspect might not carry over so well to a game like Outpost 2.

Pax2 also had fully customizable ships. As you researched new techs, you could design your own ships. Each hull type had a certain number of hit points, and a certain amount of space for systems. You could load up each hull with any of the systems you choose, up until the space was filled. As you researched more techs, the space requirements for older techs shrunk. It was a very fun aspect of the game, but I'm afraid it wasn't entirely well suited for a RTS game. Indeed, I often paused the game while designing new ships, which Pax2 actually let you do.

I have a feeling my base building idea is pretty much the same as Arklon.

I suppose what you could do is have the older style base deployment always be an option, but once you build an RCC, it could enable a user interface where you can plan your base with semi-transparent overlays. As you design your base plan, the structure factory can start building the kits automatically, and ConVecs could pick up the kits and deploy them automatically. Basically having an RCC would allow you to issue higher levels commands, and it would take care of the individual unit orders to carry them out. There may need to be some resource allocation though to handle priorities between building a base and say, keeping a factory producing combat units.

In Dune 2000, there was a wrench icon to repair buildings (which repair themselves when told to, at a cost). If you clicked a vehicle with the wrench, it would drive off to the nearest repair pad. Units would queue up next to the repair pads and repair themselves one at a time. Something like that might be useful. Allow the user to click on units while having all their health bars highlighted could help. It could be an RCC enabled feature.

I haven't given much thought to endgame research. It might be you need a full complement of scientists at a lab to get the benefit. I'm not sure allowing multiple labs to work on the same benefit is a good idea, since having unbounded bonuses could really mess with game mechanics. Maybe just provide lots of different possible bonuses, so it's unlikely you'd ever have enough scientists to research them all at once, even if you had a ton of labs.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on August 17, 2015, 12:45:04 PM
That is a good point about raid sirens. I had also just realized that another player in a multiplayer game could cheese your raid sirens, by bringing a fast-moving scout to your front door, then leaving, then coming back, and leaving, and such forth to cause the sirens to go on, then off, then on, then off. It could definitely be an annoying feature.

Thanks for clarifying the Warcraft and starcraft point. I clearly was mis-remembering.

Oh that is quite different from how I had considered doing Morale. I had considered Morale to be calculated by: Net Morale Change (+/-) = Total Positive Morale Events - Total Negative Morale Events. Thus in my formula, you'd want Recreational Centers as it would give you more Positive Morale Events, to counter Negative Morale Events, and thus when the Morale Checking Tick came by, there would be a higher likeliness that Morale would increase. I hadn't considered doing a division-based formula to calculate Morale, and didn't know that Outpost 2 did use that kind of system. The reason I wanted to go for a simpler addition and subtraction system (addition because you add up each Positive Morale Events and Negative Morale Events first) was because I wanted to make Morale easier for a player to understand, know how to control, and know what problem areas there is that they could improve upon to make things better. I had also considered having a "Morale Report" where after the Morale Checking Tick it would provide an interface for showing the net-change in each area (Positives and Negatives) compared to last Morale Report, and how many one-off events occurred.

I can definitely see now why researching Rec Centers in Outpost 2 would be disadvantageous, as the increase to the denominator would make it harder to control, rather than easier. Thanks for clarifying that.

I had also completely forgotten that colony difficulty also affected Morale. Thanks for bring that up.

Yes, you are right it is a stupid idea. I was just trying to get around the whole issue of discarding the resources. An alternative idea would be to allow the GORF or recycling facility to recycle a unit into resources based on its current health * it's construction cost, as a way of getting something back.

Well, the way I intended mining was to have it possible to mine literally anywhere, but the amount of resources you might get depends entirely on where you set the mine up. Thus, if you continually choose to mine low-yield areas, then of course you will be needing to set up mines on a constant basis. However, I also feel that high-yield minable areas should last longer than low-yield minable areas. As for meteor mining, I had considered that as a meteor lands, it leaves behind junk. And a Bulldozer or Cargo truck can grab it and haul it over to a junk pile or recycling facility (respectively).

An interesting idea with Cargo Trucks and Robo Dozers. The only negative is that if some disaster occurred and you lost your only robodozer and had no vehicle factory would be a loss, as you couldn't get any additional resources anymore. Unless there was a way to get resources without Robodozers. Personally, I do like the dumping into a pile idea, but I'd prefer the smelter to have a feeder-type system that sucks in resources from the pile, rather than being pushed in by a bulldozer. Thoughts?

Good point with C&C I did forget that harvesters would often seek out another refinery if one was busy. I say often because occasionally they'd be stubborn and refuse to go to a different refinery. Maybe it was because it does a scan for nearby free refineries and no other refineries are within range of that scan. If there was a system that could ensure that trucks would be able to handle themselves and go to the nearest free Smelter, then your one-click system would work... likely flawlessly.

I generally prefer to avoid exponentially increasing anything, simply because it either involves huge pointless grind, or in the case of damage / defense numbers, it involves massive uncontrollable power creep.

The unit design system in Pax2, I've encountered in other 4x games as well, but also in Earth 2150. And yes, it is often not a useful feature, as it can take several minutes, inside of the game to create a unit. Yes it pauses the game, but it really breaks the immersion and more often than not, the stock vehicles made for you are not useful to the player, forcing them to do that unit customization. If unit customization was simpler, and could be done in-game and required less time and effort for it, then I could see it working nicely. Otherwise no.

Two very interesting ways of making the RCC much more useful. I like the ideas.

I also agree that unbound bonuses likely wouldn't end well either... as it would be uncontrolled power creep. Hmm.

Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on August 17, 2015, 03:01:37 PM
I think cargo truck only mining would be better than also involving a robo dozer. If the structure is built into the ground, just have the trucks drive over a pit, which is narrower than the wheel base, and have them dump the contents. If the structure isn't built into the ground, perhaps there could be a ramp area that trucks drive up so they can dump their load into an above ground storage container. It should be a drive through structure to ensure an efficient traffic flow.

I think C&C checked if a harvester was heading back to the refinery, not just if one was already docked. Thus if a harvester which was far out into the fields suddenly decided to return home to a specific refinery, then it could block a harvester already in the base from docking at that same refinery. It was silly really, and sometimes annoying. It should probably have only checked if a harvester was already docked, not if one was heading back that way. If they wanted to be more clever, then perhaps they could implemented some sort of estimated queue time for each refinery, and account for holes in the schedule from trucks on their way, but not back yet. Hmm, I believe this might be a classic Dynamic Programming scheduling problem.

Slightly off topic, but...
I don't think the exponentially increasing thing really makes sense for a game like Outpost 2. If makes more sense for empire building games or RPGs.

In an empire building game you might start off with a single city or a single planet, and at the end of the game you might control 100 cities or planets. That should give you 100 times the rate of advance if they all contribute to something like research. Even more when you consider those games generally have upgrades, such as libraries or research labs. The improvements might increase the rate of a single city or planet by 5x, while the number of cities or planets increases by 100x, so you end up with an overall rate increase of 500x between early game and late game. If you didn't have an exponential increase in research costs there then you've have very non-uniform research times which would make for not a lot of fun. Generally you should expect research times to be roughly linear through game play so it's a constant aspect of playing. You want the rewards of completing research to be roughly evenly spaced out.

Similarly with RPG games you can't have someone level their character all the way on level 1 monsters. You need to force them to progress to more difficult areas if they want to maintain a decent rate of progress. Earned experience might increase 100x between early game and late game monsters.

You may have noticed the power increase rates between the genres differ, as do the typical cost increase rates. For a game like Pax2, research costs often increase 5x for each level (1000 points => 5000 points => 25000 points). For a game like Runescape, experience requirements double about every 7 levels (2^(level/7) + someLinearTerm). These values need to be set to give a reasonably stable rate of progress throughout normal game play.

I don't think the unit customization from Pax2 would work well for Outpost 2. It's a cool concept, but not well suited for a game like Outpost 2, or any game that doesn't tolerate pausing or offline play where designs can be made outside of normal play time.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on August 17, 2015, 05:02:34 PM
Driving over a pit and dumping the cargo into the pit sounds like a good idea. The only issue with an above ground silo, is that you'd likely have to calculate the velocity required by the cargo truck to get up the ramp to the silo and back down. Seems simplest to me for both efficiency and beauty of the solution to drive over a pit, dump into pit and be on merry way.

Oh... so that's why I'd occasionally see a harvester waiting at a refinery even though it was empty, and if I manually ordered the one in the field to go elsewhere, the one at the refinery suddenly decides to use the refinery.

Well, um, I kind of did want to do an empire building game. At any stage during that empire building, the player can assume the role of a singular colony leader. However, if they didn't want to do that, and instead allow the AI to control those colonies, then the player could take on the role of Planetary Governor, or later on Empire President.

The best way I could describe it, is an older game by Maxis called SimAnt. In SimAnt, you could take control of any single Ant, including the Queen. You could also have automatic mating and automatic colonization with those mated queens. Or you could do a manual forced attempt to colonize an area, or you could go personally and colonize the area. The yard is broken up into individual sections, where you can have a colony in each, with the goal to overrun the entire house and yard, and kill off the red colonies. Similiarly with what I had in mind was that the player could go in and control any one of their colonies, manually go in and create new ones, or leave it to the AI to do so, while the player handles the higher level strategic stuff. However, the option is also there to just stick with building colonies, and letting the AI run the Governor and President positions.

Well, there is a way of overcoming the exponential increase of research costs; you could instead have the contribution for each scientist be less, but keep the same goal for research points required. Thus, as the player has more scientists and labs, the higher-end technologies may have the same costs, but it takes longer to reach them as each scientist provides fewer points. And as they would provide fewer points, it would take more scientists and labs working together to produce the same points per second that you might have had when you were in the earlier game with only a single scientist. If you did it like this, then you could still have regular research discoveries at the same speed as you did at earlier gameplay but you'd need more scientists and labs to achieve those same speeds in research times. Thoughts?

The problem with most RPGs though, is that your rate of progress decreases the higher the level you get and most games have it so that you cannot gain experience from lower level monsters after gaining enough levels. Take World of Warcraft. At LV 1, it requires 600 XP to go to LV 2, and LV 1 monsters provide about 60 XP per kill. Once you get to LV 6, LV 1 monsters provide no more XP (I believe it is 4 LV below = Green XP, 5+ LVs = 0 XP). So that is about 10 kills to gain a level up. By LV 59, it would take well over 1,000 monster kills of the same level to gain a level; the monsters might grant 6000 XP per kill, but the amount of XP required is several magnitudes larger. The only RPG I can think of that doesn't follow this trend is D&D tabletop, where it is always approximately 10 encounters to gain a level up.

EDIT: While reading through the Robot Command Center on the Wiki (I'm looking at each structure/vehicle, to get an idea of what kind of technologies existed at the time when the events of Outpost 2 took place), I noticed it said that the RCC has specific computers that have built in Hardware Encryption and Anti-Jamming Circuitry to aid it's ability in making vehicles smarter. A way to make the RCC useful, is that as long as vehicles are within a certain radius of a RCC, they are more resistant to EMP and are immune to Spiders attempting to hack into them. Reading the Spider notes on the Wiki, it appears that the EMP causes the vehicle's harddrive to reboot and the Spider interfaces with the harddrive during the reboot process and hacks the vehicle onto Plymouth's side. However, as the RCC is designed to counter jamming and hacking, it would make sense to me that Spiders and EMPs would be less effective while a RCC existed within a certain range of your vehicles. It would have limited range to prevent those same vehicles from being resistant no matter where they were on the map, such as attacking the enemy's base. Thoughts?
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on August 18, 2015, 07:53:48 AM
Having scientists contribute less over time seems counter intuitive. It also presents one issue when dealing with the matter of research choice. You might expect certain basic techs to be easy to research, and to remain so if you chose to put off researching them until later. If instead you focused on some other components of the tech tree early game, and later returned to some of the easy but perhaps less important techs, they would now require much more effort to obtain then if they'd been researched early game. This isn't necessarily a problem though, as this would have the same effect as how Civilization works, it's just a weird way to implement it. In Civilization the difficulty of researching the next tech depends on how many techs you've researched so far. So although each scientist still contributes the same amount, there is a slow exponential growth in research costs, based only on how many techs have been obtained, and not tied to what the tech actually is.

How are you planning to reduce the usefulness of each scientist? If you did something simple like divide by how many you have, then you would remove all incentive to build up an army of scientists for faster research. There needs to be some ability for a player to improve their research position, even if it's only a temporary rate increase due to increasing difficulty. I think the exponential increase in research costs is a good working model.

If you start dividing the scientist productivity figures, you also enter into the territory of rounding errors, and possibly the law of small numbers. The later is probably the most relevant, and comes into play if dividing produces small numbers. Consider the difference between 4 increasing to 5 (a 25% increase) versus 10 increasing to 11 (a 10% increase). If you're dealing with small numbers, then you're generally dealing with large percentage differences. Random chance can have a much bigger impact on outcomes with small numbers. (I'm assuming integers here).

Depending on how calculations are done, seemingly small differences might accumulate across the empire, which can produce quite a strong difference in results for fairly minor changes in the input. Depending on your perspective this could be a good or a bad thing. Indeed, the tax rate in Civilization functions this way. The division of trade into income, science, and luxury are done per city. A small change in rates, set at the empire level, can produce a large change for cities with lots of trade, and no change for cities with little trade (the differences lost in the rounding). Depending on your cities, this could mean a small change in rate produces a big change in total output, or possibly no change at all. Of course, as your empire grows and the number of cities increases, you might expect the distribution of your cities properties to vary in such a way that large differences and small differences mostly even out across all cities. It's never quite true, but perhaps close enough. The mechanics of Civilization is interesting because of the small numbers used in that game.

I guess one of the questions you'll want to consider, is if you want large sudden changes between progression points, or if you want slow gradual change that builds up over time. Some games use small numbers where any increase represents a large percentage gain, while others use larger numbers and have a more gradual sense of growth. Consider a game like Pool of Radiance (a D&D game), where level caps are between 6-8, with hit points ranging from about 1-100, vs. a games like the Final Fantasy series where levels range from 1-99, with hit points ranging from low tens to 9999. The later produces a much more gradual sense of progress. I should also point out that both games have an exponential increase in experience per level. In Pool of Radiance the experience requirements double every level. In Final Fantasy it doubles at a much slower rate of every few levels.

There's also a reason why RPGs tend to have a slower rate of growth for higher levels. The quicker initial levelling provides feedback that encourages people to get into the game and play, while the slower late game levelling adds challenge and makes obtaining a high level character more rewarding. If it takes more effort, it tends to be more satisfying to achieve. I don't think much about levelling to 99 in Final Fantasy, where it's almost a matter of course. I've done it a few times over in the various games I've played. But in Runescape where it can take months to get a single skill to 99, it feels like much more of an achievement worth being proud of. (Or embarrassed for spending so much time on the game, take your pick). It also affects the life of the game. If progress slows as you get closer to the top, it can make the game fun for a much longer period of time. Consider this, experience earned grows linearly in Runescape as you work with higher level materials, by maybe about 5x, but experience requirements double every 7 levels, which means it doubles over 14 times between level 1 and level 99, which means you need about 2^14 = 16384 times the experience to achieve the last level as opposed to the first level. A considerable effort.

Of course Runescape is an RPG that people play for months or years. An Outpost skirmish can't last more than a few hours.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on August 18, 2015, 05:35:14 PM
EDIT2: Actually it appears you did understand me. It is I that didn't read your post clearly enough. My apologies again.

Based on your responses, I failed to explain my point clearly enough. Apologies. I'll explain it now though:

In most games, research cost increases while research provided remains static. So a LV 1 Tech could require 500 research, while a LV 10 Tech could require 250,000,000 research.

What I'm proposing is that the research cost remain relatively constant, but at different tech levels, research produced by scientists decreases. This doesn't mean that if multiple labs research a topic of a much lower level that they won't be able to contribute as much as a player might have done with only a single lab. So, research cost at LV 1 could require 500 research, while LV 10 Tech could require only 4000 cost.

The change would be that instead of research per scientist is +100 every 5 seconds, as a constant variable irrespective of the tech level, here the change would be that the higher the tech level, the less scientists provide every 5 seconds. So at LV 1 Tech, Each scientist provides say +100 research data every 5 seconds, while at LV 10 Tech, they'd only provide say +3 research data every 5 seconds. Thus, this would encourage at Planetary and Empire tiers, that in order to accomplish research at the same speed as you did in Planetfall or Colony Tier, you'd need more scientists and thus more labs working in unison. If you decided however to do a Tech Level 1 research at Planetary or Empire Tier, it would get researched nearly instantly. However, for higher tech levels, you'd need more scientists working together to achieve the same results.

In theory it should do the same as exponential increases, without the exponential increases. I'll provide an edit, when I can figure out the math correctly to show an example of it (I tried, and managed to get the same amount of time it would take to complete a project, but I didn't choose my data per second numbers correctly and thus the resulting answer was 20,000 seconds or about 5.5 hrs to complete a project... an obscenely long research time).

Basically, each tech level would have different data per second provided per scientist, so if you used a large number of labs to research low-level technology, it would happen nearly instantly.

Well, what I'd prefer is to avoid rounding errors by doing integer division where it drops the remainder (true it does round down); I'd prefer whole numbers as it is easier to do a lot of things without decimals.

Otherwise lots of very thought provoking stuff Hooman (so thought provoking that I'm going to need to digest the rest of it for a bit while I think of a reply as I feel the rest of it does deserve a reply). I'll edit this again later with further responses. (or just add them to another reply if someone else joins in)

Edit 1: Math Support for Research:

Tech Level 10, 500 Scientists Each, Data Measured per Second

System 1 (Exponential Research Costs) = 200,000,000 Cost / 500 Scientists * 1000 Data/s = 400 Seconds to Research Topic
System 2 (Reduced Research per Second) = 20,000 Cost / 500 Scientists * 0.1 Data/s = 400 Seconds to Research Topic

In both cases, it would take 400 seconds to research a Tech LV 10 research topic. In the first system, the research cost increases, while in the second system the research per second decreases with higher tech level.

Then again, after looking at the numbers, you are likely right that it does seem counter intuitive, and exponential research costs does now sound like the better idea, over reducing scientist data per second.

Edit 3:
Yes, I can see now why having division to calculate scientist data per second is a bad idea, and that exponential research costs does sound much more logical and reasonable. So, thank you for posting your reasoning against it. I appreciate it. Now for the rest of the post; comments:

As for the Empire side of things, what I had considered was to have specialized colonies. Instead of ordering all colonies to adapt to a specific broad planetary policy change, you'd have different colonies working to produce various things based on their location on the planet; empire tier you could enact policy change to overcome shortfalls by having non-specific regions change their specialization. The AI would naturally work to create specialization based on specific regions and on overall need of something, and the player as the Governor could force a specific colony to a specific specialization.

However, I had thought at the Empire level, if you noticed shortfalls in something, you could create a broad policy change requesting that Governors convert as many possible colonies within reason to a specified type. Keeping in mind that some areas are naturally better than others for something, a colony in an area where it is naturally better to be one specialization, will stay that specialization at all times, unless the player forces it to change; the AI will leave it alone. As an example, if a colony is in a metal rich zone, with lots of volcanoes, and a lot of work to manage those volcanoes, then it will be specialized for mining and operations in volcanic regions. Thus, the AI wouldn't attempt to change it into a research, or food production specialized area as it is naturally better to keep it specialized for mining than it is to convert to something else. The player of course can order it to change despite the fact that the region wouldn't be ideal for a different specialization. Thus I also wish to create specific zones on a planet, where they are naturally better at being specialized to a specific thing. Thoughts?

That is a good question. I haven't actually decided upon how progression in numbers will occur. For some things, particularly units it will likely be with smaller numbers. But with research, or Planetary/Empire level construction it would likely be with larger numbers. The exact numbers could be addressed during the actual development during balancing passes. Though, figuring out in general which things falls into which category before development phase would be a good idea.

There is a bit of an issue though with RPGs; the maximum level is definitely something that feels like an accomplishment worth it when reaching it. However, each level they gain along the way doesn't really offer them much in the way of in rewards for working towards that level. In WoW, going from LV 58 to 59, doesn't usually feel like an accomplishment; it more feels like... "I wish I was 60 so I didn't have to grind anymore." Going from 59 to 60, however does feel like an accomplishment, but was all that time spent to get there worth it? Getting to 60 was worth it, and feels rewarding, but your trek from LV 50 to 59? Did that feel worth it? Did you feel that each level made you significantly more powerful, or that the loot gained was worth it? Most people I don't think would say that going from 50 to 59 would feel the same way as reaching 60, even though they accomplished more levels or accumulated far more experience in total than was necessary to get to 60 (I'm talking from a player who played Vanilla, and some of BC). When I finally reached 60, it felt great for a time. But during the grind from 50 to 59, it felt like total and utter drudgery, many times asking myself why I was doing it and if 60 was really worth it to achieve? If each level felt valuable, then I guess the end goal of 60 would mean less, but at least then you'd feel like you enjoyed your time getting to 60, rather than trying to rush to 60 as quickly as possible as the game only really begins at that point with raids, PVP loot, and epic loot. However, after I reached 60, and realized that the true grinding only happened at 60, I felt cheated. I had thought things would get so much better at maximum level, but instead it was worse because grinding was needed about 10x more at 60, than it was during 50 to 59 as loot rates are atrocious, and that the cool end game content was only available to those who got lucky with rolls and had the weeks to spend doing it. Course I think this whole discussion on my part about WoW is a rabbit trail. I guess for me, if there is going to be serious grinding at LV 60, then why not make it easy for players and start at 60 so that they can do meaningful grinding towards actual endgame content, rather than spending months gaining basically pointless levels. Anywho...

However on your point of a skill taking forever to level up to 99. Did each skill up feel rewarding, as if the effort spent to gain any level of that skill was worth the time investment, or was most of it a grind where the 99 skill level was where things got good, but all skill levels up to that point felt like meaningless bumps in the road.

Maybe MMOs are just not for me.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on August 19, 2015, 05:59:48 AM
Yes, it sounds like what you'd proposed for reducing research contribution for each level was mathematically equivalent to increasing research costs for each level. Instead of dividing the contribution by a certain amount, multiply the cost by the same amount to get an equivalent system where research contribution remains fixed, but research costs grow (exponentially, or not, depending on the sequence of numbers you choose). Well, equivalent aside from rounding error.

Regarding integer math, avoid division whenever possible. There are two main reasons:
1) Division is much slower than other basic mathematical operations (addition, subtraction, multiplication).
2) Division introduces rounding errors.

For instance, instead of checking if ((x / 10) < y), you could check if (x < y * 10).

A slightly related topic, avoid floating point whenever possible. You really need to know what you're doing to work with floating point properly. There are many commonly assumed mathematical properties that people assume hold which actually fail for floating point. You can also often do equivalent things with integer math. Here are some common issues:
1) The spacing between consecutive floating point numbers is not fixed. For large numbers, the minimum distance between numbers can be greater than one. For a 32-bit floating point value I believe that threshold is at 2^24. For 64-bit float point I believe that threshold is at 2^53. This of course means rounding errors greater than 1. Try it:
Code: [Select]
float f = 16777216; // 2^24
f++;  // No change (rounded down)
2) Floating point addition is not necessarily associative.
  Associative means ((A + B) + C) == (A + (B + C))
See the above point. If one of those values is large, say 2^24, and the other two values are 1, then ((2^24 + 1) + 1) rounds down to ((2^24) + 1), which leaves you at 2^24. If you add the small numbers first so they get bigger (2^24 + (1 + 1)) = (2^24 + (2)) = 2^24 + 2, with no rounding errors.
3) Common decimal values are not exactly represented by floating point values. Like say, "0.1". Powers of 2 work well, (including negative powers which produce fractions less than 1), hence 0.5 = 2^(-1) is not a problem, much like how 0.25 = 2^(-2) is not a problem. Sums of powers of 2 also work, such as 0.75 = 0.5 + 0.25. When working base 10, remember that 10 = 2*5, and that factor of 5 throws things off. It's like when you divide by 3 or 7 and get a repeating decimal answer. The same thing happens in a binary system when you divide by 5. That 5 is not a factor of the base of a binary system, and so the representation will be a repeating sequence of bits, representing an infinite sequence of additions of (negative) powers of 2. Since registers store values in a fixed number of bits, there will be truncation of repeating values.
4) Exact value comparisons often fail. This can be due to rounding errors in calculations, or rounding errors in converting decimal numbers in source code to actual floating point values (see above). Instead a close enough approach if often needed.
Code: [Select]
if (x == y) { /*Code not likely to execute when expected*/ }
if (abs(x - y) < epsilon) { /*This should work for appropriate small epsilon value*/ }
5) Conversion between floating point and integers can be slow
6) Different processors implement floating point to different precision, which means results often differ when the same algorithm is run on different CPU families. On x86 you have a choice of 4 byte floats (32-bit), 8 byte floats (64-bit) and 10 byte floats (80-bit). I'm not aware of other processors that offer the last option.

Not surprisingly many code optimizers won't touch floating point code. Consider what reordering operations could do considering they are not associative, and with rounding errors which can build up over operations, and will almost certainly be different if operations are reordered.

It often makes sense to avoid floating point when possible. Consider this, to calculate a Cartesian distance, you can use Pythagoras theorem along with a square root.
Code: [Select]
dx = x1 - x2;
dy = y1 - y2;
distance = sqrt(dx*dx + dy*dy);
The stock square root function uses floating point, so even if distances were integer, you'd convert to floating point, perform the square root, and then possibly convert back to integer. You could use a custom integer square root routine, but it's still going to be a bit slow.

But if you're only checking a distance against a threshold, like say a proximity check for enemy units, or a range check for firing a weapon, this is a different problem. You only need a yes/no type answer, not the exact distance. Hence, square both sides of the equation.
Code: [Select]
dx = x1 - x2;
dy = y1 - y2;
if (dx*dx + dy*dy <= distance*distance) { /*Within range*/}
The above uses only integer math, and avoids a slow square root calculation. Note that it never actually calculates the distance between two objects. It only determines if two objects are within a certain distance. Also, if many objects are being tested for proximity, the square of the distance threshold does not change, so that multiplication can be lifted out of the loop.

But that was a bit of a side tracked rant.

As for Runescape, depending on the skill, most levels unlock a new ability. Smithing had a whole set of weapons and armour, and for I think 6 different materials. It got crowded near level 99, in that the last level unlocked a whole bunch of things. There weren't enough levels to evenly distribute all of it. Skills like fletching had fewer abilities to unlock, so they were spaced out more. That unlocking of new abilities made each level more rewarding.

Edit: Meant "associative", not "commutative".
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on August 19, 2015, 04:32:18 PM
I didn't know that division actually took longer for the computer to do than multiplication, addition or subtraction. Good to know.

I also didn't know about the complexities regarding floating point numbers (including Double or Float, in C++). I would have assumed that they would work essentially like integers except with decimals, but I didn't realize that including the decimal adds in rounding errors (if I'm understanding that correctly). I also didn't know that floating point numbers were not commutative. I learned C++ from an older textbook, and it glazed over details concerning floating point numbers, much to my discomfort now.

Few questions regarding floating point numbers:

1) If I typecast a variable of type Integer (short int, long int, etc) to Double, would the typecasted variable suffer from rounding errors as well?
2) If I stored 2^24 in an integer variable, due to the size of the variable would it still suffer rounding errors, or is 2^24 too large a number to fit in an Integer variable (as I know there is numerical limits for integers)?
3) So rounding errors also occur for floating point numbers even if an integer value is stored in it (ie 2^24 is an Integer value, as it is whole numbers)?
4) Since pointers point to a memory address, if they pointed to a memory address containing a Floating-Point number, would the pointer also suffer from rounding errors?
5) What if a constant is used? Not a constant, as the constant added to a variable to make it fixed in a program, but the other kind of constant. ie Y = X + 2.2; where 2.2 is the constant. Does the constant also suffer from floating point numbers, even though it isn't attached to a variable of type float or double?

Can many mathematical calculations be simplified down to addition, subtraction, and multiplication, or only specific common ones such as Square Root, or Exponents? ie Could more complex mathematical calculations such as Calculus Derivative or Anti-Derivative be simplified down into less complex calculations (I think maybe possible having done Calculus in University, if you used the simpler calculation that has as X approaches a specific number; can't remember what the introductory formula is called that introduces people to calculus at the moment)?

A well worth sidetrack rant, Hooman. Very informative.

Okay, so then each level did feel valuable. Good to know. I just watched an Extra Credits episode that explained that most progression systems in games are Skinner boxes, and I'd have to say that World of Warcraft or Diablo 3 would definitely fit into that definition. Runescape, maybe not.

On a side note, having gone through the wiki to learn about the technology that was available to the colonists in Outpost 2, I kinda feel that the game we played didn't adequately show how high tech they were. As an example, aerial drones are commonplace and are often used as couriers to deliver objects to people or assist in construction. Or perhaps that the Spider was designed to do all the same tasks as the ConVec including constructing structures and each leg on the Spider could perform a separate task, so they could if next to several vehicles at once, could repair them all at the same time. Or that they had Mag-Lev vehicles inside the tubes for transferring cargo and people from one end of the colony to the other quickly. Or that they had access to virtual reality technology that would make the Holodecks on Star Trek look low-tech. Or that they had highly sophisticated computer systems that would make the UCS in Earth 2140 look like dumb-witted AIs in comparisons (and yet the UCS had a wide range of combat androids, assault mechs, and flying units).

I guess, it didn't seem as high tech to me because most of the units used tracks or wheels, when it would appear that the technology was available to have aerial drone units, hover technology, or in the very least Mag-Lev support to allow vehicles to be transported from one end of the base to the other quickly. Or that, with the boptronic technology in place, I doubt why colonists were needed at all in the first place (much like with the UCS in Earth 2140) as basically everything was automated, or had automated machines repairing / upgrading everything, such that the colonists could exist in a Virtual Reality environment for their entire lives (like in the Matrix). Or that their Agridomes were so sophisticated and well-run that they would be many times more efficient than a farm 5x the size of the Agridome, and thus I don't see why Eden wanted to Terraform the planet.

Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Sirbomber on August 20, 2015, 04:44:53 PM
Guys, can we maybe keep it a little concise around here?  Does everyone have to have a 5 page long wall of text for every post?  :P
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on August 20, 2015, 07:30:35 PM
@Sirbomber; Lol, true enough. I'll try and work on my brevity.


I'm working on various ways behind the scenes to figure out a way to reduce complexity by combining similar structures into one, and increase depth by giving those combined structures added features. The negative with a large structure list is that the AI becomes more complex with it's build order when there are more structures, especially if multiple structures appear to serve a similar purpose. I do want a good variety of structures, but having too many structures will likely also confuse a player on which they should or shouldn't build and in what order.

For example, (you can also still disagree with anything I post, as I'd like to hear input on my changes as well) take the Defense Tower. I've decided to combine the features of a Sensor Tower (Basically detection radius outside of Sight Range), a Light Tower (Utilizes a spotlight on the target it is currently shooting at to illuminate the area), and the Component Tower from Tiberium Sun, to create the Defense Tower. It can be built into a wall, has a spotlight, detection radius, and is mounted with any of the weapons you currently have researched. Additional research unlocks more features that are optional (they cost resources to upgrade) but provide some unique benefit if you install them.

In the meantime, if others would like to give their own input to the first 5 questions (reposted below), I'd also appreciate that:
1) I was wondering what kind of features would people here like in a game "based" on Outpost 2 as inspiration?
2) Are there specific things that irritated you with Outpost 2, that if you could you'd want fixed in a game like Outpost 2?
3) Are there specific things that you feel made Outpost 2 unique and without them it wouldn't feel the same?
4) Are there any things that particularly interested you with Outpost 1, that you wish Outpost 2 had?
5) I'm aware that a previous Indie Development Team had attempted a game similar to Outpost 1 (Terminus I believe it was called) and failed to achieve kickstarter funding. Do you perhaps know why it failed, so that I could avoid whatever problems they had?

EDIT: As an additional point, I've decided to again separate the scout back into two units: Surveyor and Scout.

-> Scouts are used to detect hidden units, find things in the environment, and have greater sight range than other units.
-> Surveyors are used to determine how rich an area is in each resource, and determines which parts of a cooled lava flow are safe for mining and travelling over. (Yes, lava is planned to be able to cool, and then be mined. However, if only a small layer has cooled, sufficiently heavy units can break through and burn to a crisp)
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Sirbomber on August 21, 2015, 09:05:16 PM
Just my two cents, but I would figure out the general idea and theme of your game a bit better before you start porting units in wholesale from OP2.  If you're talking about playing on a galactic scale, why would you need a stupid robot with a stick to poke at the dirt and tell you whether there's gold in them thar hills?  You'd probably have orbital sensors to do that, assuming you weren't just blowing up the planet and picking out the good parts from the debris.

Really this applies to anything, but I don't want to waste a good pun: don't add a Surveyor unless it surves a purpose.  ;)
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on August 21, 2015, 11:18:11 PM
Well, to put it into Outpost 2 terms, why would you build a Surveyor if you had an EDWARD satellite? You wouldn't. But, if you didn't have an EDWARD satellite, would you build a surveyor?

That is where the Tiers of gameplay come in. In tier 0, it would the equivalent of you being the commander of the initial settlers of the Conestengo (did I spell that right?) to build the first colony, likely made from ramshackle buildings and scrapped starship parts. Most of your settlement would likely be man-operated and very manually oriented. Thus, you would start to work towards automated facilities, and more permanent structures. Thus, you'd need a steady supply of resources, and to do that you'd need a surveyor. It is true, that by Tier 2, you might have orbital satellites doing the surveying for you, but you need to work your way there.

I also don't wish to lift units wholesale from OP2 either. Some units, like the Surveyor makes logical sense; you don't know where the rich resources are unless you have a way to find them, thus the Surveyor in the early game makes sense. In the late game, it will become obsolete, but the same can be said of in OP2 when you get an EDWARD satellite.

How I had envisioned the game was to start the player off simple, and introduce complexity to the player as they played longer, rather than have a huge information dump on them at the start, or force them to go through a large series of tutorials to begin playing. The intent is to allow people to pick up the early game quickly, while still having a lot of complexity to learn later on in the game. At any point in the game, I'd like the player to be able to remain the bold explorer, colonizing new places. However, I'd also like to allow the player to have a more strategic role in their civilization that they are building/rebuilding (haven't decided which yet), than simply a single leader of a single colony.

Thus complexity wise, tier 0 requires little set up and is fairly straight forward. Choose a base location, deploy your mobile structures, work towards making a more permanent colony with a fixed learning path, as specific structures would be required in a specific order. Not saying I wouldn't include a tutorial, just saying that I want the game to be easy enough to pickup and start learning immediately rather than do a specific tutorial first.

Tier 1, will play much like most of Outpost 2... to a point. A lot of the more advanced technologies, such as Spaceports, are in Tier 2. In tier 1, it will teach you how to manage the affairs of a single colony, balancing colonists, morale, food, mining, and defense. Tier 2, moves towards multiple colonies and thus the logistics and coordination of multiple colonies, whether working towards a similar goal or working on individual goals.

Tier 3, which is many hours into the game is where the empire strategic gameplay comes in when you have the resources and the people to develop starships to colonize new worlds. Tier 3 is very WIP right now. (Mostly because Tier 3 is likely going to be designed and developed later on [1 or more years from now]; since the early game builds into the late game, the late game only deals with managing multiple worlds, starship fleets, and other stuff, which could be separately designed and made modular and thus easily added into the game, particularly if I design the other tiers to allow for Tier 3 to be added in later)

And I have thought a fair bit of the theme of the game, before I came looking for input here. Its just that its fairly hard to explain that theme in only a few sentences, and as you've pointed out walls of text are not good options either, so I find it very hard for me to explain the theme without some kind of visual aid, such as a partially completed prototype, to express my point on the them. However, once I have a prototype, it is generally very hard to make changes either additions to it or subtractions from it that weren't originally planned to be there, or were planned to be there and had foundation code for future mechanics which will then cause problems when you remove something without realizing the repercussions.

Hope that explains some things without getting too wordy, or defensive (as I appreciate the input, but I feel that I'm just not able to explain the theme as well as I like to, and thus it is causing confusion) as neither are my intent.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Vagabond on August 24, 2015, 07:28:02 AM

I've been a big fan of Outpost 2, but never really posted in the forum. It is great to see everyone still excited about the game and trying to remake it.

I think designing a real time strategy game will be very challenging by itself. It would be a lot of work to design a another empire game on-top of the strategy game.

Maybe it would be worthwhile to break down the game from a technical standpoint first. What I mean is, look at the more challenging coding aspects first and solve those issues individually. Then circle back and make the game when you have a good understanding of the building blocks.

Navigating on a large 2D map with lots of objects
Efficient Path-finding
Unit Combat AI
City-Building AI

After you have mastered each of the skills, you could come back and build the full game. Otherwise, if you try all at once, it will be very difficult to keep from getting discouraged.

Best of luck moving forward with the project.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on August 24, 2015, 02:17:20 PM
That is the general intent, Vagabond.

I intend to work out the design of the game first, then determine how the various subsystems work, and then look towards building something.

The reason I intend to do the design first, is so that I can use top-down design on what I want, and break it down into simpler methods of solution. I had learned in my C++ book, that you should first design your code in plain English, ensuring that you create a step in the process for everything that you'd need, and then use that to design your code with. Then I can figure out exactly what kinds of things I will be looking for and thus learn how UE4 would do them or, determine how to go about building them. Since UE4 is technically designed for first-person games, it will take me a fair bit of time to determine how to utilize it to create a strategy game. But the quickest way to figure out what I need to learn is to figure out what I intend for the game to do.

Thus, I'm doing the design right now, and then use it to figure out exactly what things I need to learn to succeed.

As to the specific issues you've raised:

1) Map Navigation = Do you mean the minimap, the main view, or both? I have read up on various ways of navigating UI with edge screen scrolling, or holding mouse button and dragging in the direction you want to go. I've also done some reading on common conventions for assigning functions to the LMB and RMB. I've read up on selecting, de-selecting, and group selecting conventions. But I'm sure there is plenty of other things too.

2) Efficient Path-finding = One thing I have noticed with pathfinding is that the pathfinding available to the AI and the pathfinding available to the player are different. The AI's pathfinding is often far superior to the pathfinding available to the player as the AI doesn't suffer from units trying to occupy the same space, as it determines specifically where each unit will go. I have read up somewhat on how UE4 handles it's pathfinding; it requires navmeshing the map and often requires Environmental Query System (EQS) to properly pathfind. There is however, still a lot for me to read up on this topic as well.

3) The AI in General = One of the major problems with the AI is that it suffers from none of the problems the player does, and thus is often unfair and far superior to the player. It can micromanage everything at the same time, often flawlessly, while the player can only focus on one thing at a time... even with multiple monitors. So, one of the tasks I wish to address, is to see if it would be possible to "tone down" the AI so that it suffers from the same problems that the player does and thus feels like a fair opponent. As an example, the AI would have to gather resources like the player, and wouldn't be able to produce a structure unless it had those resources; or the AI wouldn't automatically know where the player was and thus couldn't just blindly fire off super weapons at the player (huge problem in C&C) without ever seeing where their base was. Again, there is a lot for me to learn on this topic.

However, the problem of trying to learn these things FIRST before designing the game is that you'd have to learn absolutely everything on the topic. If you have your design in hand, you can narrow down on specific topics and reduce the amount of learning you must do before able to get anywhere. My hope is that by doing the design first, I can reduce my overall learning down from about 1-2 year's worth of information down to 1-3 months of learning instead; still a lot of learning, but it beats a full year of learning (or more) and not much else. Same applies to designing the sounds and visuals as well; knowing what you intend to do, will help you to reduce the amount of learning in other programs that is needed before getting anywhere.

I have no intention of jumping straight into development with just the design in hand. I need to first determine if I can do all the things in my design before I start creating code or assets (most structures or units could be done as placeholder assets such as a simple cube, or something). If something doesn't work then I need to go back to the drawing board and try and figure out a solution. That solution might be to redesign the design, or it might be taking time to consider the problem in detail and trying to see if my understanding of how something works is actually the incorrect thing, rather than the bit of code I'm looking at. Hope that clarifies some things.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on August 27, 2015, 09:36:49 AM
Perhaps off topic rants need to be taken elsewhere. I decided to start a couple of extra threads:
Division Is Slow (http://forum.outpost2.net/index.php/topic,5716.msg81782.html#msg81782)
A Note On Floating Point (http://forum.outpost2.net/index.php/topic,5715.msg81781.html#msg81781)

Hmm, Skinner boxes you say, yes I can just imagine the USB popup now "New device detected: Electrified flooring". ;)

Ambition with vague goals is deadly. What's your next step?
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on August 28, 2015, 12:19:19 AM
What I'm currently working on is the overall level of technology for the game, to figure out the:
1) Story
2) Tech Tree
3) Weapons
4) Units

Being that Outpost 2 was projected forwards into the future of humanity and predicted what kinds of technologies it would have, I'm trying to figure out what kinds of technological development would have occurred BEFORE the events of this game will take place. However, a lot of technology that people in the 90s didn't think was possible has either be proven true or proven false, or brand new technologies that were never conceived at the time of the developers of Outpost 2.

As an example, Graphene is a more or less recent technology created, which provides amazing applications never considered in the 90s. Or perhaps many of the new ceramic or synthetic polymers created in the recent years has allowed great advances. Or a bunch of other things.

So, I'm combing through what are the latest technologies currently in existence, taking a look at what the developers thought was realistic by visiting the wiki, looking at projected technologies and then combining the three to try and ballpark the technology level say 10 to 20 years from now. Big task. Going to take me a while.


Though, I never could understand why they used Tokamaks in Outpost 2 as Stable Nuclear Fusion is still theoretical. We've had Tokamaks/magnetic confinement, for about 60 years now, and in that time, no nation has managed to achieve a sustained nuclear reaction for longer than a few seconds at most. Even inertial confinement hasn't been successful yet. Hell, at this rate, I'd say humans will discover a method of FTL travel before creating a sustained reaction with nuclear fusion.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Sirbomber on August 28, 2015, 11:11:31 PM
I would maybe focus on getting an engine working before I started any of that.  Without the code, the rest of it is pointless.

Out of curiosity, what would you say your level of programming expertise is at?  How much experience do you have?
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on August 29, 2015, 03:30:42 AM
I'm currently been feeling on the edge of mental burnout, and thus I'm having some difficulty, forming a response. I leave for a vacation on next Wednesday for 2.5 weeks, to visit some relatives down in the USA. I don't intend to bring my computer with me as I want to focus on addressing my mental state of mind without the distraction of a computer, thus I won't be available to answer questions until I get back. My current quality of life right now is quite poor, and I'm having trouble forming concise thoughts or being creative either. REM sleep seems to be completely ineffectual (as I go to sleep have 8-10 hours of uninterrupted dream-based sleeping and wake up feeling almost as bad as I did before sleeping). I have worked out a game plan on how to address my mental state of mind, while on vacation, including reflection, relaxation and processing the problems that I'm running into.

However, I will try to answer your questions, Sirbomber as best I can.

On one hand I would agree that getting a code-engine working is a good idea, but then again I'd disagree. Its like wanting to head to some location in the world. If you don't know where you are going, how do you intend to get there? If I don't know what I intend to do for the design, then building the engine may not be a valuable usage of time. If that code engine is exactly what I want to do, then its a valuable usage of time, but if it isn't what I want to do for the design, then it is a massive sunk time cost with limited benefit. I've also paid attention to a lot of indie developers, and AAA developers and the consensus is that building ontop of a code prototype is often not a good idea, unless you specifically designed that prototype to be easily adapted.

My intent was to design the scope of the game first, then use placeholder assets to design the code to the specifications that I'm looking for.

As for level of programming expertise... limited. I started learning C++ in September of 2014, and am able to grasp most things... except for pointers, which is a WIP. I've built several small code-based programs in the Console, but haven't worked with the Standard Template Library, any of the Graphics Programming Languages (ie OpenGL), or with standalone programs. I have some experience in coding, and spotting my mistakes when I make a compiler error (most often because I didn't put in a function declaration, or missed a semicolon).

Now, I have a pretty good idea what you might be thinking: He's too inexperienced and too ambitious and he's going to run into problems, throw a tantrum and rage quit. Am I right?

However, I digress. My intent after scoping the design out was to design specific functions and classes that I would want in the game itself within smaller prototypes or essentially small "driver" programs (by driver I mean when it discusses testing functions in a separate program called a driver to ensure that the function works properly before integrating into a larger program). I would use this as a way to both ensure that the functions and classes work in seclusion, and then look into integrating them into "stubs" to see how they work with other bits of code within what I want. I would also use this to gain experience in coding, coding practices, learning from mistakes, etc...

I'm smart enough to know I'm not currently smart enough to achieve what I wish to achieve. However, I feel that spending the time designing mini programs, testing out the various features of the game, and continually learning about programming and such forth, and I might be able to start actual development of the game in a couple months (optimistically).

However, again, until I solve my current issues concerning near-burnout and prepare solutions to preventing it in the future (as there is still tons of work left to do and thus likely to pop up again later if I'm not careful) all of this is a mute point. I'll try to respond to this post up until I leave on Wednesday, but after Wednesday I won't be around until approximately September 21st/22nd.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on August 29, 2015, 10:09:22 AM
Now, I have a pretty good idea what you might be thinking
I was thinking he's young and ambitious! He's actually willing to do something, and that really counts for a lot.

The best time to do something is often when you're learning it. Then it's fresh in your mind. It also allows you to learn better and in greater depth when you're actually working with what you're learning.

Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on August 29, 2015, 04:09:41 PM
I'm extremely passionate about building (even though I'm near burnout) the game, but I am well aware that knowing the basics of programming isn't sufficient to build a game. I need practice, patience, and determination to convert basic understanding into actual understanding, and one of the best ways of doing that is to build small programs to test out specific things, and see if what you thought was right, was right or incorrect, or possibly insufficient. So I figure that while I learn and practice the basics, I can also see if specific functions, classes, and larger bits of code (that often involves many, many functions and classes) that I want in the game to see if they work the way I think they will work.

I'm also aware that there is a lot of things that are often attached to even something as simple as a Unit. Things like, sound effects, animations, movement speed over X number of frames, turret speed over X number of frames, child objects, etc... And then of course there is the event loop or something of equivalent to one (someone mentioned to me a signals and slots way of doing things in a PM).

I'm also aware that this project will take me a while, and thus I need a way of addressing my near burnout, as it may crop up again later. I've seen what happens to people when they burn themselves out and it isn't pretty. Thus, I feel right now my priority is addressing that, and once addressed, then continue working on this. Sometimes a break necessary to succeed; something I feel I've learned the soft-hard way (as opposed to the hard-hard way of actual burnout) that riding oneself for more effort and concentration over several months time isn't conducive to success.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on August 30, 2015, 08:38:04 PM
Of course if you spend all your time experimenting with small toys, you'll never accomplish the original goal. The best way to accomplish something, is to actually work on what you want to accomplish.

So are you saying you're going to do this, or are you saying you're not going to do this?

Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on August 30, 2015, 11:07:13 PM
I apologize for not being clear enough.
TL;DR = Yes I intend to do it.

The purpose of building the small programs is to accomplish the goal of creating the overall game. They are a step in the process. Each small program is meant to achieve three things: 1) Give me practice designing code, writing code, testing code, debugging code, fixing code and redesigning as necessary (for when I realize a lack of logic or missed a step that I had intended to do). 2) Ensure a minimum of removing code from the actual game and thus reduce overall time needed to fix all the bugs involved in removing code from the main program; it is easier to design and throw out a small program, than it is to build the code in, realize it doesn't work and then have to rip it out again. 3) Test out a specific feature that I want to see about putting in the game itself and determine how difficult it might be to integrate it into the main program.

Some features are:
A) Special AI "quirks" that I'd like to see if they'd work at all the way I'd like them to. Most of the AI quirks I have in mind, may or may not work and thus I need to see if they work at all. (ie a Seek and Destroy mode, that orders a unit to wander the map and attack anything on sight, chase it down and try and kill it; once dead, it will then continue hunting)
B) Specific game/engine performance tweaks; I have a long list of tweaks from anything between highly likely, to highly unlikely to work, but I'd like to see about testing some of them out. (ie Adaptive Multithreading; multithreading that automatically adapts to the maximum number of threads for each computer and then splits work between each thread dependent on how many threads available, instead of static multithreading where you code specifically how many threads to have and specify what goes onto which thread.)
C) Features that are not present in UE4 and would have to be designed completely by scratch (ie a procedural map generator, with navmeshed terrain done at runtime after the map is built)

I'd like to avoid a minimum of feature creep into the actual program once I start building it and thus the small programs allows me to test out features and see if they would work or not, without being costly to remove from the program.

I am definitely wanting to do it. However, currently I need to address my near burnout before I can do anything else.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Leviathan on September 20, 2015, 08:40:00 AM

Great to see you are working on a project :) Best of luck with it and I hope you find the time for it. Learning through doing is the best way to learn in my opinion.

These are my responses to the first post without having read the rest of the thread.

1) I really like the fact that you have to connect your base together with tubes, this is part of Outpost 1 and 2 and makes sense on a planet with no oxygen in the atmosphere.
2) Normal progression of RTS engines really. Outpost 2 is very old. Add Multiple Building Selection (MBS) and rally points and queuing of unit production. Need a larger range of units/weapons that are unique.
3) Main thing I find unique in OP2 multiplayer is the fact that there is no fog-of-war, the whole map is revealed. There is the whole day/night and lights off thing but it dosen't get used much in multiplayer in reality. (We should increase the unit moving speed with lights off and then maybe it would get used). Other thing is Outpost 2 is great because its a traditional RTS game but also a city builder type game.
4) Outpost 1 had a nice pre setup thing before the game started, this was nice in single player and its mostly all I can remember from Outpost 1.
5) So many reasons why project can fail...

I'm sure there is more that I can think of...

Will you be sharing the Design Document?
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on September 23, 2015, 12:57:27 AM
Thanks Leviathan. Some thoughts:

1) I also liked that it required using tubes to connect the base. However, I felt that how the game went about doing it wasn't appropriate and felt that I would do it differently. Since these tubes are supposed to be underground anyway, I felt that using a Tube-interface similar to Sim City 2000 (not sure if later iterations did the same as I haven't played them... only the original SC and SC2K I've played... anyway) would work well. In SC2K, each building would automatically have some tubes built underground immediately after the structure is built. You would then have to install tubes in a special interface, which were used to transport water to those structures. When the interface is off, you can't see the tubes, as they are underground. When the interface is active however, all structures are greyed out and transparent so that you can see the tubes clearly and where there aren't any tubes. This way tubes would be both underground and not interfere with building placement, such as in Outpost 2 where you couldn't build Guard Posts right up to a wall, if the wall was to the Right or Bottom of it.

2) Good ideas for automation and assistance for the player. The problem with too many units/weapon combinations is that it causes the player to keep track of all that complexity, and then try to make informed strategies in real-time, which can be difficult. Extra Credits generally suggests to avoid having too much complexity is bad if the pace of play is too fast. The example they gave is if you had to do the calculations and planning of a turn-based strategy game in a first person shooter, the gameplay would be entirely unmanageable. I do however agree that each type of tank should be useful in different ways so that players would choose the Medium Tank and feel it is useful for a viable strategy, same as Light Tanks or Heavy Tanks. I also find that playing a game like Supreme Commander or StarCraft, where you do have a lot of different units with different weapons and it can be very difficult to plan out strategies at runtime, or counter strategies that other players use. Often players end up using just one or two units and that is it (which ironically, is the strategy I most often see in Outpost 2 multiplayer matches on youtube, where only two or three units are ever used).

3) I've always wondered why units drove slower in the dark. Considering that they use robots instead of people, I'd assume that those units would come equipped with night-vision and thus wouldn't need to use lights to see. If a human was piloting it, then sure they'd need lights to see, but as it is robots doing the driving and shooting, why would they need lights?

4) Yes I noticed that too from reading the manual which I found online. Getting to pick your cargo, colonists, landers, satellites, probes, etc... I also read that if you didn't take probes, you might end up at a planet that is uninhabitable and thus lose right at the start.

5) Very true. One of the biggest reasons I've found is people who put up a project, and then barely answer questions or provide updates to it to encourage further people to invest in it or at least get your current investors more excited. That's often a surefire way to fail, and even in the Kickstarter Manual, it says to avoid doing that as it will cause you to fail.

Yes, I'll be sharing the design document. I think getting some input on the design document when its "finished" would be helpful and useful for me; by "finished" I mean that I finish it and then open to criticism on what is contained and possibly/likely make changes to problematic areas.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on September 27, 2015, 11:43:20 AM
Only problem with your suggestion of the tubes is that it takes away from the core gameplay. In Outpost and Outpost 2, builds had to be connected to the command center via tubes. The tubes allowed for things like air, water, power, resources and people to move between buildings. In the context of the games, you're on an alien planet with limited resources. Building a tube structure underground like you suggested would be a waste of resources.

Also, there are gameplay elements to it -- one, it's  slower to travel over tubes as they're partially exposed and two it provides strategy options in multiplayer games allowing you to cut off another players buildings from their CC. I remember a game I played long ago where someone sent in their earthworker way in the beginning of the game and detonated it over one of the tubes connecting my CC to the rest of the colony. Instantly won the game.

Just thoughts on the hows and whys of the tube structure and why it was done the way it was done.

As far as using C++, it's evident that you're not very familiar with the language. I haven't read too thoroughly but it sounds like you're using Unity, yes? If that's the case, use C#. It's a lot easier to develop with -- fewer occurrence of crash bugs, memory issues, etc.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Sirbomber on September 27, 2015, 01:50:23 PM
The need to manually build tubes slows the game down and takes attention away from more important matters (and, as Leeor pointed out, allows for some pretty sleazy tactics in multiplayer).  I say either get rid of them altogether, or abstract the tubes away into a "buildings must be placed within X tiles of another building" rule.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Arklon on September 27, 2015, 02:20:20 PM
The need to manually build tubes slows the game down and takes attention away from more important matters (and, as Leeor pointed out, allows for some pretty sleazy tactics in multiplayer).  I say either get rid of them altogether, or abstract the tubes away into a "buildings must be placed within X tiles of another building" rule.
No, the obvious answer is to make every map Tube World.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on September 27, 2015, 02:23:23 PM
SirBomber brings up a good point. I can accept that 'automagic' tube thing but I still think it takes away from the game to remove them entirely.

I suppose it's debatable.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on September 27, 2015, 07:57:32 PM
My memory might be a bit fuzzy, but in Outpost 2, the tubes were built underground, at least as far as the novellas and structure blurbs were concerned. Also in Outpost 2, tubes act like paved areas (at least in campaign/colony games) and thus provide a speed bonus rather than a speed reduction. It might have been the case in Outpost 1 to have the tubes above ground, but from reading bits of the novella and blurbs for buildings it sounds like they were built underground in Outpost 2.

Also if you read anything from the Outpost 1 manual, it had an entire group of structures built underground such as the Consumer Factory or the regular Lab, with underground tubes connecting those structures. If it is costly to build tubes underground, imagine building an entire factory underground. Now THAT would be resource prohibitive.

Wait what? How does an earthworker blow up on destroying a tube via self-destructing? I thought tubes were nigh invulnerable unless an earthworker manually dug up the tube... unless that is what you meant.

Also, I fully intend to have the tubes involved in core gameplay... they'll just be underground. I believe I mentioned that in my post...? They'll still be used to transfer colonists, resources, and data from one structure to another. Actually I'd think a tube underground would be a valuable use of resources, as it wouldn't be as easy to be damaged and thus safer from threats... well except for earthquakes.

I thought that power was transmitted wirelessly, as the reactors and other power generators aren't connected to the tube network, in Outpost 2. Afterall there is those big microwave dishes on the top of each reactor... right?

An enemy earthworker getting into an enemy base to rip out one of your tubes? Sounds like a design oversight to me rather than an intended feature. An ingenious and inventive solution, but not what I'd say the Earthworker was designed for.

As far as C++ goes, I intend to refresh my knowledge on it before I start doing any coding.


That's kind of the intent of having them underground and in their own interface. The intent for tubes is to have a relatively safe way to transfer people and resources from one place to the other. Thus having them above ground would be a safety hazard. Also, when is the last time someone saw an AI try that tactic? I'd say that its more of an issue of unintended logic that wasn't properly designed as the developers didn't consider players using Earthworkers in that manner.


I'm sorry, but I don't get the reference... could you clarify?


I'm not proposing the elimination of the tube system. I'm simply preferring tubes to be built underground where they are relatively safe than to have them above ground and be a prime target for an attacking army.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on September 27, 2015, 08:06:36 PM
I'm actually rebuilding Outpost so yeah, I know it had a whole underground structure.

I was going off the context of OP2... I thought it had a slowing effect as I understood the tubes were mostly underground but not entirely. Eh.

And yeah, I think it was an earthwork,... or something like that. I remember seeing it coming up and though that's weird and then it self destructed and I lost the game. I was impressed.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on September 27, 2015, 08:32:48 PM
Well, consider this. As the Robot Command Center calculates the optimum route to a destination, if you have tubes going to that destination, vehicles will prefer to travel over the tubes rather than rough terrain. If tubes provided a speed reduction, you'd think that vehicles would prefer rough terrain over tubes, as it wouldn't like include a massive speed bump (ie the tube).

If you read the DIRT or the Consumer Factory blurbs on the wiki, it makes it sound like the tubes were fully underground, rather than partially sticking out of the ground.

It would have to be the earthworker as they are the only thing I know of that damages tubes, much less destroys them. Even a supernova tiger doesn't damage tubes when it detonates or a massive earthquake centered on the colony. The only other thing that destroys tubes is lava, but that is logical that it would do so.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Highlander on September 28, 2015, 02:49:02 AM
The Earthworker tactic only works on small maps with open base access and in LR games on small maps or with close starting proximity.

1 Earthworker may destroy up to 3 tubes before it is destroyed. So the damage is actually limited as long as you have your own earthworker around.

Surely an annoying thing, but it is not an autoloss.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on September 28, 2015, 12:43:26 PM
Anywho, anyone else have some comments on the initial questions on the first post:

1) I was wondering what kind of features would people here like in a game "based" on Outpost 2 as inspiration?
2) Are there specific things that irritated you with Outpost 2, that if you could you'd want fixed in a game like Outpost 2?
3) Are there specific things that you feel made Outpost 2 unique and without them it wouldn't feel the same?
4) Are there any things that particularly interested you with Outpost 1, that you wish Outpost 2 had?
5) I'm aware that a previous Indie Development Team had attempted a game similar to Outpost 1 (Terminus I believe it was called) and failed to achieve kickstarter funding. Do you perhaps know why it failed, so that I could avoid whatever problems they had?
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Arklon on September 28, 2015, 02:57:45 PM

I'm sorry, but I don't get the reference... could you clarify?
It was a joke map Mcshay made years ago (before he fell off the face of the Earth) that consists entirely of tubes. :P
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on September 28, 2015, 03:18:08 PM
What irritated me about Outpost 2:

The controls. Very non standard.
No build queues.
Weird way of setting paths for cargo trucks in mines. Should simply be set it to go to a mine and then it automatically goes to the nearest smelter.
Research Tree could be easier to manage.
Too much focus on click speed and combat -- some of us like long colony type games.

Outpost 1 and Outpost 2 were two entirely different games... they had similar elements to them but I don't think things from Outpost 1 would really fit well into a real time game.

Why it failed?

No prior experience. Nothing produced by the team to date. Not enough interest because of poor marketing of the kickstarter campaign. Can't just throw something on Kickstarter and hope it'll gain attraction, you need to force it into people's lap. I would have loved a new game that was basically Outpost but with a modern rendering engine but I had no idea such a project was on kickstarter.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on September 28, 2015, 05:47:50 PM

Ahhh, thanks for the clarification.


Could you explain for me? "The controls. Very non standard." (Being that RTSs were not extremely common in the 90s, most RTSs held that the way C&C did RTSs was the standard, so do you mean that the controls in Outpost 2 were much different from C&C, besides the obvious difference in the way structures are built/placed)

Yes, I do wish to do build queues as well as the special kind of queue found in Supreme Commander where you can set it to continuous build a single unit or continuously build a specific set of units in a set order (ie Build Unit A, then Build Unit B, then Build Unit C, and then repeat, starting with Unit A again)

Yes, I intend to do something about mining routes. It might appear simpler to have them hunt for the nearest smelter, but that might be a very costly pathfinding calculation, especially if there are multiple trucks all fighting over who gets to go first and second.

I intend to do research trees a quite a bit differently for the game I'm designing. Each major topic (ie Entertainment or Construction or Tanks) will be a separate tree, with specific advantages and disadvantages in focusing in on one tree over the other. Several trees will also allow for reaching a specific goal in multiple ways so that if a player focuses down on one tree they will still unlock specific techs (ie having multiple ways of researching how to build a Spaceport as an example).

I believe that multiplayer was tacked onto Outpost 2 rather than it being designed from the ground up to work for it. I say that because most players play the game like a traditional C&C style RTS that focuses solely on getting combat units out, focusing on warfare and disregarding the entire colony aspects which makes Outpost 2 unique. The problem with long colony games in multiplayer is that games will be long and multiplayer is often best designed for short skirmishes rather than stretched out wars.

I also did prefer colony management over combat myself. One way of forcing a player to rely on colony management in a multiplayer match is to have something similar to real life: War Fatigue. As a war between two countries drags on, the population of each country gets tired of war... much like what happened with Vietnam or Iraq today with the USA. So, as battles drag on between two or more colonies, it causes War fatigue that gets worse the longer battles continue going, causing a massive morale penalty that only goes away when you stop engaging the enemy in battle.

I also agree that many of the elements in Outpost 1 wouldn't fit into Outpost 2 such as:
-> Underground structures
-> Massive numbers of resources to keep track of, (ie MetalA, MetalB, MetalC, or Fusion ElementA, B, C, D E, etc.)
-> Too many things that the player must keep track of at a time


When it comes to no prior experience, could you explain that for me? If a development team's first game is the one of kickstarter, what kind of previous experience would they have in making a game together?

My experience is that most teams that fail to raise money, abort the project and move onto something else, or alternatively refocus their scope and attempt to redo a funding drive but often with reduced features and reduced money they are looking for. Why should a development team continue to develop something that no one wants though?

Yes, poor marketing is almost always lethal for a game and the expectation that something will get funded on Kickstarter is also not a guarantee. Most of the most successful kickstarters did some advertising for their campaign before it started, spent a lot of time creating the reward tiers and the kickstarter page itself, often did several updates often uploading new images/video/comments from the team, often answering people's questions daily, and basically just being active with the campaign spending 4+ hours a day each day every day for the entire length of the kickstarter to show that they are trying to make it happen. It takes work to be successful and throwing something up on Kickstarter without doing the work will chase possible investors away from you.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on September 29, 2015, 09:39:01 AM
By non-standard controls I mean by today's standards. It makes it very difficult to get into Outpost 2 when it doesn't control like the typical RTS does.

If a team is newly formed and has nothing to show for themselves, they are not going to garner much, if any, confidence from backers. If I was looking for a kickstarter campaign to fund, I would quickly pass by a team that has no development experience or prior work. It's great that you have a few talented individuals but this day and age, talent isn't enough. You need drive and motivation and unless you can demonstrate you have it (by showing some sort of prior work, even if it's just a few simple games or other programs or hell, a playable demo), I'm simply not going to invest. I can't be the only one like this -- I'm not that unique.

So it comes down to this -- having talent is great. But if you have never produced a game before, you're not going to get noticed unless you can convince people that it will actually happen. Having money isn't enough. You need good team management and someone who can take responsibility for pushing a project forward (aka Project Manager). If you can't show that you have the ability to complete a project, you're not going to get any backers.


Been reading some of the previous responses on this thread and first and foremost I have to address SirBomber. Stop. Just... stop. You're aggressive and negative and it's not appreciated. Seriously, just chill.

Moving on, Lordpalandus, your response about the way you intend to go about this suggest you don't understand what it takes to build a large project like this. Not surprising, really, but you seem to also have a real motivation to make something happen. We chatted a bit on IRC and you also seem to understand that it's better to prototype some core gameplay elements early on so you have an idea of where you need to go.

I'm going to still recommend that you do some prototyping so you have a better understanding of the mechanics involved. You mentioned you wanted to use UE4 -- it may be open source but I don't know if it's up to the task. XCom used the unreal engine and it demonstrates that it can be modified for other game types but I don't know if RTS is one of those.

Also, if you don't have a firm grasp of pointers within a year of working with C++, you're in over your head. Move on to a different language that doesn't let you use pointers.

Pointers are an amazing way to speed things up but they're also an amazing way of creating really annoying bugs. Plus, if you don't have a firm grasp of them and how they work, you're going to get yourself into trouble in a language that relies on them and references. I guarantee UE4 makes liberal use of pointers and references (as most C and C++ programs do).

I would still recommend C# as a good alternative. You may need to change your tech plans (e.g., Unity instead of UE4) but C# is much better for novices and it's a lot easier to pick up. You may even want to consider a prebuilt engine like Spring.

I'm not trying to be discouraging, I'm just suggesting where you're going to run into roadblocks and how, if you're truly serious about making this project happen, you can do that with the least amount of pain.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Sirbomber on September 29, 2015, 07:10:38 PM
I have to address SirBomber. Stop. Just... stop. You're aggressive and negative and it's not appreciated. Seriously, just chill.

1) Do you see a capital B in my name?  Didn't think so.
2) Excuse me?  What prompted this?  I do not appreciate unwarranted personal attacks, leeor.  I have done nothing but state my opinions and thoughts regarding this project; same as you.  You do not have the right to tell me to stop because you disagree with what I'm saying.

Now, can we go back to talking about this project and stop flaming people for no reason?
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on September 29, 2015, 08:25:56 PM

That's kind of what I had thought you meant by nonstandard controls. Thanks for the clarification.

Well what I had intended to do is build about 30-50% of the game and have it in a demo-ready format and offer that to backers to see what I'm capable of. I highly doubt someone would invest in a project unless they had some way of knowing that it wouldn't be a lost investment. I had considered doing a pre-campaign thing for about a month or so with giving out the demo to people to try out before the campaign started so that people were interested in the campaign before the campaign started. But that's just my strategy.

Would a partially completed demo be a sufficient way of proving that a person could complete what they are saying they can complete be sufficient proof?

Sirbomber's skepticism is to be expected. I'm a newb with a lot of drive and motivation, but still a newb. I get the skepticism of "I don't think you can do it" a lot, from a lot of different people. If I actually listened to that I'd have thrown in the towel a long time ago. I understand people's concerns that I may not be capable but only time will tell that or not; practice does make perfect but practice does take time. I appreciate that you guys are willing to give me criticism even if its the kind that is very demoralizing. Comes with the pursuit of community involvement. I don't expect that you guys should trust me just because I say things. I would only expect that you guys think I can do it if I had some proof of it. Otherwise I'm just like many others who came here with false promises and never delivered. I would rather not be another in a long line of failures but it can happen... generally when the motivation runs out. I came to get community input to design and eventually develop a better product. It is to be expected that not everyone will trust that you are capable of doing it especially as others with greater talent have tried and failed before you. So, if you guys are worried that this project will go that same route, then I'd suggest not getting too involved in it. I intend to be fully involved in it with the intent of succeeding against all odds (something I'm well aware of throughout my life). It takes a lot of work to do it and I'm willing to do it.

When I get to developing the basics of RTS (interface, commands, selection, etc), I'll be able to better assess if UE4 is or isn't an ideal engine to do things in. Until then, it is a bit of a moot point. If it isn't ideal, then I'll look at alternatives. However, it may turn out that it is ideal and that it doesn't require a huge overhaul of the engine to make it work as a RTS. Time again, will tell. I appreciate the suggestions for alternatives, and I will weigh the choice of engine once I'm farther along and have had a chance to see what can or cannot be done.

I do understand pointers, more or less. Its just that I haven't practiced making programs with them yet, as my interest in C++ waned for a time when I was extremely depressed for several months and decided to instead focus on less mentally strenuous stuff until I had recovered my mental state. Then... burnout hit, and now I'm recovering from that as well, so... on both fronts I'm doing quite a bit better and living life better, but I'm not quite at the point where I'm ready to deal with C++ again. I intend to do a refresher on C++ before I touch UE4, to ensure I do know everything. I do find C++ to be fairly straight forward and easy to understand (moreso than C#) so its more of a lack of practice with the language at this point.

I also do appreciate your concerns and suggestions concerning roadblocks in understanding. You have a far greater knowledge of C++ than I do and likely working knowledge of its ins and outs as well.

@Sirbomber v Leeor;

Just to be clear, I didn't find anything either of you said to be negative. Cold hard, blunt, realistic maybe, but not negative. I appreciate both of your concerns of my capability with the project and if you feel that I'm not capable then it might be best to distance yourself from it in case I do happen to lose interest. That way you won't get hurt. Right? Or would you get hurt anyway? Hmmm....

All I'm saying is that I do intend to do it and am well aware of the massive mountain of difficulty and complexity that I'm trying to scale and overcome.

Edit: Made a change to first post indicating that there is a forum discussion on NTSC as well; link on first post.

Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on September 30, 2015, 06:48:09 PM
Practice with the language... it's kind of an understatement. As much as I love C++, it's a real pain in the ass to work with sometimes. But you begin to learn its quirks and when you develop code you know exactly what caveats to watch out for.

That said, I say go for it. If you've got a good plan of action and have realistic goals, don't let others judge you. Just make sure the goals are realistic and attainable. When I started with Outpost 3: Genesis, I made the mistake of setting unattainable goals for myself. I'd never worked with a 3D engine, I'd never developed anything more fancy than a 2D tile map, I had no idea what it took to build an RTS and I focused on all of the superfluous things (like title screens, polished 3D models and flashy shader effects) instead of the things that mattered (like core gameplay mechanics and gameplay elements).
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on September 30, 2015, 10:49:47 PM
A lot of things are going to be a real pain to work with, until I learn how to use them properly. The most difficult one for me is likely going to be learning how to do basic manipulation of sounds and creation of textures, as graphics and sounds are not my forte. But as I'm soloing it I'm going to need to learn them as well.

Well I have a variety of pre-development goals that I'll be working on before any major development occurs... many smaller prototypes and likely much failure and then learning from said failure. Most of my goals are "SMART" (Specific, Measurable, Achievable, Realistic, and Timely), though some of the later stuff after learning the basics are not too fleshed out as they require knowing the basics first before assessing how to go about doing them.

I'd have thought it would be better to work with basic models and textures (or an untextured completed model), work out all the underlying code, then start adding in the rest of the content = sound, music, textures, fancy effects, etc, basically all the graphics and sound related stuff.  Once you know the code works, then you can focus on adding all the extras on. If the basics don't work, then any of that other stuff might become obsolete and get thrown out anyway.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on October 05, 2015, 10:53:36 PM
Yes, I'll be sharing the design document. I think getting some input on the design document when its "finished" would be helpful and useful for me;
I would suggest working on the design document in an open manner, so sharing and discussion can happen before it's "finished". What exactly does "finished" mean anyway? In software there is always a next version. The input will be more useful before something is finished. It can save you time to fix problems early, and continual feedback will help keep you motivated.

As for tube tiles, they provide faster access than rough terrain, but slower access than bulldozed ground. They are essentially bulldozed ground with speed bumps from partially exposed tubes. :p

Earthworkers take damage when they cut active tubes. Each time they cut an active tube, it takes away about 1/3 of their health. They will explode upon cutting a tube that damages them too much. I believe this is to limit the number of tubes you can cut in an enemy base. I'm pretty sure the designers intended this as a tactic. There is no other clear reason to cut tubes. You can always just build on top of them in your own base. You could claim movement speed, but the difference between bulldozed ground and tubes is minimal.

There are certain conditions where cutting tubes can cause someone to lose. In particular if they have no metal left to rebuild the tube, and no structures to deploy a bridged connection, then the game becomes unwinnable for them. I don't believe the game does very sophisticated checks in this area though, so it's probably possible to fail a mission when you might still be able to win. Like how losing a main CC can cause you to lose even if you have a backup CC that is simply offline. Also, when refineries and silos are idled, they lose their storage. When EMPed, the refineries I believe keep their storage, but silos lose their storage. I'm not sure what happens when their tubes are cut. It might make them both lose their storage, in which case, that would explain failing the mission.

This thread is getting quite long. Perhaps it's time to start generating a document from the ideas discussed.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on October 06, 2015, 10:23:00 AM
Well... when I say finished I mean that I've analyzed most of the features I do or don't want and thus have settled on how the majority of it will work out. This is to avoid excessive feature creep, which is often a very dangerous thing as it can push the game's scope way out of control. Its a problem that two projects I follow have run into (Star Citizen and Space Pirates and Zombies 2); both of these have allowed far too much feature creep into the projects and thus are taking many months to years longer to develop. The reason I want to have a basically "finished" design document is so that the product I intend to create will be easier to predict how long it will take to produce and thus I can better guage how much it will cost to produce and how much it might cost to pay others to help produce it. Now that doesn't mean I wouldn't accept more features its just that I'd have to heavily weigh in whether or not I should add the feature in based on how useful it is or consider patching it in after I'm done rather than delaying development to add it in right away.

However, a finished design document isn't going to happen any time soon. I can definitely put together a preliminary design document of the features I'd like to have in it, but that is heavily subject to change. The reason it is subject to change is I still need to determine which features are feasible or not in UE4. If a feature cannot be made into a basic prototype to determine if it is feasible, then it can't be included in the game. I have a long list of gameplay-based features that I'd like in the game and a long list of engine / framework related features that I would like in the game. So, I need to do a lot of testing and prototyping to see what works and what doesn't work. Until I know what does or doesn't work, there is no point in having a "finished" design document. Basically the purpose of the finished design document is to use it as a guide to allow me to build the game like an intricate jigsaw puzzle; each part of the program has to fit together with other parts of the program and thus having a design document helps me to remember what other parts will need to work with the part I'm currently building and how to lay down a framework for other parts to connect to it and it in turn connect to other stuff.

What I'm currently working on is refreshing my C++ knowledge, going through function calls again currently, and taking some indepth notes of things that I likely won't remember easily. Since UE4 will require some significant C++ coding to do work with it, I need to be able to design code, implement code, test/debug code, redesign code, and practice.

On that note, does anyone know where a good use of a globally declared variable would be useful? I know globally declared constant variables are often used, but what about global variables in general?

However, if a preliminary design document is desired I could cobble together what I currently have.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on October 07, 2015, 05:42:41 PM
Design documents written before code starts never end up representing the code. Think of it as a living document. It will change as code is written, flaws are found, and design and code are updated. It's futile to try and write it all up front and expect it to be correct.

Sounds to me like you are delaying. You want to talk and dream about it, but you don't want to work. :p

Start on the document.

<Insert plug about a journey of a thousand miles begins with a single step>

I can't remember the last time I declared a global variable. Maybe a generic handle to a sound system, where you only ever want a single object. A video system might be another example, but remember there are systems with multiple monitors. Or perhaps a data structure that is shared between threads, where the root of the structure is declared globally. Note that sharing data between threads is not sufficient reason to make something global. You can also pass data (such as a pointer to more data) into a thread that describes whatever needs to be shared.

Mostly I would only declare static read-only data globally.

On a slightly related note, it's much nicer to only have to share read-only data between threads.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on October 07, 2015, 06:33:19 PM
I'll start working on a preliminary design document then.

Actually, I do want to work on it. However working on requires an understanding of how to convert ideas/"dreams" from the mind into something the computer can understand. That requires knowing C++ and knowing how my C++ code will interact with the Unreal Engine. Not all dreams are feasible and thus practical prototyping is required to determine what works and what doesn't. I thought that would be fairly clear to someone with a huge background in coding...? Dreams on paper are just that, Dreams. They need to be converted into code and then that code tested to see if that dream is feasible or not.

I'm also not delaying. Even though I lack a computer to prototype ideas on, I still end up prototyping ideas on paper and seeing how various things interact with eachother to see if I'm missing something or it could be considered complete. I haven't bothered with a Design Document because week-to-week many things change; some things are improved upon, some are thrown out completely. Thus my design is always in flux. A design document to me, is something that is reasonably set in stone, but still flexible in being modified. My current design for the game isn't quite there yet. There is several areas I have not even touched on yet.

The other problem is that about 50% of my ideas and design are on my development computer which is in the shop at the moment. The other half are scattered throughout my iPad and this computer I do word processing on. I can certainly put together what I have right now but its nowhere going to be near being complete or fully fleshed out.

Also, finally the design document I was referring to was intended to be created AFTER I had tested out most of the ideas with it in various prototypes to ensure that it would work and thus the design document would be representative of the final product. My idea for a design document is clearly different from your view on a design document; my view may be impractical, but it is what it is.

EDIT: What format do you want the Design Document to be in? Doc? DocX? Google Document? .txt? etc
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on October 07, 2015, 10:45:55 PM
I was going to suggest a google doc. It's easy to work on from most devices and is easily shared.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on October 08, 2015, 01:05:52 AM
That's kind of what I was thinking as well. So I'll get on with that.

EDIT: Link = https://docs.google.com/document/d/14gyJIIFiPd3nLKRqhVE-t7376VqwSdjoh0ActRrywyA/edit?usp=sharing
NOTE: I'll update it as I accumulate the information I have available to me and what I can remember that is stored on my Dev Computer (which is currently inaccessible)
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on October 08, 2015, 09:44:59 AM
One of the best things about Google Docs is that it saves automatically as you work with it and you don't have to update the link! :D

So a few thoughts as I'm starting to read over your current DD.

The Story
I know it's fiction but there are a couple of holes.

First, I'm pretty sure a ship built by us without star trek like shields and integrity fields and so on would be torn apart by whatever distortions would come from a worm hole. Granted this is all theoretical and we don't know that worm holes even exist but theoretical physics does predict the presence of worm holes... except that they're tiny. Like microscopic tiny. So that alone immediately breaks the suspension of disbelief. May want to consider something besides a worm hole.

Assuming we stick to the worm hole story and assuming that the ship is torn apart or crushed like a bug, after 10 years suddenly arriving at a star system, I doubt the computers would think it's the true destination. Computer software sophisticated enough to continuously monitor a ship's functions while the crew are in cryosleep would also be sophisticated enough to detect the anomoly and determine that it's approaching an unknown star system. It would have probably instead woken up key members of the crew to make a final determination of what's going on.

Also, the captain would probably be able to triangulate their position based on pulsar information -- that's how we determined where we are in our own galaxy and how we tell aliens via Voyager 1 how to find us -- so he probably wouldn't say "Nope... no idea where we are".

You have some great thoughts here and I like all of the suggestions but Tier 1 alone will be a challenge to develop let alone Tier 2 and Tier 3. If you absolutely must include other tiers, I would stick to 1 and 2. Either way these are all ambitious goals so maybe you should focus on Tier 1 and leave the others for another game.

Grandiose goals lead to burnout which lead to failure. Take it from someone who has failed many, many times. I learned the hard way that you absolutely need to start with goals that are attainable. You also need to know your limits. Since you're just starting out with C++ and the UE4 engine, the Tier 1 gameplay will be enough of a challenge without also trying to build two other entirely different levels of gameplay on top of it. So stick with a colony management RTS, finish it, and then go from there.

...is to develop tier 1 to about 70-80%..

Unless you're careful, the last 20 - 30% of development will take 90% of the time. Make sure you set concrete goals and milestones and don't ever, ever allow feature creep or you will never finish. Ever. You'll end up with Battlecruiser 3000AD. That is not a good thing.

I see you actually modifying the DD now so I'll hold off any further notes or thoughts I have on it.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on October 08, 2015, 10:37:37 AM
Yes, the story is quite a bit WIP. I haven't put too much time or thought into it as the campaign would be built or not built after the funding drive was determined successful or not. The focus on Tier 1 is to show possible investors what I'm capable of, show that I can complete it, and show that the gameplay is actually enjoyable to play and not a bore fest.

I actually don't know that much about wormholes actually. My understanding of wormholes comes from the wormhole in Deep Space Nine, or the wormhole in Farscape; both of sufficient size to encapsulate a starship and both deposit ships entering them a good distance away, from the entry point. I did not know that in reality, most wormholes are far too small to for something as large as a colonization ship.

Alternative ideas to a wormhole, could be a subspace tunnel, such as in Star Trek Voyager, a time hole, such as in Red Dwarf, or a "black hole" like in an older game called Gravity Well.

Its true that computers sophisticated enough to plot a journey to a star system, probably wouldn't be fooled by a brand new star system into thinking it is its destination. Though, I'd still think the computers would want to wake up the human crew to determine where it is.

Also, didn't know about Pulsar information, or how scientists encoded in the Voyager probe how to find us again. I don't have a huge hard science background... as I'm not a NASA scientist, which is what Outpost 1/2 had on their team.

Gameplay... That's kind of what I've been thinking. The interface for Tier 2 and Tier 3 will be completely different and will play entirely different from tier 1. Tier 3 will definitely play the most differently, as it will play like a real-time strategy equivalent of Master of Orion, so it might be best to keep that as it's own separate title.

Lots of things lead to burnout. Also, still working on my burnout. SMART goals and SMART goals of the SMART goals is what is needed (Specific, Measurable, Attainable, Realistic, and Timely = SMART). What I mean with that is that the goals need to be SMART, but also how I view the approach to solving those goals and how many goals I try to accomplish at the same time need to be SMART.

My experience from watching developers create games, is that the last 20-30% takes the longest because of poor planning (as in no planning is done period) and poor design (constant iteration is great for a prototype, but not so good for a complete product) of the code leading to a lot of bugfixing, balancing, and more bugfixing. If code is well designed, and things are planned out carefully, the last 20-30% should take about as long as the rest of the work. The problem is that since most game code gets rushed in the industry, the last 20-30% takes forever as you have to unravel your "spaghetti code" and find where one problem starts and another ends.

What is Battlecruiser 3000 AD?
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on October 08, 2015, 11:23:07 AM
I feel my reply has become partially obsolete while writing it, but whatever, here it is.

However working on requires an understanding of how to convert ideas/"dreams" from the mind into something the computer can understand.
I partially disagree. You don't actually need to code or know how to code to start writing a design document. Initially you just need to know what the game is about. If you can describe the game from the viewpoint of a player then you should be able to write a decent start to your design. Keep in mind that design documents are not really standardized, their scope varies a fair bit, as does the scope of the projects they describe. Sometimes a design document doesn't contain code, prototypes, or diagrams. Ideally though, it should be complete enough that there is no ambiguity about what features go into the game, and should eventually provide enough detail on how the features work to implement them. Saying there are multiple weapon types and amour systems is a start, but too vague for a final version. Saying what the weapon types are, and the equations for calcuating damage based on weapon and armour is better. It doesn't need to be actual code, but at least a mathematical equation would be a good idea. Describing the high level idea, feel, and flow of a game should come before implementation details. The initial part of writing a design document is then more of a technical writing skill than a coding skill. It's only when you start drilling down to the details of how something is implemented that coding skill becomes important.

Not all dreams are feasible and thus practical prototyping is required to determine what works and what doesn't.
If you keep the design open, it's possible for more experienced programmers to catch ideas that aren't likely to work. Fortunately though, having to solve NP-complete problems and the like in a real-time game isn't an issue that typically comes up. If you can dream up an idea for gameplay, there's a pretty good chance it can be implemented. If it really is a bad idea, that often comes out pretty quick, even before code is written.

Not everything needs to be prototyped first, and certainly not at such an early stage. Prototyping is probably more useful to test a possible implementation of a program feature, rather than as part of a design step that determines what features are present. It would seem very strange if a prototype was driving the design, rather than a design determining which parts to start prototyping. Why build something if it wasn't a needed feature? Why have features that might not be possible to build? That would be more of a research project than game design.

The other half are scattered throughout my iPad and this computer I do word processing on.
All the more reason to start collecting things into one place which can become your authoritative source of information on what the game is and how it will work. You do need to nail things down at some point.

I can certainly put together what I have right now but its nowhere going to be near being complete or fully fleshed out.
It will never be complete if you don't start. ;)

I don't know if you've noticed this, but if you re-read your post, a few parts sound like excuses. I'm not going to debate the validity of them, I'd just like to bring up the mindset of this. It's sometimes a little too easy or convenient (lazy) to find a reason why something can't be done (now), rather than make a decision on the next actionable step. Certainly things won't always go according to plan, but that's not really the point. If you need to wait on something, then make a note to revisit when the time is right, and move on to something else where a decision can be made. Putting things off is easy, making decisions is hard. Decisions are needed for progress.

I am very guilty of putting things off and making excuses myself. I've come to realize that making excuses doesn't help get things done. Coming up with small actionable next steps does help. The most productive people I know always have a small next step to work on. The least productive people I know always have an excuse.

Lately I've often found myself grudgingly try to turn excuses into small actionable next steps. It's hard, I know. I am painfully aware of this.

With that said, I'm glad to see you've made a decision on the format for your design document and actually got started on it. I'm actually impressed. I wasn't expecting 4 pages already. Wait no, 8 pages now? Wow, you're really moving. Good job. I have some reading to catch up on now.

That SMART stuff is exactly what I was trying to get at.

Also, I had similar thoughts about the wormhole idea. I was thinking maybe just leave an air of mystery about it. The crew is woken, the ship has arrived at an unexpected destination. Perhaps they don't know where they are, perhaps they don't even know how long they've been travelling. Maybe there was a computer glitch, maybe there was a wormhole, maybe they've just been travelling for a very very long time, much longer than expected. Give the reader/player something to wonder about. Give them something to discuss. Probably better than giving them something to refute.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on October 08, 2015, 12:09:54 PM
Hmm... very good points on the design document.

Also, good point on dreams. If an idea sucks, you are right it will usually come out quickly enough.

I only mention that I'd need to do a variety of prototyping because UE4 isn't technically designed out of box to support RTSs. The developers at Epic have said it can be converted to an RTS, but an RTS isn't an immediate gametype available to a game developer. I had looked at UE4 several months ago when I was developing an RTS idea (completely unrelated to this game) based on Majesty: The Fantasy Kingdom Sim, to determine the feasibility of making it work for an RTS and determined at that time that it was between highly probable and extremely probable that it could be used to create an RTS in it. However, I haven't touched UE4 since then, and since then two new major updates have been released for it and thus I'll need to refresh myself on UE4 to see what is new, changed, or possibly completely removed and adjust my thinking patterns to match.

Also, good point on putting things together in one place. That does actually make sense. Thanks for the suggestion to start on the Design Document.

Now on to the excuses part... for me I don't see them as excuses, but more as a fact of my current reality. I'm still suffering through near burnout, and am recovering daily and weekly such that my productivity has been improving, and my quality of life has been improving. I would like to be doing at least 8 hours a day of work, however with my current level of burnout, I can at best get 1-2 hours of work in without feeling extremely exhausted. This is a great improvement over a couple weeks ago when I was barely able to do 30 minutes of work on the project. I'm improving, but recovery from burnout is a slow process. Whenever I try to take on more work than I'm capable of, I feel extreme exhaustion, that usually affects me for several days and thus I get very little done when I'm exhausted. In between working on the project though, I am working on improving my mental and physical health (as these are the things that heavily affect the burnout the most), by doing weekly reflection, critically analyzing problems, devising solutions and implementing them, and then reflecting on those changes a week later to see what worked and what didn't, and go from there. I've been noticing great improvements in all areas of my life over the past few weeks after I had started this major change in my life however, I am not quite there yet.

Thus, I avoid adding too much additional work onto my plate. I know right now, that adding work on without being able to cope with the extra load will just cause overall worse productivity. Its better to work at the level I'm currently able, and then setting SMART goals on improving productivity and such forth. That's why I said that I not only need SMART goals, but also SMART goals of the SMART goals. The goals themselves might be SMART, but if I have too many goals, then I might not be able to achieve them. And I find that when I fail a goal I set for myself, I feel like shit for days afterward. So I want to create enough goals that I'm challenged, but not so much that I can't complete them all.

I guess the purposeful avoidance of work to avoid burnout could be construed as excuses, but I literally do not have the resources to overwork myself at this point. Perhaps in a few weeks, that may be different. However, with that said, I'm finding that working on the Design Document has improved my productivity by quite a bit, and I managed to get more than my usual 2 hours of work per day and increase it to about 4 hours. Perhaps, some of my lack of productivity stems from writers block...?

Finally, I really like the idea of mystery. Certainly solves the wormhole problem. I like it. Thanks! I'll make the story changes now...

EDIT: Also, I'll add the link to the design document on the first post so its easily accessible and make a post on NTCS about it as well. That is, when its back to working status.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on October 08, 2015, 01:31:20 PM
Quote from: lordpalandus
My understanding of wormholes comes from the wormhole in Deep Space Nine

Star Trek is not reality. It's a great story. But it's not real.

Quote from: lordpalandus
I don't have a huge hard science background... as I'm not a NASA scientist, which is what Outpost 1/2 had on their team.

I'm no scientist but I do make an effort to understand things when I want to talk about them. Wikipedia is a good starting place.

Also, Outpost 2 had no involvement from the original Outpost team so there were no NASA scientists on board.

Also, Outpost is a perfect example of why you DON'T want scientists designing an entertainment product.

Quote from: Hooman
Also, I had similar thoughts about the wormhole idea. I was thinking maybe just leave an air of mystery about it. The crew is woken, the ship has arrived at an unexpected destination. Perhaps they don't know where they are, perhaps they don't even know how long they've been travelling. Maybe there was a computer glitch, maybe there was a wormhole, maybe they've just been travelling for a very very long time, much longer than expected. Give the reader/player something to wonder about. Give them something to discuss. Probably better than giving them something to refute.

I like this idea better. Computer glitch with a travel time far exceeding what was originally expected, getting caught in the gravity well of a totally different than intended star system is what caused the computers to wake up the commander (I recommend commander because that's how the player is referred to in Outpost and Outpost 2).

Quote from: lordpalandus
however with my current level of burnout, I can at best get 1-2 hours of work

So then stick with 1 - 2 hours a day and do first what you can do most efficiently. Right now, design seems to be the key. Take the time to design the game. Develop the DD. What Tech to use and language and all of those details can come later. But without a specific goal in mind with concrete set features and what exactly the game will do in terms of providing a fun experience you will end up with another Outpost 1 or Battlecruiser 3000AD (btw, it was a notorious failure from the 90's that was in development for 10 years, switched publishers at least 5 times and was released unfinished and very, very broken -- I had mentioned it as an example of feature creep).

I'm also hearing you use a lot of buzz words. They're fancy and sound good and make a lot of people feel warm and fuzzy but the reality is you're going to end up doing whatever it takes to make the game work.

In the industry you don't have time to make everything perfect. Sometimes you just have to roll your face on the keyboard for awhile to make something work and make it pretty later. I did that with OutpostHD so far and look, I actually have something almost playable. I've had to go back and refactor some of the code because of major inefficiencies and terrible design choices and there are other areas that I need to fix as well but those parts can be fixed later, right now I just want to get the core gameplay elements working.

Hooman is also right about another thing -- sometimes you just have to make decisions. That's the hardest part. There are times when you're going to sit there mulling over what you should do next... I do it all the time. The difference with OutpostHD is now, I just force myself to pick a specific problem and tackle it even if I haven't fully fleshed out how I'm going to do it. It's not pretty, it leads sometimes to some pretty messy code but if it does what I want it to do and it's not absolutely horrifying, I call it a day and move on to the next challenge.

You will not have perfect code. Period. So don't try or you have already set yourself up to fail. We are humans with poorly evolved, very limited monkey brains. We are not perfect. We make mistakes and our designs aren't always perfectly elegant. Unless you're a coding savant (get it, savant? eh? eh? no? okay) your final implementation will probably leave much to be desired but if the code does what it's intended to do and the game actually works, you've succeeded. You can go back and make it better later.

There are some coding sins (http://thedailywtf.com/articles/classic-wtf-line-by-line) that are unforgivable but I don't think anybody here is on that kind of a level.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on October 08, 2015, 02:25:44 PM
That is true, but a videogame often defies logic, though I'm unsure if that is a good thing or not... like in the Last of Us where it takes 4 scissors to create 1 shiv. Game logic!

Really? I thought that the same team that did Outpost 1 did Outpost 2. And yes, Outpost 1, despite appearing interesting, is a prime example of not to get an outsider who knows pretty much nothing about coding or games to design the code for a game.

When all else fails, mystery works fine.

Yes, I'm well aware that having concrete, set in stone goals are needed; hence why I don't really want to get too set in stone right now as I need to do some prototyping. But I'm not quite there yet. As stated in the Preface, things in the DD may get changed, improved or removed entirely as time goes by. Something that I thought would be a great idea may be implemented better in another way. Etc. etc. etc.

Battlecruiser 3000 AD, sounds a lot like Duke Nukem Forever. Also released in a huge buggy mess.

Perfect is subjective. Technically code that compiles, is syntacally perfect, as code won't compile with syntax errors, thus the syntax is technically perfect. However, ensuring that the logic is perfect is a not a good goal to work towards. I want the code to compile properly, while ensuring overall "good" logic and a minimum of possible runtime errors by building in contingencies. I do not expect to have perfect code throughout; good is good enough. The other thing with having perfect logic code being a pointless endeavor to work towards is that it is impossible to fully predict how a user will use the program and it is impossible to balance mechanics perfectly.

Rushing something out the door to make it playable isn't always a good idea though, as the product you are left with is essentially a working prototype. And as it is not a good idea to build ontop of a prototype and it takes forever to fix a prototype, it will take you far longer to develop it. Making the decision to partially develop some things while getting the game in a playable state faster means that its going to take you far longer to develop it than if you took the time to carefully design each part, rather than over-abuse stubs and other bits of partial code. I can understand the necessity in many cases for people to do it, but I'd rather not go down that path unless I absolutely had to. I'll deal with this issue once I got a basic prototype up in UE4 ensuring that the basics do work. Just because you can change it later, doesn't mean that is a good thing, or a valuable use of time. Bugfixing is the real killer in development, and is the cause for dragging out development time; anytime you add a feature, you have to fix the code; anytime you remove a feature or change a feature you have to fix the code. Minimizing bugfixing by carefully designing things will save you hours and hours of headaches later. Its just my preferred style to development.

Coding Savant as in someone who is naturally good at coding, or Coding Savant as in a reference to the Savant-series computers in Outpost 2 and thus implying that I'd have to be a computer to create perfect code?

The only coding sin I know of, is where a disgruntled employee at Maxis got pissed off because they were laid off or fired (can't remember which) and renamed ALL of the variables in the source code to a variant of their name, with a letter or number at the end. I heard that it took Maxis years to undo the damage.

Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on October 08, 2015, 02:46:46 PM
Quote from: lordpalandus
Perfect is subjective. Technically code that compiles, is syntacally perfect, as code won't compile with syntax errors, thus the syntax is technically perfect.

Now you're playing semantics. You know exactly what I was talking about. :P

Quote from: lordpalandus
Rushing something out the door to make it playable isn't always a good idea though

Except that's not what I was suggesting. Rushing something out the door gets you Outpost. Or Daikatana. Or E.T. on Atari.

What I was saying is something you need to just make a decision and start plodding through the code. If you don't do this you will never finish. You will never always have good code. Sometimes you have mostly good code with a few very ugly sections. It happens. Note what's ugly, why it's ugly and move on. E.g., in my own code for OutpostHD I have several things like this:

Code: [Select]
Structure* _s = reinterpret_cast<Structure*>(tile->thing());
Robot* _r = reinterpret_cast<Robot*>(tile->thing());

Structure and Robot both derive from Thing. Tile's only store Thing's. In this case I'm casting from a Thing to a Structure  and Robot and proceeding. This is terrible practice in modern programs (though it's really common in a lot of legacy C programs).

How do I fix this? Stop storing the base class Thing in Tile and store Structure and Robot instead with their own get/set functions. I know the fix. I know how to clean it up. But it would require additional checks and more code in Tile to handle it all properly. Not that it's really a headache to do it but for now this works and I know how to fix it later when I've got other things fleshed out.

This is an example of "It does the job even though it's bad but I can fix it later and focus on other more important things."

Quote from: lordpalandus
Coding Savant as in someone who is naturally good at coding...

Really? -smh- You're taking things too literally. :P
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on October 08, 2015, 03:08:50 PM
Indeed :P

Daikatana the game that will make you it's bitch and will be the end of John Romero's career.  Or ET, the game that caused the first gaming crash :P Point taken.

So are you saying that sometimes its best to have something that is crude, but effective, over taking extra time to design something well, when the crude but effective would suffice?

Come on, seriously? Its the internet, how else am I supposed to take it? I can't tell if you are being sarcastic, rhetorical, literal, or metaphorical. Lol.

Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on October 08, 2015, 04:25:48 PM
Quote from: lordpalandus
So are you saying that sometimes its best to have something that is crude, but effective, over taking extra time to design something well, when the crude but effective would suffice?

Exactly. Crude but effective sometimes is good enough, especially if it's something that can be cleaned up later without being too painful.

Quote from: lordpalandus
Come on, seriously? Its the internet, how else am I supposed to take it? I can't tell if you are being sarcastic, rhetorical, literal, or metaphorical. Lol.

Touche. Can't really argue with that.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on October 08, 2015, 06:24:56 PM
UE4 is an implementation detail. It is subject to change.  ;)

Seriously though, you don't need to worry about whether UE4 will work when you're fleshing out what the game will be about. Granted, most people have some sense of the tools they will use, and a note about using UE4 might very well find its way into an early document. If the tool is good, use it. If it doesn't do what you want though, discard it. You're not designing a game just as an excuse to use UE4 are you? ;)

As for excuses, of course you don't see it as excuses. Nobody wants to see what they say as excuses.  :P

On a more serious note, I'm not trying to be a slave driver here. If you have other priorities, then so be it. You don't need an excuse to spend your time elsewhere. You're not required to put in a full day of work on this stuff. Hopefully this stuff should be fun, and not detract from other important areas of life, nor personal health. I'm just trying to foster the mentality that there is a small next step that you can work on. It doesn't need to be strenuous. Steps should be small for that reason, it makes them easy, and often even fun. I suspect you're finding yourself more productive because you've got a sequence of small next steps that you've been moving through, and because you're having fun. Momentum generates enthusiasm. You don't need to work fast, but it does help to keep at least a little bit of momentum.

As for rushing code out the door, no you don't want to do that to paying customers. But you should rush code out to people who are willing to test or play with early incomplete and possibly buggy versions. They can provide valuable feedback and suggestions for changes. It's better to learn what works and what doesn't work earlier rather than later. As changes are made they can be retested to see if things are improving. Design is usually an iterative process, not something done up front.

I should also mention that building on a prototype is not always a bad thing. If you fear prototypes and insist on throw away code, it might be that you just need more experience with refactoring code. It also helps to write test code, which helps with refactoring. You can make sure nothing breaks as you refactor the code. Some people take testing to an extreme with test driven development, where they write the tests first, then write the code. The tests are in a sense the design of how something should work. The tests are typically run first to demonstrate failure (which can help demonstrate the test code runs and worked), then code is written to implement a feature, and tests are run again to see if they pass, indicating a properly implemented feature (and hopefully good test code).

@leeor_net, I see nothing wrong with reinterpret_cast.  ;D

Actually, there are often ways around it for what you're doing by using virtual functions. Why exactly does that calling code need to know the exact type of the object? Can't it just ask the objects to do whatever processing is needed themselves through a virtual function on the base class? Often the virtual function call dispatch can be used to avoid casting of pointers to base objects back to pointers to derived objects.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on October 09, 2015, 02:07:35 AM

That is the intent. I am enjoying designing it and thinking of ways of how to implement it. However, I try to keep the amount of work under control so that it isn't strenuous and so that I can maintain that level of productivity.

Yes definitely, but how does that work for investors in a kickstarter campaign? If you promised them an alpha, does that mean you should rush the alpha out the door, or spend the time to polish it to give a good impression?

I hear about refactoring code all the time, and people who suggest it often are the ones that refuse to throw away a prototype and start over; they prefer to iterate on something that is best thrown away, learned from, and then do better the next time. They would rather spend the time fixing all the problems than starting from scratch. All of the online tutorials for C++ and my own C++ textbook advise HIGHLY against fixing a prototype and instead starting fresh. I have heard that sometimes its better to refactor if the majority of what is there is doing what you want anyway and thus fixing up the problems would actually take less time than starting from scratch. I suppose it depends on the situation.

Are you referring to driver programs (with the testing stuff)? I heard that using drivers can be sometimes better than using stubs to test code.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on October 09, 2015, 05:42:12 AM
That is unrelated to a Kickstarter campaign. Potential investors are not your beta (or alpha) testers.

Refactoring is an important skill. It's most useful when you have code that does what you want, but not the way you want it. The code might be messy, or slow, or use too much memory, or not support features that need to be added, or might not have the flexibility to support reuse. In that case what usually happens is a set of tests are designed to verify the current behaviour, then small incremental changed are made to the code, running the tests along the way to ensure nothing breaks after each change. You would probably also make commits to version control after each small change is completed and tests pass.

In contrast, throwaway code might not do what you want, or even anything useful at all. It might simply be to isolate a behaviour that you're not sure about. Questions like how does this object behave under these edge cases? Triggering the edge case might not be of value, and hence the code is throwaway, but knowing error conditions can affect how you'd write mainline code. You'd know what error conditions you need to check for around the edge cases, and what tests to write to ensure things don't break horribly at your edge cases.

A related aspect is bug hunting, where you might try to trigger an edge case to see if that is where a bug is coming from. In terms of the mainline, the code might be considered throw away, but in terms of your tests, it's not. The code that triggers the edge case can be refactored into a test.

As for fixing a truly terrible design that mostly does what you want, that really depends on the situation. Some people start new, some people try to iteratively fix. If the code is already part of a working production app, you'll most likely want to iteratively fix. At the very least you'd at least want tests to verify correct behaviour of both old and new code. If you're completely changing the underlying algorithm though, there might be little to no resemblance between the old and new code, and so no way to make small iterative changes. Still, the testing aspect still applies. You'd want the replacement part to be isolated and tested, and perhaps do a little refactoring to make sure the part being replaced is properly isolated before the replacement.

I'd also like to point out that nothing is perfect. If you're constantly throwing away code to start over and build something "properly", you might never finish.

A test driver is what runs your tests. It feeds the test case data through the code being tested.
A test stub simulates the behaviour of a missing component.

To elaborate on the stub, if object A uses object B, a test for object A might use a stub for object B rather than the real dependency. This could be for performance reasons, to avoid potentially unwanted external effects while testing, or possibly because B hasn't been implemented yet. It could be that object B represent a file system, a database, or an email server. While testing object A, it will make calls to object B, and you might want to avoid real changes to a file system, real changes to a database, or having email actually being sent to end users, thus you want A to make calls to a test stub for B rather than the real object. You can also use a stub to avoid non-deterministic behaviour. An example is when object B represent a timer, and so complicates testing due to unpredictable return values.

A test stub often has extra state methods, that can be used to test the state of the stub to check it has been manipulated correctly. There is also a similar concept known as mock objects. They are used similarly to stubs, but they usually verify behaviour rather than state. They might have checks to ensure certain methods of B were called by the tests on object A, rather than verifying the state of object B. As an example, testing state might entail an email server stub with an added method to return the number of sent emails (added state information, which might not exist on the real object), and then checking "numSentEmails() == 1". Testing behaviour might entail a mock object that verifies the "send(message)" method was called exactly once during the test.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on October 09, 2015, 02:06:16 PM
Quote from: Hooman
I'd also like to point out that nothing is perfect. If you're constantly throwing away code to start over and build something "properly", you might never finish.

Dis right here... dis is what I mean!

There's a time to throw it away and start from scratch and there's a time to refactor. Refactor doesn't necessarily mean fixing bugs -- the refactoring I need to do in OutpostHD isn't to fix a problem, it's to improve the code and make it more maintainable. But for now it does exactly what I need it to do and without being buggy or super sloppy or slow or completely inefficient. It's not perfect, it's a little ugly but it gets the job done and lets me focus on moving forward.

Quote from: Hooman
Why exactly does that calling code need to know the exact type of the object?

I don't want to hijack this thread so I'll be as brief as possible and will probably hijack it anyway.

Structure and Robot both derive from a base class type Thing. Thing does the bare minimum in terms of representing an object. It provides several functions for managing base properties like animation states, drawing itself, tracking age and knowing its name. That sort of thing. Structure and Robot, on the other hand, define their own interfaces that don't make sense in the base class.

Structures, for instance, in addition to being Thing's, also consume Resources, provide Resources, update themselves in specific ways concerning Structure States (e.g., operational, construction, idle, disabled, destroyed, etc.). Robots, on the other hand, do not do any of this. So for them to have an interface involving Resources would make no sense. Robots also have event callbacks; Basically, they raise events when they complete their task, something that Structure's don't currently do and probably never will (unless we really really really want to let the user know that a Factory has finished producing an item and is moving on to the next). So far, I'm only deriving Structure and Robot from Thing but there may be other objects in the future of OutpostHD which would derive from Thing so I wanted to keep its interface as uncluttered as possible.

Why does the code need to know what's a Robot and what's a Structure? Basically, it comes from the mousedown handlers, specifically when inserting Robot's and Structures. Robots and Structures are treated in different when they are placed in a map. Robots, for instance, only really need to know if there's something already occupying a Tile although the Digger does need to know on the sub levels if a thing is an Airshaft (which is a structure). When placing Structure's, though, the game needs to know if adjacent things are other Structures and if they are whether or not they can act as connectors (Tubes). This really is pretty limited so I opted to go with cast's until I came up with something a little bit prettier. Or, I can leave it as it is because of how limited this need to know what a derived type is.

This is a good example of it's not perfect, it's not even pretty, but it's effective, it does what I need it to do and it's not brutally inefficient. If I was iterating through tens of thousands of these objects, casting to derived types would be probably be an efficiency problem and could slow things down but in all practically in the cases where the code does need to cast to a derived type, you're looking at 6 casts at most (one for each adjacent tile plus up and down).
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on October 09, 2015, 03:26:30 PM
Technically, I'm not sure fixing bugs qualifies as refactoring, since refactoring is not supposed to change the external behaviour of the code (at least not for cases of valid input). Consider there are refactoring tools that have collections of common code transformations, that can be proven not to change output, and can be automatically applied to selected code. Many of them are simple, such as rename a variable, but they do it with proper scope awareness which a simple text search and replace would mess up.

There is no runtime overhead cost to a reinterpret_cast like this. It generates no machine instructions. All it does is relax checking in the compiler's type system. You might have correctness issues in the case of multiple inheritance though, but of course multiple inheritance is usually a bad idea anyway.

At least there is no cost other than possible loss of optimizations because the compiler can assume less about your code. In the case of pointers to objects in the same hierarchy, I'm not aware of any optimization losses. If the reinterpret_cast did something like casting an int to a pointer, then the compiler might assume any write through that pointer could write to anywhere in memory, which might mean it has to reload values that were previously in registers since they might have changed. The cast itself didn't generate new instructions, but the loss of an assumption might cause other code to generate more instructions.

As for your design choice, if both Robots and Structures can be placed on the map, maybe there should be a virtual PlaceOnMap(x, y) method in the base class, rather than casting in the mouse down code? But it sounds like you're casting nearby objects, which is a little more understandable. Might I ask though, how are you determining if a Thing is a Robot or a Structure before casting it? It may be worth pondering that part of the design a bit.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on October 09, 2015, 05:35:12 PM
Successful Thread Hijack is Successful

Quote from: Hooman
Might I ask though, how are you determining if a Thing is a Robot or a Structure before casting it? It may be worth pondering that part of the design a bit.

When I place a Structure in a tile, I flag the tile has having a structure on it. I determine it by calling Tile::isThingStructure(); Crude, but effective.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on October 09, 2015, 06:08:26 PM
@Hooman; The reason I bring kickstarter backers up, is that it actually is standard practice these days to use your potential investors as alpha and beta testers, strange as that may seem. That is what many successful kickstarter games have done, such as Rimworld, Star Citizen, and Planetary Annihilation, is shipped out an unfinished, often buggy mess to their investors that they often pay money in the kickstarter to get access to (if you bring up any of those names in Kickstarter, you'll see that specific tiers grants access to them).

Okay, my definition of a prototype is different then than your definition, it seems (or I'm misunderstanding). The purpose of prototypes for me is to hastily throw together some code, generally without caring for commenting or good coding practices, just to see if an idea will work at all. To me, to fix something like that would take far longer than rebuilding it from scratch and with good coding practices in place.

Refactoring does then sound like a good skill to have. So you would use refactoring when your code is functional, but not that great, and thus a redesign of the code already in place is the right way to go, instead of rebuilding an entire program from scratch... am I understanding that correctly?

Okay and I can now understand why iteratively fixing is often better than restarting from scratch. Thanks for clarifying that and making it clear.

Point taken about constantly throwing away code. That is a good point.

Thanks for clarifying the usage of stubs and test drivers.

I also wouldn't consider refactoring as bugfixing; I see bugfixing as repairing something while I see refactoring as renovating something.


Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on October 11, 2015, 07:20:19 PM
Design document is now up to about 17 pages (2 pages are changelog and archived info, so I don't really count them). If people would like to comment on things listed, I can look into making additional changes. I'll keep working on it in the meantime though.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on October 12, 2015, 07:33:42 AM
I was taking a look at your design document. Here are some of my thoughts.

First of all, I was impressed with how much you wrote. You've got a very good start on this.

You mention other games for inspiration. Perhaps this is better in an appendix. I still don't know what your game is about, and I'm not sure you want to define it in terms of other games. I think it's good to tie specific features of your game, already described in the design document, to another game for reference and inspiration, but not until the context of your game is given first. The reference could allow people to understand where the ideas are coming from, and perhaps get a better sense of how they should work, or how they'd be implemented. Granted, if they have to go play the other game to know, the design document is probably lacking. So perhaps this can be omitted entirely once the borrowed aspects are properly described.

You start talking about tier 1, tier 2, and tier 3, without explaining what is meant by this. Perhaps more background on this before discussing what will or won't be implemented. I would also recommend not being overly ambitious with a first project. Try to get something working first, then look to expand upon it. Sure, keep an eye out for what you might want to do, but you really need to limit scope early on. There can always be a version 2.0 later, but you need a 1.0 out first.

One question I have at this point, is whether the game will be real-time or turn based. That's usually one of the first things given when describing what a game is. I gather it's probably a strategy game, but outside of that, it's still unclear at this point. You list other games as inspiration, but they are not from a consistent genre. Ideas don't always mix easily between genres, so already this is starting to sound like it will be a bloated mess that doesn't fit well together. The earlier vague discussion of tiers adds to this. I think you need to nail down what type of game you'll be making first, then set the story, then continue on to define the features and how the player interacts with the game.

In the Game Foundation section, you list "Adaptive Multithreading" as a feature. This isn't a feature so much as a design detail. What exactly is this used to implement, and why? Why is it important this ends up in the game?

The User Interface description is good. Consider adding a prototype screenshot at some point, indicating where each component is.

If the user is able to freely move the camera, including zooming in and out, do you still need a minimap?

Are you sure you want to limit one unit per tile? Games like StarCraft don't do this for units, only buildings. Units are not tile aligned in Starcraft, but rather pixel aligned, and have variable sized bounding boxes to which other units are excluded. The tile based design is quite likely simpler, so it may be a good choice for you, I just want to point out the choice you're making here.

I have a feeling your mini map unit filtering option will be a support headache. I kind of expect people to accidentally activate filtering, and not know how to turn it off, and then wonder why they can't see certain things.

If you allow multiple building selection, keep in mind some buildings such as factories may be already busy with a long running process. What happens if you've selected one of these buildings and issue a new command? Does it override the current command? Is it ignored? Do you limit multi selection to idle factories? Do you set a queue that applies to the factory group, with the first available factory picking up the command?

You mention renaming. What is this for? What does it accomplish?

Formations can be fun, but are a non-critical feature. I think leave them in the design, but give them low priority. Perhaps set an explicit milestone that is late in the release, or after a functional demo is to be expected.

I really like the idea of AI assist. Again though, this seems to be a non-critical feature that can be given low priority. It could be a major selling point though if done right.

I rather like your roles for the 3 tank types. I like how you've differentiated their purpose. It gives a rock, paper, scissors feel, and in the reverse order of expectation (light kills medium, medium kill heavy, heavy kill light).

Multiple staging points sounds like it could be a burden. Maybe consider an alternative, like having a way of selecting all units of a specific type from a mass of units. I've seen a few games that allow for that. Maybe select first, and then hit a filter key, or have a key to select all units of a certain type on the screen.

The robot multi function sounds like a good concept, and a very appropriate guiding philosophy. They way it's written though I sort of expect to see specific examples, and none are given. Maybe the note is just in the wrong section.

Your population model sounds a bit too complex at the moment. Sounds like you're saying elderly people are useless (harsh, and won't earn you any brownie points with some people), and yet colonists don't die on their own, so you're pretty much leaving the player to murder their elderly citizens. Are you sure this is a good idea?

Is a Robo-constructor always needed to build a kit? Do the tubes only save travel time to and from the factory?

Why do command centers build tubes? That seems to seriously weaken the unit that deploys tubes. Do structures come with free connecting tubes like in Outpost2?

And while on the subject of tubes, are tubes shared between colonies (like in Outpost 2), or are they owned by a specific player? The Outpost 2 behaviour seems a little odd. It stems from tubes just being a part of the map, with nothing tying them back to a player.

I know there's more in your document, but I'm going to stop here for now. Your document is already quite long.

Good work with what you have so far. Also, since you're keeping a change log, I'd like to comment that it isn't at all out of place to put such a document under version control.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on October 12, 2015, 11:22:08 AM
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!
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on October 12, 2015, 03:12:02 PM
Some good responses. Now you have to add them to the design doc. :p
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: DranKof on October 13, 2015, 12:35:07 AM
I attempted to read everything above and failed. Sirbomber expressed why.  :P

The only things that need to be different from OP2 I think, are:
+ Build queues
+ Rally points
+ Garage automation
+ Select more than 32 units
+ Auto-repair for Convecs + spiders; better enemy detection and auto-engaging over short distances
+ Cap on maximum food per agridome
+ Various morale tweaks already addressed
+ Optimized mining design (read bottom)

Some ideas I liked were:
+ Earthworkers automated, you just plot where things go and the robots do rest
+ Alarms and flashy lights: I'm sure they won't be annoying once things are tested and adjusted; they'll probably only be part of campaign maps because in multiplayer people wouldn't want to bother, most likely
+ Evacuation Transports in multiplayer to transfer population to other players: it boggles my mind vanilla OP2 doesn't have this because it has everything similar

On Mining:
+ It doesn't matter whether cargo trucks drop their ore in a pit or if the entire butt end goes into the building, all that matters is how long the animation lasts: the entire rear part going into the building is super-cool, I'm sure they designed the time cost to decrease ore harvesting speed per building which is kinda a good thing if you ask me. But to make sure there aren't 3 smelters per mine, you make the mine also take the same long time...that will also make people stop caring so much about the total ore output of mines as it would effectively divide them by 3 and prevent 3 smelters per mine. Also the more time cargo truck butts spend underground "being processed", the less important it is to have mines and smelters next to one another as you'd have more time for the other trucks to run back and forth, so having mines and smelters a short distance apart would become less and less of an issue. If you're worried keeping the butt end underground for so long would reduce ore income just increase the amount of ore/processed resource per truckload. Easy as pie.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on October 13, 2015, 08:30:45 AM
Not sure we should be aiming at an Outpost 2 clone with a 3D engine. I'd like to see some innovation to the way all of this works. Taking a few pages from Outpost 2 would make a lot of sense but it would be nice to go back to the roots of the series and go for a more sophisticated colony simulation with much, much less of a focus on combat.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on October 13, 2015, 11:43:48 AM
Thanks for the input


Trying to do underground tunnels and above ground stuff in an RTS is completely unmanageable though. Earth 2150 attempted it, and it only used tunnels as an alternative way to get units from Point A to Point B, and hardly anyone used the feature as when you are in the tunnel view, you have no idea what is going on above ground, and its easy to get lost underground trying to figure out where you are going.

I'm not intending to do an Outpost 2 in a 3D engine. Yes I'm taking a lot of inspiration from it, but its going to be quite different. I'm actually trying to develop a more balanced game where both colony simulation and combat have equal importance in the game.

However, for sake of discussion, what do you think would make it a more sophisticated colony simulation?
-> Would tracking food, water, air, and wastes make it better?
-> Would tracking sickness, disease and plagues make it better?
-> Would having multiple categories of colonists, such as Babies, Children, Young Adults, Workers, Scientists, and Elderly people make it better?
-> Would having both natural disasters and manmade disasters (ie a lab experiment gone wrong) make it better?
-> Would having a supply/demand type system in place for consumer goods make it better (ie Colonists demand Luxury Goods)?
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on October 13, 2015, 01:12:33 PM
Trying to do underground tunnels and above ground stuff in an RTS is completely unmanageable though.

This isn't what I was suggesting. There's no need to do anything underground. In the context of an RTS it would be, as stated, unmanageable. You can stick with above ground only structures like in Outpost 2 which makes sense if a planet like Mars was selected (far enough away from the host star that it's not flooded with radiation but not so far that an immense amount of energy is needed to keep it habitable).

All of your suggestions make sense. I don't know if 'better' is the right way to look at it. What is fun? I find city management simulations fun. SimCity did a great job of making it 'real time' by simply automating turns. Outpost 2 did something similar, but they also added real-time movement of micro managed objects like vehicles and individual structure placement.

The addition of having to manage life support systems, agriculture, morale (which would be nice if it was a little more in depth), health, disasters and supply/demand I think would be fun, but it needs to be carefully balanced otherwise you get a tedious game (SimTower comes to mind).
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on October 13, 2015, 01:26:41 PM

In my experience having games that forces you to micromanage everything gets tedious quickly. Its great for the first hour or so of gameplay, but after that it gets monotonous... like grinding in World of Warcraft. I want to try and strive for a healthy middle ground between too little and too much. Its also a major reason why I hardly ever finish my Civilization games or Alpha Centauri games; it just gets too monotonous in the endgame to keep me interested.

The key thing is in making the game fun and challenging. Why both? Well, if a game isn't fun you aren't going to want to do it at all. But, once you find it fun, you'll want to be challenged, and thus having something to strive for with your own personal gameplay goals is a good idea.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on October 13, 2015, 04:55:54 PM
All valid points.

There's a time in the progression of a game where the micromanagement of certain things does get to be tedious. That's where simplifying the interface comes in handy... production queues and, since we're on the subject of Outpost, can even implement AI Helpers that can take care of the little stuff for you. There's also a point where you'll want a game to end so you can start it up new again.

SimCity again comes to mind (I'm thinking the older ones, not the new ones). There was a point where there wasn't much else you could do. Your city was built, it was flourishing, you'd covered the entire map and optimized the zones as much as you could. To make things interesting you'd have to start a disaster or two (or 20) to level half the city so you'd have to rebuild. Or just start a new city. Building from nothing is where the fun is in those games.

That's the tricky part for me. I wouldn't know how to keep it fun after you've built yourself a thriving colony. After you're thriving... then what?

This of course is not addressing the combat aspect which Outpost 2 added. But that's a different subject.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on October 13, 2015, 06:52:50 PM
Also very good points.

I also do find it more entertaining starting from scratch, but that is often because when you are starting from scratch, the entire game's "progression" is available to you and you have constant demands on your time, your ingame resources, and you must make tough choices. Later on in the game, for most games, there isn't much to do, you have nearly unlimited resources, and there aren't any tough choices remaining. If the game continued to challenge and interest a player, then likely the endgame would be just as entertaining as the early game.

The only real way I can think of doing that, is by introducing spectacle creep. By this I mean that as the player gets bigger and more powerful, bigger and greater challenges must await. And once those are beaten, even bigger ones beyond that. That's kind of why I thought of the tiered-based gameplay. The first tier involves managing a single colony. The second tier involves managing an entire planet. And the third tier involves managing an entire space empire.

The problem with Outpost 2's combat is that either the combat system was tacked onto the colony simulator, or the colony simulator was tacked onto the combat.

Because really, thematically, if two factions are in a crisis situation, they wouldn't attack eachother; if a giant meteor approached earth, I doubt the countries of this world would continue fighting and instead cooperate and try to get off together. They (eden/Plymouth) were wasting the equivalent resources of 10 starships to build combat units to attack eachother (based on the costs for each starship component, the rockets to launch them, and the resource modules all added together equates the amount of resources wasted combined by both factions to build lynxes, panthers, tigers, guard posts, and arachnids) wouldn't make sense. The two factions up to that point hadn't declared war (as their comms satellite was unavailable) and thus had no real need to build weapons of war. So, in this case, I feel the combat was tacked onto the colony simulator.

Not to mention that the colony aspects are almost always ignored in multiplayer as being a hindrance or a nuisance to manage morale and build an army. So, in this case, I feel the colony simulator was tacked onto the combat.

I haven't been getting much done on the Design Document lately. I've been trying to think over Hooman's question on Tube Ownership, and the possible situation that could occur if two rival colonies built a tube connection to them, linking the two colonies. Since my idea is that you can build tubes or structures without the required robot, would that mean a player could build a structure in an enemy's base, as that base was connected to the tubes? If that shouldn't be allowed, then some kind of tube ownership is required. However, that introduces a new problem, which is how does one keep a tube under their ownership. So I've been considering things like have combat droids/soldier colonists that are built and deployed to tubes, and it is they that control the tubes. And then weird invasion rules with those things.

Basically, I'm trying to unravel this huge mess of complexity which is why work on the Design Document has temporarily stalled.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on October 14, 2015, 02:05:09 AM
Victory is MINE!

It took me 4 hours, but I think I finally squashed that fucking computer virus. Damn that thing had a lot of backups. 3 different backups in three different locations. Real huge hassle. Just finished deleting the files, restarted computer and everything has remained gone.

So... um... I had planned on getting some work done, but the past 4 hours sapped all my energy and thus I'm going to bed now.

However, I think I figured out a tentative solution to the tube ownership issue, but I'll post that tomorrow.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on October 14, 2015, 02:33:33 PM
Easiest way to squash a difficult bug? Wipe machine and start over.

Anyway, to address the comment of tube ownership:

It's easy -- tubes built by a player are owned by said player. So yes, you could build tubes from both sides and they would connect but because the tubes are owned by different players, they are 'sealed' (air lock perhaps?)

If you make tube ownership straight forward like this you don't have the problem of being able to build a structure in an enemy base because even though it would be connected to tubes it wouldn't be under your control. Either A) it remains disabled because there's no connection with you or B) it goes under their control because it's connected to their command center. I actually see it as a great way to 'gift' a structure to another player in cooperative modes.

Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on October 14, 2015, 03:46:14 PM
Okay, so then puzzle this out:

If a player builds tubes that are not connected with the rest of the tube network, who owns them?

Or, another situation where tubes, were owned by an enemy, but you destroyed a structure, thus cutting those old tubes off from their network; does that mean that the other player automatically gains ownership, or does ownership remain in the player who built them?

The final problem is that if you are connected to their base, via their tubes, and you destroy their command center, does that mean you automatically inherit all their structures?

Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on October 14, 2015, 05:25:19 PM
Tubes built out in the middle of nowhere are owned by the player that built them.

Tubes and structures remain the under the ownership of the player who built them and whatever network they were connected to originally. If you connected your tubes to another player and then destroyed their command center, the colonists in those structures aren't going to just lay down and hand the structures over to you.

On the other hand, if you build a structure connected to their network, not yours, there aren't any colonists until the structure is complete and connected to the network. At that point the colonists can enter the structure and thus it becomes that colony's structure.

I can see the potential of using computer viruses to 'infect' structures and to force colonists out of them thereby allowing your own colonists to enter and then take ownership... but that may be starting to take it too far.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on October 14, 2015, 06:22:04 PM
Interesting input.

I was personally considering having combat droids used to control tubes and invade enemy structures, similar to how Earth 2140 did structure capturing mechanics. So when the two colonies would initially connect, your droids and their droids will line up on their own respective tubes facing eachother, and whoever won, would determine who could go about capturing structures. To maintain an enemy tube or structure, you'd have to keep at least one droid in it. However, an opposing player could send in droids of their own and take back the tubes or structures. Additionally, I had thought of allowing a player to garrison several combat droids in a structure and thus make it harder to capture. If this was in place, two rival players wouldn't want to connect the bases together.

I don't see combat droids as being too far fetched as there are some limited examples in todays world of robots with the ability to move, recognize voice commands and perform various tasks, so its not a huge stretch to think that this technology could be improved upon to create automated combat droids that are given orders and defend a group of colonists with their robotic existence.

However, I can see the benefits from this discussion of ways of gifting structures or possibly even people to an allied player in multiplayer. 
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on October 14, 2015, 06:38:12 PM
That's what I'm thinking -- coop modes. As for players in conflict, I think it would be simple enough to have 'sealed ends' on tubes that just happen to meet. That's how I would solve it though.

As for robot sophistication, with today's tech we have robots that literally drive themselves around on roads (Google's car's and yes, they are technically speaking robots) among other things. And they did that in less than 10 years. If we're to assume say 50 - 100 years of development, I think it's far to say that we'd have far, far more sophisticated robots.

Look at 100 years ago... we barely had cars. Now we have cars with computing power that rivals the super computers of yesteryear and that are so efficient they can run for literally hundreds of thousand of miles (I drove a Toyota to 350,000 and it still ran like it was new) but 100 years ago you needed to rebuild an engine every 10,000 miles.

50 years ago we had computers that were the size of buildings that could barely do what a calculator today can do. We have computing devices that fit in the palm of our hand that do more than what a mainframe could do 10 years ago.

It's hard to predict what technology we'll be able to develop over the next 50 - 100 years but I think it's safe to say we'll have robots that do a lot more than what we've got today.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Sirbomber on October 14, 2015, 09:11:09 PM
I feel like there might be too much designer "wouldn't it be cool if" going on in this thread, so if I may I'd like to interject with a player's perspective.  What you're saying about tube ownership and all the headaches involved just don't sound like fun gameplay to me.  I'm going to be busy doing so many things at any given time: managing my army, building my base, researching, exploring, growing my population, keeping morale up, and the list goes on.  The last thing I need is to have to constantly be checking to make sure my tubes aren't being filled with enemy Battlebots.  When would this ever be useful except when someone is cheesing (http://wiki.teamliquid.net/starcraft/Cheese)?  What's to stop a supposed ally from tubing to your base, spamming Battlebots, and breaking the alliance?

In an RTS, the most limited resource is the player's attention span.  Don't waste it with minutiae, or your game won't be fun.

Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on October 14, 2015, 11:56:22 PM

What he said.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on October 15, 2015, 02:18:09 AM
Fair point Sirbomber. I hadn't considered that. You are right, that would add an annoying complexity to the game, and would make it chore-ish to play and thus detract from the fun. I appreciate the input.

I'm working on currently combing through all the various input over the past couple months and putting it together in a central place before doing more work on the Design Document. Lots of good stuff already noticed, while combing through it.

Keep it up guys!
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on October 15, 2015, 05:09:09 PM
Looking forward to seeing something put together.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on October 15, 2015, 09:42:36 PM
Well, I got through all the stuff, and will work on getting stuff added/changed to the design document tomorrow with the notes I took from this thread. Going through it was a lot of great advice and great ideas and I again appreciate the time everyone took to post things.

I found something of interest, leeor_net; I think the game was actually supposed to identify the player as the Captain, rather than Commander (you had mentioned earlier in the thread that the player should be announced as the Commander). There is an image here on OPU, where it states its the Captain's log for the Plymouth colony. Link = http://www.outpost2.net/images/Wallpaper/OP2Box2.jpg ; In the bottom righthand corner is the Captain's Log, indicating that the leader of the Plymouth colony was a Captain, rather than a Commander. Unless of course the Captain was our leader, and we were making choices on their behalf???

Also in a different picture, the Eden leader is identified as a Colonel = http://www.outpost2.net/images/Wallpaper/OP2Box1.jpg
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on October 16, 2015, 10:59:28 AM
That's the box art... I'm not sure you can count that as cannon considering artists kind of do their own thing.

Besides, the computer calls the player Commander in both games.

Ultimately not sure it's really that important of a detail.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on October 16, 2015, 01:34:12 PM
It is true that its a minor detail, and therefore Commander works fine for me.

I've decided to completely redesign the design document from the ground up. I had considered "refactoring" it but I've considered my options and feel that rebuilding it from scratch will both be quicker and allow me to introduce several ways of making it easier to read. A major problem with it currently is that it is TOO verbose and its difficult for even me to follow it and understand what I'm reading... and I wrote it, and thus can't imagine how difficult it is for others.

I've also been heavily thinking on much of the feedback in this thread and some things I've been working on and have decided to make some large sweeping changes to many of the features I listed. The reason for this is Sirbomber's recent comment about a player's attention span being a limited resource in an RTS. A lot of my features, in their current state, would needlessly use up a player's attention span and thus I want to change these things so that a player's attention span is solely focused on the important things and reduce the number of things that are important to make gameplay much more manageable.

I'll keep the old one up if you want to compare the two, as I shift information from the old one to the new one, redesigning it as I go.

New Design Document Link (with an extended story) is here = https://docs.google.com/document/d/11uDn9Oc2JOYWZBCtYKGwpLUz9ZTYVg3sevX3WWLkQDY/edit?usp=sharing
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on October 16, 2015, 06:42:52 PM
SirBomber is right in terms of an RTS... but with the features you've been talking about, are you sure it's an RTS you actually want to make? Some of these features would be well suited to a turn based game.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on October 16, 2015, 07:36:01 PM
I would prefer an RTS. I generally don't like turn-based strategy games... well except for chess.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on October 16, 2015, 08:36:01 PM
Welp, then save the other ideas that work better in a turn-based for something else and stick with the ones that work better in an RTS. :)
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on October 16, 2015, 09:12:14 PM
Good point, I shall. Thanks for the input, Leeor_net
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on October 19, 2015, 01:59:18 AM
I'd just like to point out that I've been working hard on the new redesigned design document and I'm finding its a lot easier to read and hope that it helps to explain the features of the game in better detail without being too tedious to read.

Its up to 13 pages now.

Link = https://docs.google.com/document/d/11uDn9Oc2JOYWZBCtYKGwpLUz9ZTYVg3sevX3WWLkQDY/edit?usp=sharing
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on November 10, 2015, 02:43:57 PM
Any momentum on this? Haven't seen any updates and haven't seen you online on IRC in awhile.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on November 10, 2015, 07:20:56 PM
Been busy with quite a few things lately.

However, the overall design is more or less finished, and I'm working on putting it all together in a nice, neat, and easy to read format. I'll provide another post when the new design document is ready for people's perusal. Otherwise, I've been refreshing myself on C++ lately, and making good progress with it.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on November 16, 2015, 01:19:37 AM
One of the major delays is that I've been trying to figure out how to implement the colonists now and morale, with my ideas for the AI that assists with automation and the like. What I realized is that the AI should be able to run an entire colony without human intervention and thus I had felt that colonists/morale was a useless complexity. However, as these two things are what made Outpost 2 unique from other RTSs, I didn't want to just discard them. So, I've been working on some ways of allowing for a colony to be run without humans, but have humans serve some kind of purpose, whether that is where the human colonist replaces a task that a robot would normally do and do it better, or the AI requires humans to be grown so that it can use it as bioelectric power sources... ala The Matrix...

Anyway, thought I should update on why I'm taking so long. If I were to take out colonists, well, then it would be a complete redesign of the game design which isn't something I particularly want to do. I'd prefer to find some way to make colonists useful to a colony, while still allowing a colony to be run with AI exclusively. This is also because then you can have a lore-friendly way of having multiplayer matches without dealing with colony demands, as the base could be operated without colonists.

I do understand that I've been slow to update it lately and with no news it might appear I've lost interest, but I can assure you guys its not the case. I'm just having trouble deciding on how I will address the colonist problem.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: dave_erald on November 16, 2015, 09:46:51 AM
So that was a lot of reading to get caught up to this point.

     I have no experience in coding, game development, programming knowledge or even the programs require to do such things so I will do my best to refrain from commenting on any of those areas of game creation and development, if I can I would like to try and help with other aspects of the game.

And if this is all bullshit\idiocy at the very least you can have a reference of what not to do.

     On the note about having the game run itself (colony self manage) and tube layout\management or implementation I always would have liked the Outpost 2 engine to have been able to create tubes on its own after the Robot Command Center was built. It kinda felt like to me if the robot command center was meant to command robots then why in the hell didn't? Have the earthworkers automatically build connection tubes between buildings and have the robo dozers clear mining paths of debris and obstacles. Duh you're a Robot Command Center go command Robots. To avoid supply mismanagement you could set building distance limits so as to reduce tube length requirements? Again I said I would not comment on coding but maybe someone could explain how complicated that would be to write.

     Try to remember that this initial colony is going to be colonist dependent for a long time with automation systems being introduced as relief later on. Building construction (ie supervision, large construction equipment), mining and food generation would all be colonist driven till automated Robots take over, something that can be implemented after the Robot Command Center is constructed (in the campaign system of course, shortcuts around this for multiplayer if so desired) So things like research, infantry units(if you go that route in your game) and colony leadership is still colonist based. Outpost 2 is a good reference where you can see that only one worker is required for the agridome. Maybe initial colony creation has Agridome requirement at 3 workers but automation research reduces that to one, leaving the other two to be trained as scientists or infantry (sorry I keep bringing up infantry, love me some infantry, and tanks, and I digress...) Having automation systems that remove colonists permanently from harms way could provide a small permanent boost in morale. Then this way as the game progresses you can focus less time on Morale and more on building outwards or army units etc etc.

     And why couldn't I turn Scouts in to relay beacons\forward sensor stations that buried themselves in the ground and hidden from enemy units? I would have quite liked that. They remain usable for the remainder of the game.

Anyways, that's my two cents up to this point. I'll be following along and nose my way in every once in awhile. I think its great somebody is doing something like this and hopefully you keep getting positive feedback and keep moving forward. Best of luck.

P.S. maybe I answered a question or two, if not sorry. Do with my ramblings as you wish.

ALSO if LEOOR is reading this, I imagine none of this helps in your redo for OutpostHD but maybe its just more gibberish to keep in mind.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on November 17, 2015, 01:29:51 PM
You may not be a developer but your feedback as a user of the game is valuable either way. Don't worry about the difficulties involved in making it happen, worry more about the gameplay elements themselves and what would be fun to play. As developers we often forget about the playability aspect of games.

One of the things about robots and the Robot Command Center that you wouldn't know about because you (and many others) have not played Outpost 1 is that all of the robots in the Outpost universe (no pun intended, I swear) are controlled via 'Telepresence'... e.g., they're remotely controlled by a human or an artificial intelligence. This was a buzzword used a LOT in the original game's manual, help files and official strategy guide (which was more of a brief on the science behind the game than a strategy guide). So it makes sense that the robots are only semi automated. That the RCC improved pathing in Outpost2 I think was because they just needed to give that structure some use. In Outpost, you needed a Robot Command Center if you wanted to use more than 10 robots at a time (each RCC would allow you to operate 10 additional robots). That's just my guess about it.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: dave_erald on November 17, 2015, 03:30:23 PM
So it would stand to reason that I could compare the 'telepresence' to how drones are remotely controlled from a forward operations base?

I wonder if you could conservatively assign a specific number of human workers to every robot? You said each Robot Command Center controlled ten at a time so say perhaps two workers? After research and testing cut that in half or zero? I suppose you could always start out with each center controlling more robots with more workers and then dwindle that number down thru an improvements research. I like the idea of being able to reduce worker and scientist demand thru research and then being able to use them towards bigger endeavors. So say a new space program requires twenty scientists and ten workers in the background to complete.

Also I always wondered why you didn't expend rare resources during technically more demanding research programs? Always had more rare ore then I knew what to do with.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on November 18, 2015, 12:06:15 PM
Unfortunately I don't remember the Outpost 2 gameplay mechanics as well as I used to when I actually played the game. Best guess -- balance issues. Because Sierra pretty much shot themselves in the foot at every turn around that time period, the game kind of went into oblivion. The source code was lost (according to an interview with one of the developers that I can't find the link for anymore) and Sierra disappeared for a decade or so. The only balancing that's come at all has been from the modifications OPU has made over the years.

These are all interesting ideas though.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on November 19, 2015, 05:14:59 PM
I always figured that the way the Robot Command Center worked in was similar to the Main Computer for the United Civilized States (UCS) in Earth Games, where a single powerful computer managed all of the vehicles under it's command.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on November 19, 2015, 11:53:47 PM
That's actually what I'm going to do with OutpostHD -- the command center can only control 5 robots (limited resources) but once you build a RCC, you don't have those limits anymore. If it's ever disabled any robots that are currently working beyond the first 5 will go into an 'idle' state and not finish their production until the RCC is reenabled.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on November 21, 2015, 01:35:39 AM
Since I've asked in the past for advice, I'd like to do so again now.  I'm currently stumped on two features:

1) Colonists
2) Colonies

The current design is quite a bit different now after many revisions, and thus is somewhat different than what was discussed in the first two design documents. The game is being designed now where all vehicles have hover drives, and thus are unaffected by things like Lava or Earthquakes (except for deployed Medium Tanks), and thus bulldozing in general doesn't make much sense anymore. Additionally, an entire colony can be run by self-aware AI, and thus no human interaction with a colony is required. With structure construction and tube construction available via tubes, the Robo-Worker and Robo-Constructor have been made obsolete. With orbital satellites deployed at the start of the game, Robo-Explorers are obsolete. Full mining and refining is done by the Refining Facility where it mines resources out of the tiles it is built upon and can be upgraded so that it can mine even more tiles, and thus separate mine structures or Robo-Haulers are also now obsolete. This means that there is no reason to have Civilian vehicles anymore, and only military Tanks. With all that is said, I'm stuck on how to address these two problems. I've come up with several possible solutions, but I've not been able to decide on which to choose, and was hoping to get some community input on it. In addition to that, I'm making headway into a new Design Document and will try to have that out within a week, for additional suggestions on its design. So my possible solutions to the above two problems are:

1) Colonists:
A: Remove colonists from the game, and the game plays out much like the United Civilized States (UCS) in Earth 2160 where the AI kills them all off.
B: Keep colonists in the game, and their purpose is simply to augment the AI capabilities rather than be directly useful to a colony. Colonists in this scenario are not tracked by type, but rather just as a number of colonists in general. The more colonists you have, the more technology can be researched, and the faster the AI adapts, as the AI utilizes the humans in a form of symbiosis to augment it's own capabilities. This would be quite a bit like Option A, with the only real difference that humans are used as biological storage devices.
C: Keep colonists in the game, and in addition to the features of Option B, humans are used as biological sources of energy, much like how humans are used in the Matrix movies.
D: Colonists actively help out the AI, and you still see roles of Scientist, Engineer, and Worker. Basically any structure occupied by a colonist functions slightly better than with pure AI control.
E: Colonists are essential to a base, and a base cannot function at its best unless humans occupy jobs. The AI can handle basic features of structures without humans, but requires humans to unlock the better features.
F: Colonists are fully required, similar to how Outpost 2 does it where a structure doesn't function at all if colonists aren't present.
G: Some combination of the above Options...

2) Colonies:
A: Colonies are built by launching a colony lander into space, and then ordering the colony lander to land in some other planetary sector, and set up a colony there.
B: Colonies are built by building tubes all the way to the edge of a sector, which then builds them into the following edge in another sector, and thus a new colony is setup by just building tubes to other sectors.
C: Colonies are built by a highly adaptable civilian vehicle that can haul resources, haul structure kits, build structure kits and deliver resources to a refining facility.
D: Colonies are built by the Robo-Constructor, which is loaded with structure kits and deploys them.
E: Colonies are built by a vehicle that deploys into a structure permanently, much like how the MCV in C&C games deploys into the Construction Yard.
F: Some combination of the above Options...

I'm not fully sure that removing most of the civilian vehicles is a good thing for the game, but again, the game has gone through many revisions over the past several weeks, and some things don't make any sense anymore considering the changes I have done.

What are people's thoughts on these things? At this point my game is looking and feeling less and less like Outpost 2... and I'm wondering is that a good thing or a bad thing?

Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on November 21, 2015, 10:47:04 AM
It's your own game. Perhaps it should be your own game, and not worry too much about deviating from Outpost 2. You should feel free to adapt the plan to your own desires, and perhaps even to your own skills. Outpost 2 can be complicated, and sometimes without much benefit. Maybe simplifications should be made, particularly if it helps get a game finished.

Now that you've laid out your options, what do you think is best?

As for your colonies question, can I add a simplified option? There is only one colony. You can discard the multiple colony feature.  ;)

But, you choose.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: dave_erald on November 21, 2015, 12:56:46 PM
How Colonies are constructed/maintained and or reasons for being built/moved would largely depend on where the game is and how it is going to be played for the majority of the game.

So for instance I have read some of your game history you had written but as I write this I can't fully remember where you were planning on have these three factions/groups living or fighting, whichever it happens to be. I had a game in mind that sort of follows where you're already heading, that it was three different factions of humans like you have (unless you change all this then disregard) that started as one from a colonization space ship that landed on a far and away distant solar system.

So game starts landed on some shit hole planet that can't sustain that many colonists, divide into three after having constructed more ships and stretch into the current system, one that as a large gas giant with plenty of satellites (ie Jupiter) and a large asteroid belt in between this gas giant and your current planet.

Colonists split up and you decide which faction you side with and where your going.

This is a game I pictured playing in my head, its my brain, that's a game my brain would play

But anyways, all I'm trying to show is that game design will negate how you control colonies and colonists. If you do have a good idea in mind of where the game is going, how do you want it to be played (is it all fighting or all building or bit of both?) and are all three factions on one large planet and you do move around or you don't, how big is the game, will answer for you how to build and control things.

And I'll think of something for colonists.

If you do have a good game script could you post it, or post the link to the new design? You said you were changing your mind on things right? Let me know some more about it and I could draw up some more specific ideas tailored to what is in the game.

As always, if this is a load of bull, wash rinse and move on.

Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on November 21, 2015, 05:05:54 PM

Perhaps that is true. I'm just concerned that I'm simplifying too much complexity to create more depth in a smaller number of things, that will make the game boring and less fun. Then again, too much complexity doesn't imply fun either. I suppose that part of my concerns is that I'm trying to make it less complex and in the process I've lost the fun in playing it... though that would remain to be seen when it gets built of course. Truthfully, I don't really know how to define fun, and when I play base building games the fun I get out of it is defeating my opponent and building a base. That is what I'm trying to do, but is it enough? Maybe I'm overthinking this stuff.

Which option do I think is best? Well, judging from how society is going and how technology is improving, I'd say that in several decades time people are going to be less and less interested in slaving away all their time for major corporations and prefer to focus on self-improvement and enjoyment over working long hours. Likely robotics and artificial intelligence would improve to the point where robots are doing all the manual labor jobs, leaving people to do what they want when they want. With the rise of VR today, I could see in several decades time full immersion video games (ie like that episode in Red Dwarf called Back to Reality or VR suits like in that episode of Red Dwarf called Gunmen of the Apocalypse) such that people would be more interested in playing video games over participating in real life. With the rise in robotics, and with the invention of artificial wombs (which is being talked about today, so in several decades, who knows) population growth is easily managed. But with the rise in sociological/religious movements (depends on how you see them) such as MGTOWs and Feminism, its likely that people will prefer to live solitary lives, the nuclear family structure will collapse, and the government would likely take over in ensuring population growth. So, with all that said, my personal opinion for the colonists are:

Are combination of B, C, and D. Most of the population isn't needed anymore to directly help out with a base, and thus they keep themselves fully immersed in video games. These people would be used by the AI that controls a base, as both a biological source of energy and utilize their brains as biological storage devices. However, a smaller number of the population is represented by Scientists and Engineers, that prefer to stay in the real world and try to make a real world difference, and thus scientists help the AI research and the engineers help the AI function better. Both of these assist the AI symbiotically as well, while the AI works to keep all the humans alive and happy and functions worse without any humans to support. I feel that this would be the best option, and retains the best of all solutions.

Finally, I didn't think of that. The simplicity of it, certainly solves a lot my problems. I like it!

Lots of interesting stuff will have to go through it and provide some comments in a bit.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on November 25, 2015, 12:55:43 AM
Well, with a whole lot of unexpected problems, I missed my deadline of a week for the Design Document #3. I've realized that my greatest enemy right now is my lack of Problem Solving skills. I'm finding myself getting frustrated and confused with my work, and this results in my brain's survival mechanism kicking in and thus I get distracted from that which frustrates/confuses. Its going to take me a while to understand why my brain is distracting me, but for the time being, if I improve my Problem Solving skills, I should be able to address frustration/confusion when it occurs, solve the problem instead of being distracted, and continue working. Thus I'm working on trying to improve my Problem Solving skills. I'm trying to pattern it from my gaming problem solving skills. I encounter a lot of frustration/confusion while playing yet, I don't get distracted from playing and thus I clearly have developed some great Problem Solving skills to address problems I encounter. So I'm trying to understand why I can problem solve effectively for games, and prototype a way of utilizing those skills for work.

With that said, I'm trying a few new things to see if they can work to solve the problems I'm having. I've had some limited success already, but not enough to truly solve the problems I'm running into. In particular, I don't understand the value to myself to create a Design Document. I can understand it's value to the community here, as they can see what I'm trying to see for my vision for the game. But as I can see the vision for my game, I don't see the value for myself in having the Design Document. So, I'd like to create a Design Document that is specifically useful to the community here. So, some questions related to that, to help me problem solve and create a Design Document that is useful to people here to understand what I'm going for. As I'm creating the document for the community, it would be nice to know what the community wants out of the Design Document, and how they feel its best to portray the information. So the questions are:

1) What format do you want the Design Document in? Was Google Documents ideal for everyone here, or would you prefer a different format (ie Text File, Open Office, Microsoft Office Doc/DocX, etc)?
2) How would you guys like the information presented? Was the way it was presented in either Design Document already ideal for people here, or would you guys be able to suggest some changes to it for better readability?
3) Do you guys want interface mockups? By mockups, I mean something simple created in Paint, indicating where you'd find specific things? Or would you guys prefer to wait until I have a chance to work with UE4/whatever engine I choose and provide more accurate mockups? Or both?
4) What kind of information is useful to everyone here? Is it simply text information, some numerical information (such as building HP, building costs, etc), some formulae (ie Damage Calculations), etc?
5) Do you guys want me to go into great detail or go for more of a tl;dr version? Or both?

Answering these questions will really help me out in creating an ideal Design Document for everyone to peruse. Thanks in advance!


I keep saying I'd respond to you Dave, but I keep forgetting, so I'll reply here:

1) I'm thinking for simplicity to avoid having complicated faction relationships such as I explained in the second Design Document. Unless of course people would prefer that. Its just that with a lot of my changes, it wouldn't make sense to have those complications in the game anymore. However, it does create the problem of who you would be "attacking" or having conflicts with... hmm...

2) Micro-bases without a colonist population does sound like an interesting idea. I like it.

3) I've ended up combining the features of a Robot Command Center and a regular Command Center together. The way I'm thinking of doing it is to have the initial colony start out as a Structure Factory. It builds tubes and structure kits and has its own built in generator. However, it is limited in the kits it can produce until a Command Center is built. The command center is used to control all vehicles/tanks in the region/area and if it is destroyed/deactivated all vehicles shutdown and the command center is used to unlock advanced features for each structure. Not quite sure how I'd handle it though for maps where there isn't an active command center, or perhaps have a maximum range vehicles can travel from an active command center and remain active.

4) I hadn't considered using a reactor to beam energy to vehicles and thus you would require more reactors to support more vehicles. An interesting idea.

5) I had in mind to have a balance of colony development and combat, with neither being dominant and both being important. A difficulty balance to achieve though. I want to have an indepth, but not too complicated colony development to the game, and an indepth but not too complicated warfare aspect to the game.

6) I do not feel your comments are bull. Keep them coming. I would like to produce a good design document for the community and thus help myself by getting some advice tailored to what I'm trying to build and achieve with it.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on November 25, 2015, 07:08:55 PM
Well, with a whole lot of unexpected problems, I missed my deadline of a week for the Design Document #3. I've realized that my greatest enemy right now is my lack of Problem Solving skills. I'm finding myself getting frustrated and confused with my work, and this results in my brain's survival mechanism kicking in and thus I get distracted from that which frustrates/confuses. Its going to take me a while to understand why my brain is distracting me...

It's simple -- without a disciplined mind you will never be able to finish a large project.

That's not to say that I'm perfect. Hardly. But I've had my share of burn outs because in the back of my mind I knew I may have bitten off more than I could chew.

Problem solving skills isn't the problem. Realizing the immensity of the task at hand and being overwhelmed by it is.

I don't understand the value to myself to create a Design Document.

If you don't know the value to yourself of a design document than you're not even playing the game.

The DD isn't for the community, it's for the developer(s). It's to give you a roadmap of what you need to do and keep you focused instead of allowing feature creep to take over and make the project an unattainable goal.

1) What format do you want the Design Document in?

Irrelevant. The format doesn't matter. Just write it wherever it's convenient and with whatever program you want to use. If you want to publish it for an easy read, export a PDF. Otherwise, just do whatever, this is not important.

2) How would you guys like the information presented?

Irrelevant. Write it in whatever way suits YOU. Just be consistent.

3) Do you guys want interface mockups?
4) What kind of information is useful to everyone here?
5) Do you guys want me to go into great detail or go for more of a tl;dr version? Or both?

Irrelevant. The DD is for YOU and the developers, not the community.

It's pretty clear that you're focusing on things that are meaningless or unimportant/trivial. Stop wasting time overthinking things and just do it. A DD is for YOU and the developers, not anybody else. See above.

Just to throw this out there again, not to be discouraging but it's evident that you're in way over your head on this one and maybe you're afraid to admit that. It's okay to realize you've taken on a task that may be too big for you. That doesn't mean the project has to die, only that you need to rethink what you want from it.

First and foremost, based on the questions you were asking me over at NTCS via PM (I knew your name was familiar), you have no concept of large C++ development projects or what it would take to actually develop a game like this. Taking an engine like UE4 and bending it into an RTS is going to be a challenge that is currently beyond your ability. That doesn't mean that you will never be able to do it but right now you're out of your league. I'd be out of my league if I tried to do it and I've been writing C++ programs for over a decade.

That stated, you should consider a few things. If you're sure you want to be programming, either 1) join another project and learn from it before taking on this challenge or 2) choose a different technology platform that will make the development process easier. Unity comes to mind as it's generic, runs on many platforms and I've seen several commercial games built using Unity that are similar to your concept.

I don't say this to be negative, I say this from experience. When I started Outpost 3: Genesis I chose Ogre3D as my technology with the thinking "I'll figure it out as I go along." Suffice it to say I never did figure it out. All I figured out is that I had no idea what I was doing. In order to make Ogre3D do what I wanted it to do, I would have had to build a scene graph handler from scratch. At the time I wouldn't have had any idea where to start. Today I'm in a better position to try my hand at it again but no, I'd rather use something like Unity as it makes the whole process that much easier and comes with a myriad of tools and a giant community to help you get through what you're trying to do.

I'm also not saying you should abandon this project. Only that you should consider changing or tweaking its scope. Unity is a good choice... UE4 MAY have a large enough community and may even have some RTS templates/projects/examples that you can work with. I'm not familiar with UE4 so perhaps you should start by demonstrating that UE4 is in fact the correct technology to use.

If you find that it is NOT the correct technology to use, then it's time to look for another. Rolling your own will not work, you're not ready for that yet. So let's work on that together. The DD that I looked at was fine, just finish it up and lets's start looking at what technology is appropriate for your game. And also, keep the scope of the game SMALL or you will never finish.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on November 25, 2015, 08:03:00 PM
If only things were as simple as having a disciplined mind. I do have a disciplined mind, the problem is that I distract myself from emotional pain, and confusion/frustration is emotional pain. Doesn't matter what kind of emotional pain it is; fear, anger, sadness, depression, etc... I'll distract myself from it. When I'm in my groove, I accomplish a lot. The issue is staying in said groove, and emotional pain kicks me out unless I immediately solve the issue. Though my definition of disciplined is likely different from yours.

Edit: I see discipline as being the choice to remain focused, as compared to the choice to distract oneself or procrastinate. I don't lack discipline; I'd be happy to throw 8-16 hour days at the project. The problem is that I'm being distracted not by choice, but against my will and outside of my control. Problem Solving skills allows me to regain control, and allow my discipline and enthusiasm shine unobstructed. If I can address the problem that is distracting me, then I can remain focused.

Yes, I do agree I've bitten off more than I can chew. However, how does one back out of it once they've realized that? I do want to create the project, but currently it is beyond my capabilities. In the future maybe not. But right now, it is.

Edit: The reason I hadn't realized this before is because in previous months, I had "bigger" fish to fry, and compared to them, building a game was a cakewalk. Things however, have changed in the past few weeks, to make me realize that building a game isn't a cakewalk; if it was, I'd be building a game right now, not talking about building one. During previous months, I hadn't considered it an option to try to make a smaller game, as I needed to produce a commercial game. Things again have changed and thus I see it is an option to do a smaller game first, even if it isn't commercially viable.

I'm well aware of the immensity of the task at hand, and knew this going in. However, I did not anticipate all the problems that would come with it. Problems, problems, problems, but no solutions.

I don't like DDs. I have my own method of keeping track of all the necessary information, in a nice, clean, easy to read, format. The issue is that getting that format to you guys is impossible. I use an old D&D program called DM Genie built originally for 3e. I use it because in it's campaign manager, it allows for directories, with full formatting, no spell checker, and sub-directories. I can easily sort out information into separate files and quickly browse through them. In this manner, I can easily sort out necessary information and put together features in an intelligent manner and it just keeps everything well organized. I have never seen this format for directories since, and thus I continue to use DM Genie; its extremely useful for me to keep everything in one spot. The issue is that DM Genie is a paid program and hardly anyone uses it anymore as hardly anyone plays 3e anymore; even the developer has stopped supporting it. I find it useful because it has all the benefits of Notepad, Word, and a color-coordinated file and wrapped together with none of the negatives.

Therefore my questions for the DD stand. I have my own method of ensuring everything fits together nicely and avoid forgetting something. Getting that information to you guys so that you can offer suggestions on the content requires you guys to comment on the method you prefer the information to be in.

As for the other comments...

I am in way over my head. This project is too big a task for myself to complete it, at my current proficiency in coding, art, and engine work. However, what should I do? If it is too big, then logically, it would be best to shrink it. However, whenever I've shrunk a project too much, in my other game designs, I lost interest in it. Therefore, I realistically see only two options. 1) Abandon the project or 2) Put the project on hold, while I develop my skills in development with a smaller, unrelated project; something that is doable, attainable, and within my capabilities. I'm more inclined to go with option #2. I think that putting this project on hold while I work on my development skills on a smaller unrelated project with a much smaller scope, would be the ideal choice and would be beneficial for me to see if I should be attempting something as big as this in the first place. If I can't accomplish the smaller project, I have no hope of completing this project, ...yes? There is of course the third choice which is to give up on development altogether, but I'd rather attempt #2 before accepting that I'm not cut out for development. Now the problem is I need to design a much smaller game... hmm...

Edit: I've decided upon a smaller scope game idea. It will be a game inspired by a fairly simple space shooter released during the early 90s by a company named Software Engineering, and the game was called Gravity Well. I really miss playing that game, but as it was a 16bit game initially, and the lastest build was 32bit, neither runs on 64bit machines. Software Engineering did end up making a 5th one, but it plays nothing like the originals.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on November 26, 2015, 09:16:36 AM
Hmm, you do sound a bit frustrated. Perhaps there are ways we can better assist.

For one, you seem very frustrated with the design document to the point where you either don't want to do it, or want to push the decisions off to other people. I can't say I blame you. I'm guessing this is your productivity stumbling block though.

One thing I've learned is not to trust your brain. In particular, be aware that "belief" is a feeling, same as other emotions, and not entirely reliable. It is not always backed up by facts. It's been found that beliefs come first, and explanations follow. I mention this because you say you can "see the vision" for your game. How do you know? What supporting evidence do you have? You might very well *feel* that you do, but if asked to hammer out the specifics, I'm guessing things get difficult. This creates conflict in the mind because reality does not match up with your beliefs. What usually happens is belief prevails, facts are ignored, and you're left feeling frustrated by the unresolved situation, and form a tendency to ignore what you don't want to believe.

Chances are, for a project as large as you're envisioning, you haven't thought it all through, and probably can't remember all the details in your head. That vision you see, probably isn't as clear as you think. I'm guessing that's why the design document is hard, and you don't want to do it. By working on it, it presents you with decisions to make, and details to fill in which you don't entirely have yet, and that goes against the feeling that you can see your vision.

If you can't trust your own mind, perhaps try working with someone else who can call you out on a lack of clarity.

Don't be afraid to think big. Sometimes that's exactly what's needed. You do need small actionable steps though. If your game seems to big to do now, why not consider that vision 10, and instead cut things down to a very minimal set of important parts that can be a version 1. No need to choose a whole new project entirely. Probably even worse to put it on hold indefinitely to learn, or just abandon it outright. I think there is value is taking a step back from the grand vision and instead focus on a small aspect. Try to find some core minimal subset that could be made into a complete game. Even really simple games can be surprisingly fun, often more fun than a complicated mess that is hard to learn.

Getting something going is often more important that getting something complete, or even correct. Having something to show helps build enthusiasm and momentum. Simple still images, or even just text output can be a start. You've played text based games before, right? But, perhaps not even a relevant question. I guess my point is, simplify. You don't need to abandon your grand vision, but you may find it changes long before it's complete, so start small.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on November 26, 2015, 02:26:54 PM
Quote from: lordpalandus
Doesn't matter what kind of emotional pain it is; fear, anger, sadness, depression, etc... I'll distract myself from it.

Just to put it out there, this is THEE definition of an undisciplined mind.

Also just to put out there, I'm not suggesting you go out into the mountains on your own and meditate for 30 years before you're capable of developing a large project. But being able to keep plodding through when you've hit a difficult problem in a project is the difference. OutpostHD has presented many such problems and for the first time -ever- I've been able to overcome every single one of them. I still have an uphill battle to get through the other gameplay mechanics but I'm actually managing to 'get shit done'.

Quote from: lordpalandus
However, how does one back out of it once they've realized that?

By doing exactly what you're doing now. Saying so. It's OKAY to say "Hey, I really want to do this but it's really kind of beyond my capability right now." Admitting it is already better than many of the projects that have come and gone.

Quote from: lordpalandus
I don't like DDs. I have my own method of keeping track of all the necessary information, in a nice, clean, easy to read, format.

So that's a design document. There is no specific format. There is no specific method you need to use. Whatever works for you. Again, it's for you, the developer, not anybody else.

I would still recommend that however you do it, you complete it. That a lone is a bigger accomplishment than you know.

Don't be afraid to think big. Sometimes that's exactly what's needed. You do need small actionable steps though. If your game seems to big to do now, why not consider that vision 10, and instead cut things down to a very minimal set of important parts that can be a version 1. No need to choose a whole new project entirely.

That's the point I was trying to get across.

I did a little research and UE4 may actually be a good technology choice. Seeing this: https://docs.unrealengine.com/latest/INT/Resources/SampleGames/StrategyGame/index.html convinces me that there may be a good starting place. How about a tower defense game? It's simple, it employs a lot of the things your original idea will ultimately use and it's a good starting place while at the same time being simple enough to accomplish.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on November 26, 2015, 07:48:24 PM
A bit frustrated is an understatement. I was a bit frustrated a couple months ago. I'm very frustrated now, but anyway.

Its not that I haven't hammered out the details; I have. They are just scattered over 30 different files... an annoyance I assure you that I don't like which is why I'm working on putting it together in one place in DM Genie. Although... I do think there are some things I haven't addressed... The evidence is there, its just highly disorganized and badly needs some tidying up.

As far as the vision goes, what I mean by I see by its vision is that I've hashed out most of the details for that vision... how the game starts, how it plays in the mid-game, how it's interface looks, what it's endgame goals are, what are the failure conditions, how multiplayer will work, how the campaign will work, how the moment to moment stuff will work... I've hashed this stuff out. The thing I've not fully hashed out is the tech tree... mostly because I'm on the fence of how far I want to go down the rabbit hole into make believe science and how much I want to keep it to hard science.

As per the beliefs, I've had my reality shaken quite a bit. I originally considered things simple and easy, and they aren't simple and easy. If they were, we wouldn't be having this conversation >.>

No I dislike the Design Document because its clunky, too wordy, and I have a tendency to dislike huge text files. Trying to say more, with less, is a very frustrating chore. And if I don't try to say less then I end up having 30000-50000 words to read through. Probably why I hate taking notes... hmm...

There may be some details I've forgotten, I'll give you that. Only way to be sure is to sort the information out and see if I am missing something.

Hmm... small actionable steps... that might be the ticket. Yes, I would agree that putting it entirely on hold will just likely cause it to never get done. Afterall, isn't that what happened to most of the projects here, that got put on hold and eventually that turned into project abandonment?

I'll need to think on it but I think there is a smaller core subset that could be acted upon to act as a starter or foundation for more while still having concrete results and some level of functionality.

Yes, some of the most simple games happened to be the most fun... strangely enough. A recently released title Kingdom, is a simple game, yet addictively fun.

Yes I would agree having something to show would build some enthusiasm. Yes, it is probably for the best to start small and build on that, rather than wait to do it later.

Yes I've played text-based (ie Zork) games and text-based graphical games (ie Hugo 1).


Yes, and you just explained why Problem Solving skills are so essential. Without them, the first problem you would have run into, would have resulted in you stopping development. Thus, I'm working on developing them.

How is admitting it is already better than many projects that have come and gone? Doesn't it have the same end result, a lack of completed project?

Really? I had thought a design document was specific to a long-winded document in a single file, or pdf, and often printed to have physical copies... not what I'm doing. If it is the same thing, then I guess I'm making a design document. (confused look)

Yes, I do intend to complete the design document and have been working on getting everything put together in a single location for organization sake and to ensure I haven't missed some detail I haven't hashed out yet. Though... what I could do is after I have sorted it all out, I could Copy + Paste all the sorted information into one larger file for people's perusal... it might not be neat but it could have all the relevant data for people to look at.

Yes, I saw that RTS demo as well, but didn't actually take a look into it at the time. It does seem like UE4 could be built for an RTS. I've never really considered a Tower Defense an RTS, and considered it always as its own genre, tower defense but that's a minor nitpick. I wasn't thinking of a tower defense, but the game I had in mind does have many of the strategic elements that my game might have. But I can scan through the code for the tower defense and see how it operates, try to affect changes and see what the results are or lift portions of the code and use it in my own project.

Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: dave_erald on November 26, 2015, 08:48:08 PM
Damn. Hadn't even considered tower defense, I read your most recent design doc, some of that could work in an adjusted tower defense model. There could even be some RTS imposed in as well, nothing as in depth as say Outpost 2 but I can think of a niche that you could fill, provided it ain't been filled already.

Hmm... You are still set on doing a proper design doc, and this game, but the scope is too large right now? I say just because you scale it back or change the core game mechanics doesn't mean you failed, I call that being productive and reasonable. AND ITS STILL YOUR GAME
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on November 27, 2015, 10:53:33 PM
Thanks Dave, I appreciate that.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on November 28, 2015, 01:29:21 PM
Quote from: lordpalandus
How is admitting it is already better than many projects that have come and gone?

Because the others just up and died. Some dramatically, most just silently disappeared. This includes Outpost 3: Genesis which had a very dramatic fall from grace and then silently went dormant and died in the process.

Often times this involved users/members silently disappearing at the same time. Sometimes, like me, in a dramatic tantrum. And others just pretended that the project never existed (or at least ignore it).

You've stated "You know what, this is too big for me. I want to do it but it'll have to wait." You haven't disappeared and you've acknowledged that perhaps you should take a few steps back and try something smaller first.

Quote from: lordpalandus
I had thought a design document was specific to a long-winded document in a single file

A lot of people think that's what a DD must be but it doesn't have to be. Again, a design document is for the developers (you) so that the developers (you) have something to look at and reference when moving beyond design and start turning that into the scaffolding for a project. Too often people get caught up in The ProcessTM and forget that it doesn't have to be official. It doesn't have to be lengthy. It doesn't even have to be a single file (though a single file does help in terms of distribution). What it really needs to do is 1) be consistent and 2) describe the game, its gameplay elements, its rules and that's effectively it. The rest can be addendums (e.g., UI design, interface controls, etc.) and can be developed later.

Quote from: lordpalandus
I've never really considered a Tower Defense an RTS, and considered it always as its own genre

It is its own genre but they share similar elements.

And that's just the basics. For games where the 'overseer' can use magic, you also have special abilities like being able to cast AOE magic that can aid in surviving a wave. This sort of thing applies to RTS games as well though in a somewhat limited capacity. A good example of this is StarCraft's Nuke ability (well, the Ghost anyway). Either way it's a special ability that has a large AOE effect and it's done in an RTS.

First thoughts for an Outpost 2 based TD type game:

In fact, there's your DD for an OP2 based Tower Defense game. Note how it's not lengthy, it doesn't go into excruciating detail and anybody reading this list would have an easy time taking it and building a project with it. The DD, as stated, is for the developer(s). If there's only one developer, you can leave out a lot of details because you'll flesh those into the project as you go along. If there's two developers, you would have some additional details but with only one line of communication to worry about it's easy to figure stuff out along the way. Get into 10+ developers and then you need something much more formal.

Also note that this is a SMALL project and should take no more than a few weeks to build depending on the technology you use and the familiarity you have with said technology. If you built it in 2D using existing art assets, you could have this done in about a week. Or at least a playable version. If you wanted to do it in UE4 as a 3D game, assuming your C++ is half way decent I'd say it would probably take a month or two to develop, half the time would be used learning how to work with UE4 and the other half actually developing the game. Also keep in mind that resources would need to be created for the project so that would slow things down as well.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on November 30, 2015, 01:17:35 AM
Interesting. A good suggestion Leeor, I'll need to take a look into it once I start doing my UE4 catch-up (as I've not used it for at least two patches so I'm sure there will be some new stuff to work with, especially as when I lasted tried it it didn't actually have that Tower Defense game at the time)
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on December 05, 2015, 09:54:54 PM
Just so everyone knows, I got struck with a viral flu on Monday, fought it off by Thursday and then got a bacterial infection (tonsilitius) later on Thursday of this week. I am quite sick, and completely invalid. Thus I have not got any work done lately. I am interested in doing it, but right now, I'm not interested in doing anything other than sleep. So yeah. Laters.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on December 06, 2015, 02:33:58 AM
Get well soon.

So..., if we start giving you commands for things to do, will they be invalid commands?  :D
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on December 13, 2015, 01:13:27 AM
Well feeling quite a bit better... at least physically.

Right now I'm working through a variety of life changes that need to take place. I had set out in September after my returning from my trip, to do a 3-month goal. Suffice to say I didn't succeed at my goal, but I learned a lot of valuable lessons, and pertinent information that I feel I should utilize to affect my life in a positive way before I set about the task of creating a new 3-month plan. Yes, I said plan and not goal; I do see the two as being different and that is one of the changes I will be implementing.

I feel these life changes are necessary in order to succeed at developing a game, and thus I feel it is critical to address them now. 

EDIT: I've been making a lot of headway recently with my changes I feel are necessary. I've put together an effective problem solving system for myself and a way to combat distraction and remain focused on my tasks. I felt a little update would be appropriate as I've been silent for over a week.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on December 29, 2015, 09:23:18 PM
Just so everyone knows, I got struck with a viral flu on Monday, fought it off by Thursday and then got a bacterial infection (tonsilitius) later on Thursday of this week. I am quite sick, and completely invalid. Thus I have not got any work done lately. I am interested in doing it, but right now, I'm not interested in doing anything other than sleep. So yeah. Laters.

As opposed to... bacterial flu? No such beast.

Anyway, I know the feeling. I was totally wiped out for three weeks with what started out as a flu and developed into more serious complications. Have recovered now at least.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on January 01, 2016, 07:42:58 PM
It is strange that viral flus are less menacing than bacterial flus, while the most dangerous things a person can get are Viruses, such as HIV.

However, making much progress on changes and on the project. I've been analyzing it critically, and noticed some things that are not likely to be complicated to implement (complicated as compared to nearly impossible) and thus I'm looking at removing them and fixing the rest of the design to operate without them. I've decided that having complicated Orbital Layers and the ability to switch between an orbital view with orbital structures and a ground view and ground structures is needlessly complex and even if it wasn't complex, I don't really know how I'd go about doing it right now anyway.

Wanted to get some work done on it today, but had to fight with my computer as Windows Update forcefully downloaded a "BAD" "security update". Only thing it did that I noticed was that it prevented Windows from detecting my second monitor. I checked its drivers, cords, wires, and graphics card drivers and all were working properly. Uninstalling the security update though fixed the problem. I really want to know why a security update would prevent windows from detecting a second monitor... how is a second monitor plugged into the same graphics card a security risk?
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on January 02, 2016, 01:03:02 AM
There's an awful lot of information that can leak through a million pixels. ;)

So what work were you planning on doing? How were you going to start?
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on January 02, 2016, 06:38:45 PM
Haha, that's a good point, Hooman.

Well, one of the things I was going to work on was the change to the User Interface. By not having an orbital layer, the UI wouldn't need a way to switch between the orbital layer / planetary layer and all the information that would have been displayed graphically, with space-based units would now need to be condensed down into a simpler interface tab, likely in the Colony Tabs.

As for other work, I had compiled a large list of design strategies from designing a bunch of other game prototypes before I came upon deciding to make a game like Outpost 2. Thing is I've not looked at it at all since starting to work on this game, and thus I feel I should check it over to see if there was any wisdom I wrote down that I might want to consider.

As for figuring out where to start, I'll figure it with some problem solving, and create a variety of SMART goals to accomplish each stage of the redesign. I'm in a way getting tired of redesigns, but as I continue to work at things I realize how some things are unrealistic or needlessly complex and don't add anything by being there and instead detract from the gameplay and thus I feel another redesign, but with fewer redesign changes is necessary. I'm running out of things I need to change so hopefully this will be the "final" design so that I can put together a complete design document and share that.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on January 02, 2016, 08:51:26 PM
Nothing is ever final. Changes occur right up to release, and then again afterwards with release patches. And don't forget there is always the possibility of a sequel. :)

Embrace change! ... But yes, do celebrate once the changes start getting smaller. :P

And remember to eventually start on something. Having something to look at and play with helps to refine the plan. Do you have any plans to start on something other than a design doc? Where do you see yourself starting? Will you start with some code? Graphics or models? User interface? Tech trees? More abstract game concepts (like being able to simulate gameplay without having a user interface to see or interact with, but helps verify and balance your gameplay model)?
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on January 03, 2016, 02:18:29 AM
Yeh, that is true. Nothing is technically final. Its just a matter of how much work you want to invest to make the changes when its in a more concrete form.

Well, I am learning to embrace change and appreciate it. Its valuable and although sometimes costly, always worth it in the end.

As for where I'd like to start, I think that I'd like to start on combat mechanics and unit control. In the short-term I can use mostly placeholder objects for units and placeholder code for structures while I work on combat mechanics and unit control. I can "likely" (keyword) do this within UE4 exclusively with a minimum of C++ coding (except for coding some of the AI decision making as that must be AFAIK be done in C++ exclusively as there isn't blueprints for AI decision making). As a major component of the game will be interacting with vehicles, namely tanks, and ordering them to do combat actions, I'd want to spend some time prototyping and testing different ideas out with them. I also want to see how the engine handles large numbers of units on the screen; if it works anything like Supreme Commander, I would expect there to be framerate drops and weird AI behaviors due to the event queue getting clogged with too many events that it cannot process fast enough and would like to use a profiler tool to see where it might be possible to get gains or reduce the overhead in some way (naturally as they would be placeholder objects, they wouldn't have the same impact as finished models, with finished effects [sound, lighting, shadows, weapons, movement effects (dust, tread marks, etc), etc] but it might still be useful to see where the bottlenecks would be.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on January 03, 2016, 06:26:33 AM
You're prematurely assuming there will be bottlenecks. Looking to optimize something, are you? You know what they say about premature optimization. ;)

What part of combat control will you work on? Converting user input (mouse, keyboard) into unit commands? Acting on units commands (moving units about)? Simple reflexive AI (if attacked, attack back, possibly charge in if out of range)?

How does this tie in with UE4? What support do they have? What is their API like for the parts you need to code yourself? Is there a specific part of it you're already familiar with that you plan to work with, or do you still need to read and learn what their API offers?
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on January 04, 2016, 04:36:55 PM
You are technically right I'm prematurely assuming there will be bottlenecks. But as almost every game seems to need optimization these days, that brings up the question, why do they need optimization? From looking at some games, (i'm staring at you bethesaida), these games seem to lack a consistent standard of quality throughout development and thus require the optimization. Though, in Bethesaida's case, you'd think they would know by NOW how to do a proper open world game, as Fallout 4 is their 5th mega-large open world game (haven't played any of their's before morrowind so only counting Morrowind, Oblivion, Fallout 3, Skyrim, and Fallout 4). They know their engine and their file formats back to front... why do their code have so many bugs? ... If you were an employer you'd expect that over time and over several projects, they would become more and more experienced, such that their quality goes up. With bethesaida, it doesn't seem like they learn anything as some of their bugs from Morrowind era, are still there in Fallout 4. I dunno, I expect bottlenecks, because many triple AAA games seem to run into bottlenecks and as a result require huge optimizations.

However, from what I do understand about optimization, its often things that developers have little control over directly, such as reaching your draw call limit. I heard that before Assassin's Creed Unity was patched it was hitting 25000 draw calls per frame, when the maximum they could do per frame to maintain a stable framerate was 10000. How does one optimize that?

Well, from looking at the documentation, I could create a relatively basic UI, and code specific commands to keybindings, instead of buttons on the interface. I had intended to create and test several basic commands, such as Move, Stop, Attack, and Stand Ground. I wanted to test out the hitboxes to ensure that weapons fire was indeed hitting the target and causing some kind of effect (ie loss of HP as a very basic example). I wanted to ensure that when a unit is destroyed, it leaves behind a husk; similar to those husks that are created in Supreme Commander when a unit is destroyed. Reflexive AI would also be something I'd want to test out; it would be important to test it out with a command like Stand Ground, to ensure that the unit will stay where it is but attack at enemies within range, but units without a Stand Ground command would need to move within range and attack.

I've spent some time looking at how keybindings work in UE4, and how to setup a way to rebind those keys. I've taken some time to also look at UMG, the tool used to create interfaces for UE4. I've messed around a bit with camera controls, to get the camera to the right angle and height for a RTS. You can create objects made from prefabs, and attach code to them and thus use them as temporary objects for units until the actual models are ready. From what I've learned from it most of the stuff is straight forward, but I still need to know how to setup the gamestate, UI/Camera and player controller for a RTS. I'd want to reread these sections again though in case they have changed much since 4.7 when I read them last (they've released 4 patches since then, with a possible 5th coming out soon) and as many patches have come out since then, its likely they have. A good place to start would be to check out, as suggested by someone here, the tower defense game demo that UE4 released for the engine and see how it does things to get an idea.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on January 06, 2016, 07:11:15 AM
I'm not sure I agree. I often get the sense optimization is less important these days. Hardware gets more powerful over time, and ever growing software projects rely increasingly on libraries and frameworks of already built, tested, and optimized code. I suspect optimization is now less of a concern at the application level. In many ways, optimization is choosing the right library function or data structure, rather than applying any detailed knowledge of algorithms or CPUs to get code to run faster. Which isn't to say it doesn't help to understand that stuff, as it helps you choose the correct library implementation to use. Programmer time, related to cost, is usually a bigger concern than CPU time. Higher level languages are chosen increasingly over lower level "fast" languages. (Languages don't really have an inherent speed. That's more an implementation detail). Essentially, get a product to market before you run out of money. Slow code is still better than no code. And on today's hardware, things will generally run good enough without special optimization, provided you didn't start with a terrible design. But this is all unsupported speculation on my part.

Of course the notion of programmer time being related to cost doesn't really relate well to hobby projects where there is no money. So, if it makes you happy, I suppose optimize away.

An interesting exercise is to consider the time cost of optimization vs the time savings of optimized code:
Project A: You need to run some custom conversion code once. It takes 4 hours to complete. If you spend 45 minutes working on it, you can get it down to 1.5 hours to complete. You need results quickly to continue on with the project.
Project B: You need to run some custom conversion code once. It's grossly inefficient, to the point of being offensive. It takes 5 minutes to run. If you spend 30 minutes working on it, you can get it down to 20 seconds. The code will likely never be run again.
Project C: You run the code every day for a year. It takes 5 minutes to run. After a day of optimization, it now only takes 4 minutes to run.
  Case 1: The code is done in a batch processing script overnight.
  Case 2: The code is run in an interactive desktop app.
Project D: You run the code every day for a year. It takes 10 seconds to run. After 2 days of optimization, it now only takes 0.5 seconds to run. The code is run in an interactive desktop app.

As for what you're working on, you've listed quite a number of things. Where do you think your next day worth of effort will go?
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on January 06, 2016, 12:14:02 PM
Well I suppose it really depends on how many things you want to occur simulataneously then, which is where optimization is necessary. Most AAA games these days tries to force as many objects on the screen with as many polygons as possible with the highest number of pixels of textures, with as many actors with AI onto the screen. You'd think that trying to have so many things would require optimization. Most operating systems have a finite cap on the maximum RAM used by the system (I'm not referring to the 32/64 bit stuff, but that different OSs of WIndows have different caps, such as I think Home Windows 8 is 16 GB, but Professional is 32 GB or something). Despite the need for it, not every game supports SLI or Crossfire support, which implies they expect you to use a single card to run the entire game and for some games that isn't feasible (ie if you have a powerful enough system, you can technically run Batman Arkman Knight on PC with 60 FPS, but for most people to run it they'd need SLI or Crossfire support, but it doesn't have it).

If your RTS only does 100 v 100 unit battles, it likely doesn't need much optimization or any. But if it is doing 1000+ vs 1000+ units, then optimization is necessary. As for my limited understanding, there is a cost involved in interpreting code at runtime with very high level languages (ie Scripting) and I wonder if that is partially why Supreme Commander had problems when you tried to have 1000 v 1000 unit battles as most of its code utilizes a Scripting Language (Lua I think). I've run Supreme Commander on this machine and I still get huge framerate drops into the single digits when there is over 600 v 600 unit battles. How does Outpost 2 handle having 1023 vs 1023 units (as I believe its said somewhere that you could only have 0-1023 as unit numbers without a stack overflow)? Its an older game, with far less graphics than modern games, and even though it uses one core, I still bet it doesn't function as intended (ie units not doing what you want them to do or not responding for a long period of time).

Actually it does still apply to hobby projects. Its called opportunity cost; the cost of something else forgone to do this activity. So if I spend 2 hours optimizing, then I can't spend that 2 hours adding in new features. Everything has a cost; it just isn't always money.

Next day of effort will go towards more adaptations; I've carefully analyzed my current position and how I've tried to do things over the past year, and without these changes and adaptations and changes of perspective, attempting to do this project will be an impossible task. Yes, impossible. Therefore, to succeed I need to make some tough changes. I've made many of them already and continue to work at it to make the rest. Maybe not what you wanted to hear, but it is what it is. I've doing things over the past year over and over in the same manner, and getting the same lack of results and I feel I would be insane if I continued to try and expect different results. Thus changes are necessary to ensure things are different this year.

Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on February 08, 2016, 06:10:35 PM
Well, I know its been a while since last I posted, but I'm finished with personal life changes, and have moved onto learning the various programs to work towards making a very simple RTS.

By simple, I mean something like:
- Headquarters structure (or starter structure) that builds other structures
- Factory structure that builds vehicles
- Vehicle with a gun

So you have two structures and one unit. The purpose would be to destroy the enemy base while preventing your own base destruction. It would be a simple way to design a RTS and ensure that I understand how to build the interface, various controls, and basic enemy AI, which are all foundational concepts that are needed for a more complicated RTS to function properly. So, over the next few weeks I will be working towards building this simple RTS prototype. From there, I intend to try and build on this foundation and create my more complicated RTS.

So I just thought I should update everyone that I'm now starting to move forward and the project isn't abandoned. I'll post back here in probably a week (sooner if someone replies) with my progress for the week. Cheers!
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: dave_erald on February 08, 2016, 10:10:52 PM
Awesome, let us know what happens and if you need help.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on February 09, 2016, 12:58:27 AM
Yes indeed.

You mentioned learning various programs towards making your RTS. Do you have a clear idea of the software you are going to use at this step?
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on February 09, 2016, 10:18:03 AM
The software I plan on using to create the RTS are:

Blender (modelling, building the uv maps, and rigging if necessary)
GIMP (making and editing uv mapped textures)
Audacity (sound editing where necessary; likely get some free sound effects from Free Sound)
Unreal Engine 4 (most of the work done here)
Visual Studio (apparently "required" to do C++, if blueprint scripting can't accomplish what I need)

Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on February 09, 2016, 11:21:10 AM
Visual Studio isn't required -- you could use something else like Code::Blocks if you knew which dependencies you needed to link to and how to set up the build environment with either GCC or LLVM.

I'm helpful. I know. /me takes a bow
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on February 11, 2016, 06:33:48 AM
Very good to know. Nice that you have your tools figured out.

What kind of sound editing were you thinking of doing?

Your tool set and goals still cover a lot of ground. Do you have a more detailed and narrow plan of action?
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on February 11, 2016, 05:52:35 PM
I'm doing quite a bit of planning and research to figure out what I need to learn, and focus on that for now. There is a whole lot of stuff I'd like to learn, but for now my focus is on getting something basic up and running, and functional; something that I can use as a foundation and build off of, or use it as a prototype, learn from it, and build something better with what I learned.

Preferably very little sound editing, as I don't have any sound editing equipment, just a program, so at best I'll be able to do some minor tweaks to existing sounds, with the intent that if I grab a freely usable sound, I might be able to work with it and see how to intergrate into the game. Since many freely offered sounds may not be of the same "tune?" it would require retuning them. I'm sure that's not the word for it, but when it comes to art design, there is a thing called aesthetic. If the art design doesn't match up, then things start to stick out like a sore thumb. Same thing with sounds.

Also, good to know that I might be able to use Code::Blocks; I've used Code::Blocks before, but never Visual Studio.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Vagabond on February 11, 2016, 07:35:49 PM
I've used Audacity in the past for changing audio formats. It also works well for minor edits like combining multiple sound effects, equalizing volume between effects, cutting out the beginning/end of sound effects, or fading sound effects in and out.

Be careful using FreeSound. Each file has a different license with differing requirements. Some require attribution in work, some are not allowed be use in commercial applications, and some do not allow editing of the effect, etc. I would read each license and make sure it is agreeable before taking the sound effect.

I'm looking forward to seeing what you come up with. Your end goals sounds like they could make an enjoyable game.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on February 19, 2016, 09:32:30 PM
Well, I'm making good progress with Blender. I've finished learning how to properly use Object Mode, and about half-way through learning how to use Edit Mode. There is a lot of possible options and tools available, but many of them are very contextual and thus only useful for specific tasks. I've focused on learning the tools that I'll be using most often to reduce the amount of learning needed and so that I have fewer shortcuts to remember.

Good to know about Free Sounds. I'll need to be careful in choosing sounds then. Thanks for the heads up!
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: dave_erald on February 19, 2016, 09:37:03 PM
Blender is actually fairly simple to work with, it's making good looking things that's a cock and a half to accomplish.

Keep it up!
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on February 21, 2016, 08:58:58 PM
Do you happen to know how to use Blender? I ask because I'm having a difficult time understanding how to apply a texture. This would be the texture made from the UV Layout exported by Blender after the mesh has been unwrapped to one's satisfaction. I ask because the manual doesn't explain the process all that well, and I've read multiple tutorials and each seems to explain how to do it in different ways, confusing me further.

Its the last thing I need to learn before I can consider Blender now learned (and thus able to move onto another task of learning for next week)

EDIT: After reading through about 6 different tutorials, I finally figured it out. Now if only I knew what a UV channel was...
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: dave_erald on February 22, 2016, 12:31:54 PM
Yeah I've only just started using Blender and can work my way around, with more practice I could do alright I think, I got some of the basics down but not an expert by any means.

This is where I am Wiki Books:Noob to Blender (https://en.wikibooks.org/wiki/Blender_3D:_Noob_to_Pro/UV_Map_Basics) which is about what I am

...a Noob
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on February 27, 2016, 12:30:29 AM
Everyone is a noob once. Practice good sportsmanship :P
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on April 09, 2016, 11:54:42 AM
Well, its been a while since I posted an update of any kind here, so... update time!

I've been working towards creating a very basic prototype in Unreal Engine 4. I've managed to create some simple, placeholder meshes for it, and exported them in FBX format. I've imported them into a sample project, and am working on adding some functionality to them. I have run into a lot of different and varied problems, but I'm still at it. I doubt my current work will be uploaded here until I can figure out how to do selecting and deselecting at runtime. I have found a youtube user that explains how to do it, as well as other RTS concepts in UE4 (https://www.youtube.com/channel/UCIEqFMmWhxF4yA4gowhFjNA/videos?nohtml5=False). My very first prototype, will likely lack selection as its a lot harder of a concept than I originally realized, and thus the prototype will play out like an automated simulation, without user input (as without selection/deselection, user input is next to impossible, unless you hardwire specific buttons to do a specific task [ie click R to recruit a drone]), and thus this simulation would run exactly the same way every time. But, its a start, and thus that's where I'm at.

Just figured I should pop in and mention what I'm up to, so that those who are following it know that I'm still at it. When I have something that is "playable" (ie something that has proper select/deselect enabled, with possibly multiple selection as well) I'd be more than happy to upload it here for people to look at.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on April 11, 2016, 02:29:29 AM
I noticed the YouTube page included a video with formation controls. Is that what you meant by unit selection? Or were you talking about the more basic band box selection of units, or click to select type functionality?

Do you have anything worth a screenshot? What about console output of code results? Or interesting snippets of code?
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on April 11, 2016, 11:48:41 PM
Currently I don't have anything specific worth showing at the moment. I had "something" but I accidently deleted the project, when I had meant to delete a different project, that was similarly named; will need to give my projects a meaningful name from now on to avoid this.

In Blender my meshes appeared to be complete (with all faces present; then again maybe they weren't as I was having trouble consistently being able to subdivide while other times it refused to subdivide), but when they got imported into UE4, several of them were missing faces entirely or had lighting building problems, so I'll need to rebuild most of my meshes. Which isn't a huge issue as many of them I didn't like in the first place.

For selection I had meant click selection or click deselection. Though, I will want to have marquee box selection, multi-unit selection, and formation movement at a later point, but my priority is to get mouse button selection/deselection working properly.

I messaged the creator of the videos and he suggested that all of the RTS logic can be done exclusively in Blueprints and suggested I follow along his "RTS Series" tutorials (each video is about 2-3 hours long a piece, so it might take me some time to get through them fully). He also mentioned that if I have any questions on how to do something specific in blueprints I can message him for help, which will be quite useful methinks.

Not much in way of code snippets or other visual elements. For my initial prototype I had wanted to show how key input could modify the values on the User Interface, but that didn't work. I redid the tutorial and figured out what I did wrong, so that perhaps for this week's prototype, it will have some UI numerical changes present (ie Build X object, consumes X resources, which shows up on the interface).

It looks like I will have a busy week working through tutorials, but should have something worth showing at the end of the week, screenshots, or something "playable".

EDIT: Correction, the shortest tutorial in the series is 2-3 hours in length. The longest tutorial in the series is nearly 16 hours in length. I may not be able to cover the entire series in one week.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Vagabond on April 12, 2016, 12:01:27 PM
It would be cool to see a couple of your models if you want to post some renders, even if they are not 100% yet.

Once I start spending many hours on a project, I start thinking of backup or version control. The last thing someone wants is an accidental delete or hard drive crash losing 40 hours of work.

I used to just zip my coding projects once a week and save them to an online cloud service. A lot of cloud services offer enough free space to do this without paying. Now, I typically save bigger projects to a private repository. A couple of sites offer free private repositories. I've had good success with Bitbucket in the past which allows either Git or Mercurial. Of course the downside with using a repository is that you have to learn the syntax which can be daunting while also trying to learn 3D modeling, programming, and game logic.

Looking forward to seeing your continued progress.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Sirbomber on April 12, 2016, 04:01:38 PM
I had "something" but I accidently deleted the project
You have failed.  Our colony is doomed. (http://www.youtube.com/watch?v=8tm4p53yrts)
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on April 12, 2016, 09:32:17 PM
Its okay, what I had wasn't all that much, so probably not a huge loss. I'm however working through the first video in RTS Series, and have setup the camera and camera movement. Will have to rewatch the first 30 minutes again though, as he mentioned a lot of interesting tidbits that I didn't have time to catch (was busy making sure I had the right nodes in the right order, as he goes fairly quickly and had to pause the video quite a bit to make sure I had the right thing). Once I'm done the tutorial, I'll figure out what each thing does so that if I need to modify it (which is likely, as he is going for more of a C&C type RTS) I'll be able to do so.

By code snippet screenshots, would a screenshot of my Blueprints and their nodes suffice? Not necessarily C++, but the scripting is based on C++ logic (and can be used interchangeably with C++). I'll likely need to change some things into actual C++ code at a later point but right now I just want something that is functional and workable; figure out if it needs optimization later on, and concern myself with optimization then, rather than now (as many such as Hooman and leeor_net have suggested that I don't worry about optimization at this point)
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on April 13, 2016, 07:57:23 AM
The usual response from Sirbomber I see.

It's good that you have tutorials to go through. That can be helpful. Sometimes it's nice not to just learn about some technology, but to actually see the workflow of someone using it.

I would suggest using a version control system, with a repository on a separate computer that you can push to. I've also used Bitbucket (https://bitbucket.org/), and yes it's nice they allow free private repositories.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on April 13, 2016, 08:53:41 PM
The usual response? How many times has this been his response that caused him to be associated with this response as his usual response?

Well, as I said before the engine can be adapted to a RTS, but doesn't support it out of box. If I hadn't found his tutorials, it would have taken me a lot longer to create it. However, my intent is that once I understand how to make the basic foundation work, then I'll diverge and start making the game I want to make rather than copy/paste what the tutorial is doing.

Well I'll have to take a look into something like that in the future. Right now I just want to be sure I understand the fundamentals before building something of worth on top of it.

Sorry I missed your post!

I can do that, would you prefer .blend files, .fbx files, some other format, or just screenshots? I mention the other three in case you wanted to see them in 3D space. Though as my modelling skills are developing faster than my 2D texture skills, I'll likely either use a placeholder texture or leave it untextured.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Vagabond on April 14, 2016, 01:37:31 PM
I would be happy looking at 2D renders. No need to send in 3D form.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on April 15, 2016, 02:29:34 AM
The usual response? How many times has this been his response that caused him to be associated with this response as his usual response?
According to search results, 3 times. Ok, so not quite as many times as I thought.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Sirbomber on April 15, 2016, 04:01:58 PM
I think I'm owed an apology. :P
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on April 16, 2016, 03:16:23 AM
You're right Sirbomber, I'm sorry.

Here's a link to a video apology:
https://www.youtube.com/watch?v=dQw4w9WgXcQ (https://www.youtube.com/watch?v=dQw4w9WgXcQ)
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on April 23, 2016, 03:37:21 PM
Well, I've been continuing to work at it. The camera controls are working now, and can Pan, Rotate, Edge Scroll, move with WASD keys, and Lock the Mouse Cursor to the screen. Been running into issues with the second tutorial, and thus haven't gotten very far with it yet. My two biggest gripes is that one, the tutorial is LONG and two, its highly disorganized, and thus the tutorial maker often makes a mistake and deletes things, and then I accidently delete the wrong thing and basically have to redo that section of the tutorial all over again. I'm about 30 minutes into the 6 hour long tutorial, and have had to repeat it three times now. However, hopefully, with enough persistence I'll get through this one as well; the tutorial covers User Interface creation, Building Placement, Ghost Buildings, and Building Selection, for those wondering what I'm working through right now.

Gameplay wise, I have "plans" for two asymmetrical factions; one plays like the Campaign-Outpost 2 (Human Faction), and one plays like the Multiplayer-Outpost 2 (AI Faction). The initial game prototype will have only the AI Faction, and play out much like Outpost 2, but without combat/conflict, so basically a city-builder like Eden Starship, but without any enemies ever attacking you. How I want it to work is that, the Human Faction must cope with Morale while the AI player does not, and if the Human Faction manages to maintain high morale, they can actually do things faster and better than the AI faction. Though, if their morale drops, they perform worse than the AI faction, and thus the player who plays as the AI Faction, will constantly try to exploit that problem by destroying civilian structures (and thus kill that player's morale). While, the AI faction has its own shortcomings that it must deal with, in particular it's "Brain" requires constant maintenance in the form of circuits (as it burns them out regularly, just like an Overclocked Computer would) and thus needs a steady supply of resources to perform this maintenance. So, the Human Player would be focused on destroying the AI player's supply lines and thus attempt to blockade them and kill them by attrition from lack of maintenance.

I realize that this will mean that I will have a Design Document #3 (DD3), as this changes quite a bit of my original ideas. Many of my original ideas from DD1 and DD2 will return, but as each faction will function quite differently gameplay wise, changes need to be made.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on April 27, 2016, 07:09:11 AM
Sounds like a good amount of progress. Also sounds like you have something rudimentary to look at now. Anything worth a screenshot? I guess what you're describing is more suitable for a video though.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on April 29, 2016, 06:52:30 PM
I could look into providing some screenshots of blueprint graphs if you liked, but as for visuals there isn't really anything to see yet. I'll give a screenshot of what I mean by that so you can judge for yourself. By the end of this tutorial I'm doing, I should have something visual to see, but right now, its mostly just setting up the foundation.

Image "ViewportNotPlaying" = In this image you can see a simple, flat mesh with a terrain texture applied to it. The four textureless boxes are called "Bounding Volumes"; these act as invisible walls so that things on the flat terrain mesh won't be able to leave or fall into the infinite abyss all around it.

Image "ViewportPlaying" = Here you simply see a placeholder sphere mesh that helps in bugtesting to make sure that the various camera controls are working and to ensure that the mesh changes position properly on both your client and on another person's client. Later on, this sphere will be removed but is simply used for now to prove that the camera controls work; later it will be replaced with units and structures that will be selected instead.

So, yah, not much to look at the moment. But, hopefully with diligent effort I should have something to show later, visual wise. Still having problems with Blender to UE4 import process with problems with the meshes, so not quite sure what the problem is there, so not going to show off any of my meshes until I know for sure that they will import properly into UE4.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on May 10, 2016, 11:16:08 PM
Ahh, interesting. Thanks for the screenshots.

Is there a reason the bounding volumes overlap? How did you determine the height of the invisible walls? Will there be a way to create randomized powerful combined explosions, that just might have the strength to send something over the wall, sending it tumbling down into the infinite abyss?
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on May 12, 2016, 12:16:14 AM
Well, the reason they overlap is because that's how the tutorial maker did them, so I merely replicated that. However, you can definitely increase the height, width, and length of them to prevent such an eventuality. But, I'd think the best way to address that kind of issue (of sufficient force applied to objects) is to do what most games do with invisible walls; have the invisible walls say 10% away from the edge of the map, so that if something did have sufficient strength, it should still land within bounds. Or just have really, really high mountains. I would say that having really high bounding volumes might break immersion when you see a seemingly open area and see an object blown up collide into thin air and then drop to the ground.

Well, with sufficient force I have found that one can overcome extremely high bounding volumes anyway. There is a FPS barebones project where the ball (ball gun) hits with force to move cubes around and if you add enough force to the impact, those cubes go flying. So its probable. How to prevent it entirely could be a matter of boxing in things with a top-layer bounding volume (to seal everything in) or to limit the amount of force applied to objects from an explosion. Realistically, most objects wouldn't have enough force to launch objects very far... unless it was a nuclear explosion or hilarious ragdoll physics (ie Skyrim).
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on May 12, 2016, 08:45:22 AM
I approve of "hilarious ragdoll physics".

The ceiling idea should work. A reasonably high ceiling of course. Then if someone manages to somehow take out the walls we can have a Chicken Little effect.  ;)
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Vagabond on May 12, 2016, 08:24:08 PM

Thanks for posting the screenshots. I missed them earlier.

You could write code that removes any objects that manage to escape your bounding volumes. This would prevent errant objects off screen from causing bugs.

You could also have disposable objects like projectiles disappear when they touch a bounding volume to make it appear as though they traveled off the visible map instead of exploding when hitting the bounding box. Unless your units fly an unusual distance, they could probably just 'bounce off' the bounding volume or stop moving when touching the bounding volume and not look too bad.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on May 13, 2016, 02:59:13 AM
@Hooman; Yes, a reasonably high ceiling would likely work.

@Vagabond; Well, similar to a bounding volume, you can have other forms of volumes that could trigger an OnOverlapEvent, where bullets/projectiles would simply disappear, so its very likely code could be fairly easily written to accomplish that task. So, how I'd see something like that working, is to have first a bounding volume that prevents most things from leaving, while allowing projectiles to pass through it (so they don't appear to just hit an invisible wall) and then disappear afterwards.


I'm keeping at it, and continue to make progress with the tutorials I'm following, but more importantly, I'm actually understanding things, and figuring out ways of adapting some of the current systems to do other things. As an example, in the tutorial, it uses a scaling box to show a list of units or structures when the appropriate button is clicked or the structure clicked (just like in any C&C game if you need a visual reference for that; the tutorial hasn't covered how to create the list yet, so I don't have a screenshot of it yet). My idea is to use a similar listing+scaling box to do the research tree, where the tree can expand (as topics get researched, more becomes available OR expandable for modders to add in new research topics and have the game's research tree visually scale appropriately) or contract (as you finish off the research tree, the list might shrink in size until all available topics can be seen on the screen without scrolling). So, even though at times its frustrating (the guy rambles a lot and gets off topic a lot) I am comprehending things enough to realize how things might be adaptable for other purposes.

I do want to eventually have something playable (functionally playable at least) for people to try out. A growing trend in the games industry is the importance of having UX (User Experience) involved in helping a game be the best it can be. Many sites (that discuss UX) suggest that getting it as earlier as possible is extremely important so that major problems with interface or gameflow can be addressed early on when its easier to fix them; plus its suggested that UX can help a developer find bugs in the code that they didn't know existed. I know there is a risk in a showing off something when it is in such an early stage (first impressions, right?) but I feel the benefit of getting early UX is better in the long-run. Afterall, if suggestions make the UI a lot better, and just the UI (not considering all the other benefits of UX) that can really help make or break a game. Since the UI is one of the key things that reduces complexity of the user. Thus having a good UI aids a player in understanding the game by making everything more intuitive, reduces the learning curve, and makes making complex decisions a lot easier.

But, I may have a long way to go before I have something playable. BUT I WILL GET THERE! ... Eventually. :)

Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on May 14, 2016, 02:36:28 AM
Sounds good so far. It's fun seeing your updates on this.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: CK9 on June 28, 2016, 12:00:17 AM
Haven't read through th whole thread yet, but wanted to congratulate you on your dedication (If I'm not mistaken this is the longest running project so far?).

If you're still open to suggestions, I would recommend going beyond just an Outpost 2 -esque point in the story line.  I don't know how anyone else feels about this, but I think it would be an interesting idea to have it start out with the death of Earth instead of having it just a part of history.  I feel this gives the player a chance to feel more connected with the story and more of a reason to choose one side of the conflict over the other as it develops instead of being present with "oh, we have philosophical differences that pre-date you.  Choose a side."
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on June 28, 2016, 02:13:17 AM
*cough* OutpostHD (http://forum.outpost2.net/index.php/topic,5718.0.html) *cough*
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: CK9 on June 28, 2016, 10:58:17 AM
lol, I'm still catching up on what I have missed while I was on a minecraft binge :p

also, if any of the projects could use assistance, I am actually capable of lending a hand in coding now (been teaching myself more advanced C++ and the windows API by building a cribbage game from scratch).
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on June 28, 2016, 05:36:01 PM
Head on over to the OutpostHD form, check out a copy, check out the redmine tasks and see if you're up for some of the challenges! I'm writing the game in portable C++ using NAS2D and its libraries to handle the platform specific stuff.

And with that I end my thread hijack. :D
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on June 28, 2016, 08:22:47 PM
Yep, I am still at it. Been having difficulties with some aspects of the tutorials as the tutorials were done in V4.8 of UE4, and I'm using V4.11 (I know V4.12 is out, but don't want to upgrade yet to it). So some features that were easily accessible in V4.8 are either hidden away now in different spots, are modified in some way forcing you to be careful of the choices being made or the feature he is using/abusing is now depreciated. So, progress has been slow as I've been having to troubleshoot and address problems as they come up which has slowed my progress. I want to be sure that the issues I'm running into are resolved before I move on so that 1) I don't forget about them and 2) So that my program functions almost identically to his so that when he runs his program mine looks similar to his so that I know I'm on the right track. I would have wanted to be farther along than I am, but sometimes these things happen, and the code that is currently being worked on is the basic structure construction code (Currently it is a basic C&C structure setup but will show later in the tutorial how to get a vehicle to do it):

Click Button on UI (ie Defenses) and display a List in the Scaleable List part of UI of all buildable options -> Ensure an Appropriate Structure Exists and if not leave UI Scaleable List Blank by Defaulting to a Specific List (ie if you clicked defenses, ensure that you have a construction yard built before displaying defenses list)-> Click Structure Desire to Build -> Produce Ghost Structure Outline -> Determine Structure Placement -> Remove Ghost Structure Outline and Replace with Actual Structure -> Begin Resource Consumption for Structure Construction -> And other steps involved (listed the most important).

So the big problems I'm running into at the moment that is slowing my progress considerably is trying to get my code to do the same thing his does when he is using a depreciated feature. I've addressed most of them, and once I finish off with the last one I'll be able to continue with the tutorial.

I am still very interested in creating it, but progress lately has been slow. Hence why I haven't updated with any recent news... though the absence of news does seem to make it look like I've given up, which I haven't.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on June 28, 2016, 11:17:24 PM
I'll give you one thing for sure -- you've continued to plod along at whatever pace you can manage which is more than a lot of people can say. My project -- same deal, sometimes there are just long stretches where things are on hold for a short while. It happens.

Keep on keeping on.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on June 29, 2016, 03:34:01 AM
long stretches where things are on hold for a short while
I call contradiction on this. :P

Good to hear you're still working on the project.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on June 29, 2016, 11:45:56 AM
I was tired when I wrote that. Sue me. :P lol
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on June 30, 2016, 08:17:31 AM
Are you leeor_net? Yes? You have been served.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on June 30, 2016, 11:50:58 AM
Nice. lol.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on December 26, 2016, 01:43:08 PM
Been awhile since the last update. What your progress been like?

I've been thinking about ways that we can all help each other out. In Admin we talked a lot about switching over to GitLab for hosting projects. Was wondering if you had thought about doing that? I don't know if you have much to show for this yet but I'm still interested in how it's progressing.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on January 11, 2017, 06:04:48 PM
Yes, it has been a while since last update. Progress stalled for a few months due to a combination of issues but I'm back at trying to make it work, with a better understanding of how to succeed. The issues I ran into were:

1) A tutorial designed for an earlier version of UE4, where the version I was using had deprecated many of half-assed duct-tape features in the older version with brand new features, but with no documentation on how to implement these new features to replace the half-assed duct-tape features. Additionally, certain things you could do in an earlier version of UE4, isn't supported now, and attempting to do so will result in complete project corruption. This is what initially caused the stall in development; the complete loss of my project files as the project refused to load, citing data corruption issues. It took me a few months to figure out why the data corruption occurred and how to prevent it in the future, but, this means I can't use the tutorial I had worked with for 6 months anymore to create a foundation for my RTS. LAME...

2) I tried to troubleshoot the problem with the creator of the tutorial series, and the only suggestion he could give me was to build my game in the earlier version of UE4, for which the tutorial was designed for. However, that means giving up on about 1.5 years worth of UE4 updates and new features, which I feel is an unacceptable loss... so been hunting around for alternatives. The only possible way to make this work is to just use an earlier version of UE4, do this tutorial to learn "some stuff", and then treat it as completely throwaway as the project will instantly get corrupted if I were to update to the newer engine update. As the tutorial was made in early 2015, and the tutorial maker has no interest in producing an up-to-date RTS framework in UE4 with the latest update, this has resulted in quite a problem for me, as I don't know for sure if I can actually apply knowledge from this tutorial to the newer UE4 as many of the half-assed duct-tape solutions do not work anymore, period and as the entire tutorial series is about 60 hours long, which with all the stops and starts and restarts (he has quite a lisp and accent making some words nearly impossible to understand) will be about a 120-180 hour time investment.

3) I have found buyable RTS frameworks for UE4, on the Epic Store for assets and stuff, for relatively inexpensive costs (between $10-$60) however, this raises three issues. (1) I cannot demo the project to see if it is what I'm looking for, and thus I could buy one and find out it will require a lot of effort to tweak to what I'm looking for (as any framework can be tweaked with enough effort for those determined to make it work). (2) The whole reason I was trying to go the tutorial route was so that I actually understood what each part of the framework actually does and if I buy a framework, I may not be able to actually understand it. (3) I'm still learning, and am quite a noob at blueprints, and as unreal documentation is very bare bones, I need to know how to use a framework, and how to build things into it and know how to troubleshoot it. Most of the frameworks, do not come with a manual on how to use them, expecting the user to automatically understand them before purchasing them.

4) As much as I like the Unreal Engine, and all it offers for free, I'm starting to realize the immense difficulty in building a RTS in it, after trying for several months to build one. I'm sure people here suggested that I don't do so, and honestly after trying to learn UE4, getting frustrated with data corruption and error reports and the engine refusing to accept my models without butchering them in some way, I don't think I will bother with making a RTS in UE4. I do still want to make one, but UE4 is just not working out. When I first started the project and started learning with the tutorial I was hopeful, dedicated, and determined to succeed in UE4. However, with all the problems I've had, all the terrible documentation, the difficulty in getting help (someone can't provide a good solution if you don't fully understand your problem), and all the crap I've had to put up with... thus, trying to build a RTS in UE4 feels like climbing a mountain, while artillery rains on your head, and cannibals are chasing you up the mountain... TOTAL INSANITY.

That is why I haven't posted in a while. I've been knee-deep in the trenches of trying to get my UE4 RTS to work, and just have not been successful at all. I am open to suggestions of other possible engines to work with instead of UE4. I am committed to making a RTS, similar in theme to Outpost 2 (real-time, warfare and colony aspects both equally important) but as I've reiterated above, I cannot see it happening in UE4... unless Epic makes a dedicated framework, with documentation for a RTS, I doubt I'll be able to create a RTS in UE4.

Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on January 12, 2017, 11:51:05 AM
This sounds more and more like you're trying to force an engine to do your bidding without understanding how that engine works first. Development doesn't work like that. You can't sit down with a tutorial and suddenly have a game. You should be learning how to work with that engine, learning its strengths and weaknesses, its scene graph structure, its object model, and so on before you attempt to do anything even remotely as complicated as an RTS.

X-COM, a turn based strategy game (an award winning one, at that) uses the Unreal engine. It's not a far leap to go from a turn-based strategy to a real-time strategy. That tells me everything I need to know -- it's entirely possible to develop just about anything in that engine.

I've been looking into the engine a bit myself recently and am floored at what it's capable of, how well tuned the whole thing is and how easy it is to get it to do what you want. So the question I pose to you is how is it that you're having so much difficulty with it but after only about two hours of working with the toolset and engine I have a firm grasp of how it all works?

Keep in mind this isn't a case of me saying "I'm smarter and better than you". I don't believe that at all. I'm simply saying that I have a greater understand of game engine design from years of experience. I'm also not sitting down and attempting to build a very complex game on my first try out the door.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on January 13, 2017, 03:25:11 AM
I suppose I have a different view on what is or isn't a game than you do, as I felt that you could have a fully working game by doing a tutorial; it may not be a deep game but it would still be a game. I guess it also depends entirely on the tutorial in question too, as the tutorials I was looking at explained how to create a very basic RTS, with maybe one or two units of each type (ie land, sea, air, structure, turret, etc); it wouldn't be enough units for a commercial build, but it would allow for basic gameplay, movement, and unit commands.

I thought the point of tutorials was to learn how to work with an engine and learn its strengths and weaknesses. Also, have no clue what you mean by "scene graph" or "object model". (EDIT: Unless 'Scene Graph' is referring to how the game processes/renders each frame or 'Object Model' is referring to how it manages the objects of classes, as U-Classes are written originally in C++ and thus an object would be an instance of that class)

X-COM may have strategic elements, but it functions more like a Turn-Based RPG like Wasteland 2 or Divinity, which is VERY different from a turn-based RTS. When I think a turn-based RTS, I think of something like Alpha Centauri, Civilization, or Risk, which is often much more "macromanagement" focused, whereas X-COM is more "micromanagement" focused.

The best analogy I can give you to explain my difficulties in learning it is this: Take someone who has never used a computer in their life, and have them play a video game like Rise of the Tomb Raider. After two hours, you might comment on why do they suck so bad, are stuck on the very first section of the game and are getting constantly killed. You don't understand why it is so hard for them, as you play video games regularly, and even though you were a noob when you picked up Rise of the Tomb Raider, you learned quickly and managed to succeed. You learned quickly because a lot of gaming skills, that a person develops, are easily adaptable for any situation; if you've played one FPS, you can learn a new FPS quickly as you know in general how it will play. However, those who lack gaming skills have to learn everything from scratch and until they have acquired those skills, the simplest of tasks are nearly impossible to achieve. Consider, if you don't know home row and where your keys are, how hard would it be to play most games? The similar situation applies to me; I lack the game development or learning skills necessary to grasp the engine quickly, whereas you have those skills. Thus for you, you can take a look at the engine and very quickly adapt skills you already possess and learn the engine within 2 hours; a task that would possibly take me 100s of hours to accomplish. I don't have the skills yet, which is why I'm having difficulties and acquiring the skills necessary is not an easy task, as most tutorials assume you HAVE those skills. That's the best way I can explain things.

No, it is a case of you having skills that I do not currently possess, nor do I have an idea how to acquire them. Thus, things have been slow and frustrating with development. So, I've been focusing lately on improving cognitive shifts to R-Brain thinking, to better understand what things are causing me to get hung up on, from a different mental perspective, and thus address them and move forward with my learning process. 
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on January 14, 2017, 09:31:53 PM
Well, I decided to stick with UE4, and keep trying to resolve my difficulties, instead of switching engines. I just needed to vent my frustrations and now that I have I feel better and am back at it trying to get around my issues. I'll likely update this discussion topic once I've gotten some actual, worthwhile progress to show. That or I get that long promised Design Document put up. Whichever occurs first.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Vagabond on January 15, 2017, 12:30:13 PM

Sorry to hear about your frustrations with programming and UE4. I've been there before too. There are a lot of tough obstacles learning to program well, and I'm still learning a lot myself.

I've never used the UE4 engine before nor looked at the tutorials you were using, so I can't offer any specific advice about either of them. I'm actually most familiar with C# and a game framework called MonoGame (used to be XNA), which I very much enjoy programming in. But it took me a very long time to feel comfortable with C# and MonoGame. There is still a lot I don't know.

I'll put out some general advice, but feel free to ignore it if you wish. Everyone learns differently, and I don't presume to know for sure what is best for you. If you haven't already, consider doing some research on finding a good book on UE4 and another on C++. For C++, if you have spent a lot of time in a beginner book, maybe pick up an intermediate book. Then when you are working on your RTS and have questions about either C++ or UE4, you can spend  dedicated time reading/re-reading about your issues. I would sometimes read a section several times before starting to understand what a given book is trying to tell me.

The way you described using features that were removed from future versions of UE4 and were like band aids made me think of a quote I read once by Douglas Crockford (from the book JavaScript: the Good Parts). He basically said try to figure out what a programming language is designed to do. Use it for the intended purposes. Try to stay away from what it does poorly or using it in a way it is not designed. He was getting at that JavaScript is designed differently that C++ or C#. So someone shouldn't try to use the language as if it were C++. Someone will be most productive using it as intended and choosing a different language when more appropriate for the project. I think this applies for frameworks and engines too. Is one of the main features of UE4 to provide an engine for designing a RTS game? If not, then it is probably a poor choice. If it is, than it is probably at least a decent choice if not a good one. But then more specifically, try to use UE4 how it is designed. If you know a feature is being deprecated, don't use it. Don't try to use hacks to get the framework to do something it shouldn't. The tough question for someone new to the framework and the genre is probably how to use it properly. That is hopefully where documentation and a good book come in to help.

Don't feel like you need to program on the bleeding edge. Using an engine that is dated by a couple of years isn't necessarily a bad thing. It means there will be less bugs and the persistent bugs will be better documented. An older framework will probably have more reference materials than one that just came out. And typically if you understand an older version, it will not be too difficult to learn the new features that were added in a newer version when you actually need them. The reality is that most games programmed at a hobby level will not require bleeding edge features.

Anyways, try to stay with it. Hopefully with time, you will start to crest a hill where you start recognizing more and more of what is going on. Slowly, things will become easier and you won't have to pause to read reference material all the time as you program. Eventually, with practice you will see your productivity moving faster and faster on your game.

I look forward to hearing how it goes moving forward!
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on January 18, 2017, 02:29:15 PM
I guess the best question I can come up with is did you go with that RTS tutorial as your first tutorial for learning to use UE4? I'm going to hazzared a guess and say that you used that tutorial as your first.

Anyway, yes, tutorials are designed to learn how to use an engine. But if you don't have a solid foundation to work with you're not going to succeed. Your diffulties are a case and point. Because you don't understand the engine or how to work with it, the tutorial isn't working for you because you don't know the shortcomings of the tutorials. If you understood the engine and knew how to work with it, when you came across something in the tutorial that doesn't work, you'd be able to say "Okay, cool, I know why this isn't working" and address it.

Also note that building a game off a tutorial is probably worse than building a game off a prototype. I've seen a number of people try to build 3D games using code from NeHe's OpenGL tutorials -- while those tutorials are suitable for learning how to work with OpenGL, you simply can't build a game off them and if you did, it would be a terrible mess.

Scene Graph -- that the way an engine manages a scene including static and dynamic geometry and objects.

I may be using object model inappropriately -- I'm speaking of how objects are represented in a game (or other application) vs, how they're represented as a particular language construct.

To address some of Vagabond's questions:

Is one of the main features of UE4 to provide an engine for designing a RTS game?

No, but it's not poorly suited to this task either. It originally started out as a FPS engine but has since expanded tremendously and is extremely flexible. It uses a Blueprint system to model the logic for any game built with it. I've seen many kinds of games built with UE4 including shooters, turn based strategies, tactical strategies, tower defense, top-down dungeon crawlers and more. At its heart it's a very powerful real time rendering engine with great network code and a hell of a scripting system to allow you to do pretty much whatever you want.

Using an engine that is dated by a couple of years isn't necessarily a bad thing. It means there will be less bugs and the persistent bugs will be better documented.

I would disagree with this. Spring comes to mind. It's hardly a bleeding edge engine but it's also not well suited to ... anything and is loaded with bugs despite being a decade or so in age.

There is also GLest which is an RTS engine better suited toward what Lord Palandus wants to do but it's extremely dated, hasn't seen significant development in a long time and, like Spring, is loaded with bugs.

I'd like to reiterate what I stated a few months ago.


You've decided on UE4. Excellent.

Now you need to learn the basics of it and how to get it to do the things you want. Build small projects with it that represent individual things you need to do.

First thing's first -- unit selection and movement. It's a very simple yet extremely important function.

Second, building placement. This one is a little more difficult but is also extremely important.

Third, unit/unit and unit/building interaction. Without this you don't have anything.

Fourth, unit construction through an interface accessible through a building.

Fifth, resource collection.

Those five things are the bare basics of any RTS. If you can figure out how to do each of those things separately (I cannot stress this point enough), then you can figure out how to make them work together. Do not expect to sit down with a tutorial and have something good to show for yourself -- as you can see, it won't happen.

And remember, I'm not saying "You suck, piss off." I'm sharing my experiences with you in how to learn the development process of a game. You absolutely need to start small. If I were to sit down today to build an RTS I'd start pretty much in that order. Once I figured out effective ways to do these things I'd settle in to build a fully working prototype demonstrating the core features and build off that.

Also something I didn't comment on until now:

How to prevent it entirely could be a matter of boxing in things with a top-layer bounding volume.

No! Don't do this! In your case if something is hit with enough force to leave the 'play field', just have it disappear. If it's exited the boundaries of the play field than it's no longer in play. But this is something that's determined by the rules of the game.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on February 17, 2017, 03:08:58 AM
It's good to hear you're sticking with the project.

I still know nothing about UE4. You're farther ahead than me on that.

As an aside, who here has written an RTS? I know I haven't. I've tinkered with them, yes, but I've never actually written one.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on February 17, 2017, 12:44:29 PM
It's good to hear you're sticking with the project.

Agreed. I think I have a tendancy to come across as adversarial which isn't my intention.

As an aside, who here has written an RTS? I know I haven't. I've tinkered with them, yes, but I've never actually written one.

I did a long, long time ago in QBasic. It wasn't full fledged but I had the basics of it from a Dune clone perspective (this was like... 1996 so holy crap over20 years ago, I'm flipping old!) -- resource gathering, building placement, unit selection and movement (movement code was terrible, I hadn't yet figured out path finding algorithms).
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on February 18, 2017, 05:52:15 PM
@Vagabond; Thanks for the advice.

@Leeor; Its hard to determine emotion when one is only dealing with text. In a sense, it does seem like you do come off as adversarial, but at the same time, I can see that you do actually want to encourage success, just that success often means completing small manageable steps and not trying to do the big project all in one go, particularly without experience of doing a big project all in one go. Also thanks for the helpful, wall of text, advice above.

@Hooman; Yes I am still at it. I still want to do it.


On other news, after going through about 5-6 written prototypes, revising features, simplifying complexity, improving depth, eliminating un-fun components, and thus, I've finally decided upon the, final, desired written prototype, to build the design document for the game. I'll look into posting a link to that in the coming weeks. And this time I intend to complete the design document.

The short-version is, that the early game will play fairly close to Outpost 2, the mid game will play similar to Outpost 2 with some deviations, while the late game will function very differently from than Outpost 2, with logical lore-complying reasons for the change of pace and play. So, the intent is that the early game will have much of the micromanagement focused gameplay, while the mid-game is starting to shift from micro to macro, and the late game macromanagement focused.



Progress is proceeding nicely with the design document. I intend that for each major section, there will be a too long didn't read (tl;dr) section that summarizes the stuff in that section and then following it is a more descriptive information on the mechanics. As an example, for Weapon Systems, the tl;dr section simply lists the weapon systems and at what point in the game you will acquire them, while in the descriptive section, it gets into the mechanics of those weapons, their pros and cons, and their overall purpose.

I also intend to have a section that will give some example gameplay to help the reader have a better idea of how all the various things will work together. Its nice to read the specific features such as weapons, vehicles, structures, etc, but having an idea of how all those things tie to together to make the actual gameplay that a player might experience on a moment to moment basis, is very important. There will be sample gameplay sections for early game, middle game, and late game. Additionally, during late game, with research, you get access to powerful, yet optional, new technologies that solve early/middle game problems in unique ways. They are again entirely optional, but can help out with problems you might encounter in late game play. An example, is the Cyrosleep Facility. This place allows you to put colonists to "sleep" and thus those colonists do not effect the "Employment Rate" and also do not effect the "Birth Rate". Thus, this structure allows you to much more easily control your morale by avoiding extreme numbers of unemployed people and also helps to control the birth rate as there is fewer people that are counted to determine how many births occur during that tick.

I'll keep at it and hopefully be able to show it off soon enough.

Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on February 25, 2017, 06:14:52 AM
You're fired. Now get in the tube.  :o
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on March 01, 2017, 05:21:12 PM
Heh, close enough.

Mostly its designed to address a problem I encountered a lot in late games of Eden/Plymouth Starship, where your population growth is out of control, birthing 2-3 children every 30 seconds, and the player has in excess of 20-40 workers, and no new tech projects to do and thus 30 something scientists, and you can only micromanage so many ConVecs and Structure Factories and thus keep up with both the unemployment or even managing to have enough Medical Centers, Residences, or Recreational Centers to keep up with the load. If the player is able to control that by putting those workers and some of the scientists away, it would really help out a lot.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Sirbomber on March 02, 2017, 03:47:44 PM
Idle the Nursery and spam DIRTs and Medical Centers.  Problem solved.

I honestly don't like this idea.  At all.  You've identified a problem: population booms too much in the late-game and there's nothing for those extra workers or scientists to do.  I feel that the correct solution to this problem would be finding a use for that excess population, or tweaking the growth formula to reduce population size.  An option to get rid of people (and bring them back) as it becomes convenient doesn't feel like interesting gameplay, nor does it feel like it adds a useful tool to the player's repertoire - rather, this just seems like an additional nuisance for the player to micromanage while it steals their attention from more important things.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on March 03, 2017, 12:12:31 AM
So what happens during power shortages, power cuts, or other offline events? Is it like when silos lose their storage when they go offline?  ;)

I think it'd be interesting if the evacuation module didn't bring everyone at once. It'd be neat to coordinate several launches to get the needed population onto the starship. Dwindling people left behind to run the colony and complete the evacuation. Also more possibilities to mess up your chances of winning, not having enough colonists left on the ground to complete the operation.

Though in terms of population control. Idling the nursery does seem to be the way to manage it.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on March 03, 2017, 12:40:15 PM
Well, if I made it so that idling the nursery didn't cause a morale penalty (as you get a morale bonus is one is active), then I suppose you wouldn't need a Cyrosleep Facility. That's kind of the reason why I had devised it as anytime you idle the nursery you get like a consistent -5 or -10 to morale every tick, which drains your morale down to 40s or 50s and stabilizes there. However, if the requirement was to have a nursery at all, rather than one that is active and employed, then idling the nursery would be a better solution.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on March 04, 2017, 04:55:31 AM
A nursery can have a heavy effect on morale early game in Outpost 2. If your morale drops to 40-50, and it's late game, there are causes outside of an idle nursery. Perhaps a part of it is the large numbers of unemployed people that caused you to idle a nursery, negative events, and difficulty setting. The nursery contributes to the steady state portion of morale, where it represents some fixed piece of the pie. The more morale buildings you've researched, the smaller the nursery represents of that piece of pie.

For details:
http://forum.outpost2.net/index.php/topic,2170.msg39086.html#msg39086 (http://forum.outpost2.net/index.php/topic,2170.msg39086.html#msg39086)

For reference, if you enable logging to MORALE.LOG you'll see something like this (early game):
13056: Events:                      3
  Overcrowding:      56        2
  Food Supply:    Srpls        2
  Dis. Bldgs:         0        2
  Rec. Center:    10000        0
  Med Center:     10000        0
  Nursery:            1        2
  University:         0        0
  GORF:               0        0
  Quake Alert:                 0
  Elect. Alert:                0
  Vortex Alert:                0
  Volcano Alert:               0
  Meteor Alert:                0
  DIRT Coverage:      0        0
  Unemployed:        18       -1
  Sci as Wkr:         0        0
      Total Cond:            7
      Potential Cond:        8
      Max Cond:            100
  Normalized Cond Effect:           87
Calculated Morale:                  82
Final, Clipped Morale:              70

Note the "Nursery" line, which has 2 points listed. This is how much it contributes to the condition morale pie. Notice the line "Potential Cond". This is the total number of condition morale points you can possibly earn, with currently completed research. With the nursery researched it's 8, and before that was researched, right at the start of "Colony, Eden Starship" it was 6. This means, early game, right after you get a nursery up and running, it can contribute 2 points out of a max total of 8 points, so 25% of your morale. As you research things like University, GORF, Medical Centers, Recreation Centers, DIRTs, and advanced disaster warning techs, the total number of possible points goes up.

Here's another excerpt from MORALE.LOG (late game):
230656: Events:                      2
  Overcrowding:      90        2
  Food Supply:    Srpls        2
  Dis. Bldgs:         0        2
  Rec. Center:       58        3
  Med Center:        70        3
  Nursery:            1        2
  University:         1        2
  GORF:               1        2
  Quake Alert:                 2
  Elect. Alert:                2
  Vortex Alert:                2
  Volcano Alert:               2
  Meteor Alert:                2
  DIRT Coverage:   2500        4
  Unemployed:         4        0
  Sci as Wkr:         0        0
      Total Cond:           32
      Potential Cond:       34
      Max Cond:            100
  Normalized Cond Effect:           94
Calculated Morale:                  79
Final, Clipped Morale:              79

Note the "Potential Cond" line has increased to 34. Now a nursery accounts for 2 points out of 34, or just under 6%. A very small piece of the pie.

Granted, there are also difficulty modifiers for morale. Note the "Calculated Morale" line, and how it differs from the "Normalized Cond Effects" line. The morale difficulty modifier tends to reduce the steady state of morale, relying more on events (including the production of consumer goods) to maintain the high levels. Effectively, this makes the nursery an even smaller percent of final morale.

With that said, I do like the idea of being able to idle a nursery, university, or GORF, without morale penalty. I think just having one should be enough in most cases, particularly the GORF. The other ones might be conditional, such as idle them without morale penalty if your population is at least 200.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on March 07, 2017, 10:44:58 AM
On other news, after going through about 5-6 written prototypes, revising features, simplifying complexity, improving depth, eliminating un-fun components, and thus, I've finally decided upon the, final, desired written prototype, to build the design document for the game. I'll look into posting a link to that in the coming weeks. And this time I intend to complete the design document.


But... uhm... remember, a design doc doesn't need to be some huge formal document. It's a guideline more than anything else unless you're in a giant corporate structure requiring every last thing be explained to the very tiniest detail.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on March 07, 2017, 01:10:47 PM
Thanks for the insight on how morale works, Hooman. I always thought that idling the nursery had a much greater impact than what is shown.

A valid point leeor_net. Though from several developer interviews of those giant corporations, they create a huge design document and then ignore it throughout most of the development process... at least that was the case with Diablo 3, Duke Nukem Forever, and Aliens: Colonial Marines... and see how well those turned out :P
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on May 21, 2017, 03:12:16 AM
Sorry for the long delay, in replying. Turns out my idea needs a few more revisions. However, I am temporarily shelving this for later. Since its been almost over 2 years since I've started this project, and haven't made anything financially viable with it, and doesn't appear I will be anytime soon, I'm putting this on the backburner to focus on a different project.

I've been working on a text-based adventure for the past couple weeks, and honestly, I'm finding it much easier to code for and the code I have made for it, does what I want it to do. I've found making the text-adventure to be much more enjoyable and fulfilling than working on this remake. Probably because when I do run into a problem I can fix it and I actually understand what I'm doing. I feel confident that I will be able to make something financially viable with my text-based adventure and thus I've been just focusing on it lately. I'd be happy to share it once I've finished implementing a few more features, and get some feedback on it from people here. It has a fully functional combat system, that I designed and coded myself, a variety of items, and game failure states already put in. I'm really enjoying making the text adventure and it is showing a lot of promise for a very interesting game.

I'd like to do something with my Outpost 2 remake, but my finances have dwindled over the past 2 years, and I really need to either get a day job or focus on producing a game in an engine that I can actually use reliably and solve problems that I have with it, in a few days, rather than with UE4 having some problems take months to figure out. I'd like to return to this later, but right now I need to focus on my finances and I honestly don't think I can have an RTS produced within a year... whereas this text-based adventure, I can easily see it being completed within a year and have something unique that other text-based adventures don't have, and thus set it apart from other titles. As I've been busy with it, I kind of forgot about OPU, and thus this is why I'm replying now to give everyone a heads up. I'm sorry if this is a bit disappointing, but I've not made any money for the past 3-4 years, as I've been focused on designing and developing games, and thus I need something to change soon, or I'll have to leave game development, completely.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: White Claw on May 21, 2017, 04:41:54 PM
No worries (at least not from me, anyway). Life is life, and taking care of yourself is certainly important. Game development is a hard industry, so good luck!
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on May 22, 2017, 05:30:34 AM
Hey lordpalandus, nice to hear from you.

Reading your concerns, I'd say take care of yourself first. Sounds like you already know what you need to do, so go ahead and go it. Guilt free.

As for making it producing games, don't feel you need to go all-in on a personal project with a make it or die trying mentality. I know there is a common mindset that you have to go all in to be successful. It turns out this is actually false. Statistically, the people who are the most successful at starting a business or completing some venture are not the ones that go all in, but rather the ones who maintain some day job to pay the bills while they work on their side project. Those who do transition to earning a living from their side project usually wait until it's already earning enough money to life off of, or even to replace their full time salary, and have reached a point where they just don't have the time to continue growing their side project and work full time. Both those conditions are important.

There are a few reasons to maintain a steady day job works better than going all in. One is the day job will force you to learn skills that may be very valuable to you in your own ventures. It's easy to push off future problems for another day, and never end up developing the skills for when you need them. The immediacy of a day job helps to combat that. Another big reason for having a day job is managing risk. If you rely on your side project for income, you won't be in a good position to take big risks with it, since failure has much bigger consequences. Having the security of a day job lets you experiment more and find out what works. It's those experiments that often lead to rapid growth and overall success.

Here's a gambling analogy. Lets say you gamble on something, winner takes all, with over 50% win ratio for you. This means the more you play, the more your should expect to win. The more you bet each round, the higher your expected earnings. Sounds good. Except for one problem. If you always bet everything, always going all in each time, your probability of going broke approaches certainty the more games you play (even with 99% win ratio). In other words, long term success doesn't generally follow a sequence of high stakes risks, even if each one is in your favour.

As for getting a day job, did you have any particular jobs in mind?
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on May 26, 2017, 03:23:43 PM
Less a day job, and more a project-focus change, Hooman. I believe I can make the text adventure marketable within 6 months tops, as I'm progressing quite rapidly at it. I have a variety of features in mind that will set it apart from the usual text-adventure or non-visual novel and thus ensure that it can be sold. There does seem to be people interested in playing text-based adventures, but the question will be whether people are willing to PAY for one. But, I'll look into that issue later; for now, just work on it and once its in a playable state, get feedback on it.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on May 26, 2017, 05:07:03 PM
There are ways to test a market before producing the product. I'd highly recommend looking into it. It's much better for you to test up front, than to potentially waste 6 months on something that nobody wants. It also lets you tweak the direction if you realize what people want is just slightly different. That takes considerably less effort the sooner in the development cycle you catch it.

One of the most common reasons for not testing the market, is not realizing you can do it before developing a product, or not knowing how to do it. It's very easy to push something off if you don't know how. It's uncomfortable. Deal with it later. Though avoiding the uncomfortable things is often setting yourself up for trouble.

Another reason for not testing the market, is people object to some of the methods presented. There are many ways to do it, so choose something that works for you. Indeed, you'll often come across some very sleazy sounding tactics, like putting up a page to sell the product, and measuring how many people buy, even though you don't yet have a product to give them. This can actually be illegal in some places, especially if you're actually collecting the money. A softer variant of that is to have a buy button, but rather than going through order completion, it informs the user the product is not ready yet, and the expected release date. Knowing how many people see the page, and how many people click the "buy" button, would then give an indication of market demand, both in terms of raw numbers, and percentage conversion rate. Though keep in mind not everyone that clicks "buy" would necessarily have completed the order even in the case where there was a product to sell. This method might still seem misleading, since you're getting users to click a "buy" button, when it's impossible to actually buy. A softer method still might be to have a "learn more" button, that gives more details of your game, and the date it's expected to be released. There are other tactics as well. Some might involve leaving an email signup for people who want to be informed when the game is released. This is likely to provide a better estimate of demand than simple page clicks to learn more, since some people like to look around with no intention to buy. It also helps filter for people who are willing to take action towards your product, which is a very good sign.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on May 27, 2017, 02:03:51 AM
... at least that was the case with Diablo 3, Duke Nukem Forever, and Aliens: Colonial Marines... and see how well those turned out :P

We don't speak of Duke Nukem Forever.


Also, you're not building a project with a multi-million dollar budget with hundreds of developers so I think it's safe to say my point stands. :D
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Sirbomber on May 27, 2017, 08:15:22 AM
Now I'll come right out and say I don't know what I'm talking about.  But, if you want to make game development your career path, perhaps it would be better for you to make something for yourself, something you and your friends would find fun, rather than something to generate income (not that it can't do that too, fingers crossed).  But you could then use that to build your resume and hopefully land a job where you can meet people you can learn from, and get some training and experience.  That might be a better launchpad for your career.  But I'm sure someone else will come along and correct me if I'm steering you in a bad direction.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on May 27, 2017, 10:54:19 AM
Yes, I think finding a suitable job is probably the best thing you can do right now. That could open a lot of doors for the future.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Vagabond on July 22, 2017, 10:58:31 PM

I'm curious to hear how the text based adventure game has been going.

Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on July 23, 2017, 04:08:15 AM
Well, I've tossed out a few prototypes already, as I found certain mechanics that I was trying to go for just didn't work at all for a text-based adventure. Mechanics such as:

- Stealth mechanics; no real sense of risk as you can take as long as you like to do any action (technically you can use timers, but without a visual element, time can be seen as unfair in a game where you can't see things that aren't described to you with text). Thus, have decided to avoid having stealth mechanics in my game.

- Announcing actions; in Dark Souls, if you observe your foes, you can learn their attack patterns and where the attack will land. I tried a system like this, in text-only format, but found that it just wasn't all that fun. The beauty of dark souls way of doing things requires a visual element to work properly. Thus aborted a prototype with it.

- Adaptative AI; I tried to implement a basic adaptive AI system, where if a player would input a series of commands, the game would learn and then take an appropriate action to counter that strategy. However, I found that this requires a fair bit more code than I believe I can possibly do, and I found it was far too easy to cheese the AI, so aborted a prototype with this system in it.

- Range / Co-Ordinates; I fiddled with the idea of trying to do multiple target battles that could take place within a room that was say 3 x 3 squares, where an enemy would have coordinates of (0,0) to (2,2), and could move 1 square per player action. However, without a way to visually represent even the most basic thing with a grid, I found it too cumbersome to use a system like this in a text-adventure.

- I also tried out several different types of basic systems, necessary for the kind of text-based adventure I'm going for; ie various ways of representing the player's inventory (without cluttering the interface), different ways of equipping AND unequipping items, different ways of handling combat encounters, and different ways of casting spells.

So... after all of that, I've now (I hope) got something I feel will be quite doable within a text-based adventure game and will likely be something I'd enjoy playing to boot. With all the prototyping I've done, I've gotten quite familiar with the engine and ways of doing simpler things much more efficiently. I've been able to figure out much more easily when its more appropriate to refactor the code and when its easier to just redesign from scratch and I'll pick the right one for the job; sometimes its better to refactor; other times when a system is so heavily embedded in the code, its better to redesign. Anyway...

The game itself will be somewhat of a hybrid between three games; Morrowind, Dungeons of the Unforgiven, and Ancients: Deathwatch; if you've never played those games, then that list may be completely useless to you. Basically, you have a variety of skills that are used by all the major actions/activities in the game, and you earn a lot of XP when you fail, and some XP when you succeed. Killing monsters provides XP for your character level, and your character level determines your maximum HP/MP; so Skills are not used for levelling the Character, but are independent. Thus, you can build your character, to suit your personal playstyle rather than being pigeon-holed into a specific class. There is a town that you can be safe in and spend your hard earned coins at various vendors. The end-goal is to defeat the boss in the deepest levels of the dungeon; the dungeon itself is broken up into sections, with an optional boss in the final floor of that section. That is a basic explanation of what I'm currently going for. When it is a bit fleshed out with content to actually play with, I'll drop a link here for you to take a look at and give me some feedback.

If you have any questions, ask away!
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on September 04, 2017, 01:12:02 AM
I've been wondering about this project lately. Have you come up with anything concrete? Do you have any source code? What language are you using?

I've been thinking more and more about an outpost 2 like game myself (either a direct clone or something new that takes gameplay inspiration from the original). Granted I've still got OutpostHD on my plate but if there was a primary developer working on such a game I'd be happy to provide assistance either in the form of code reviews, feature implementation, etc.

BTW, I wanted to thank you for sticking around so long especially through some of the adversity you've experienced in this thread. Would like to hear more from you. Hop on to IRC some time! :D
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on September 05, 2017, 12:38:14 PM
This outpost-like game is on the backburner at the moment.

I'm focused on my text-adventure which is very much operational, very-playable, fairly gameplay style balanced, and has very few bugs. Only issue is that I don't have the tutorial ready (as I know my commands and the way the game functions quite well as I've played it so much) and the in-game command list is only partially complete as I've been focused on the room-generation code as of late.

In terms of content for the text-adventure it has:
- Three distinct, and fairly balanced playstyles = pure mage, pure melee, and the stealthy assassin, which I've tested thoroughly and each are viable in both early and mid-game (unsure of endgame as I've not built it yet). The game allows you to also create your own playstyle if you don't like these, but these are the ones I've built and been able to test to ensure they are balanced (balanced in terms that each has their benefits and flaws, but each can do early game, and mid-game with approximately the same level of challenge). Any playstyle can use any item, can cast spells, and can perform any combat action, but different styles have different item requirements to make them successful. What I mean by this is that, if you want to be successful at pure mage, you won't use armor or shields, as every point of protection from them, increases your spell costs, to name one example.
- Two sections of the dungeon (each section is 3 floors) are built, with a boss fight for each section and powerful boss loot as a reward if you kill them.
- Multiple combative-ways of handling encounters... or you can decide to just flee a battle instead; if its the first round, you can flee without them noticing as well.
- I've decided upon the story, and I've decided upon how it will be portrayed to the player.
- Unique room generation, so that each room is interesting, with both fluff to build the scene and some interactables that have the possibility of loot but also the possibility of danger.
- You acquire experience to gain character levels, that only increases specific attributes (dependent on chosen race) and HP/MP. You also acquire training for attributes by succeeding at tasks, but more from failures (the idea that people learn more from a failure than a success) and once had enough training, an attribute goes up.
- You acquire soul shards to be spent at the Celestial (think of soul shards as a currency like in dark souls and the Celestial as a divine being equivalent of Vulgrum from Darksiders) Can spend soul shards on almost anything except for XP for character experience. So if the RNG hasn't favored you, you can mitigate it by purchasing things like spells or training.
- The goal of the game is to reach the bottom most floor (with a level design somewhat reminiscient of Diablo 1, with different sections underneath each other), and defeat the Chaos God. You can encounter avatars of this diety called Chaos Primals; they give great loot and great character XP, but can drain your experience points and every one killed, makes all future ones that much nastier.

This is the game in a nutshell. I'm hoping to, after I complete the room generation code for the current levels (the new room generation code is functional for LV 1 and 2, but not 3, 4, 5 or 6 yet), to complete the command list (ingame) and then post a build of the game here for people to muck around with. I'm finding playing my own game and developing it, is both quite enjoyable... well, it is when the code does what I want it to do and not skip sequential steps (grumble grumble grumble).


Adversity is understandable. Cynicism with multiple failed projects, and no game developer houses picking up the game after years and years, can definitely rub people the wrong way. And when some look promising for a time, and then the developer never shows pictures or actual code from these new projects that pop up for a time, and then the developer of it disappears from the forums permanently, can definitely make some people feel jaded to the point of... "Great, another project is here and my bet its going to be gone in 6 months time... lets not get our hopes up, like we did for the last 10 projects!"

I would like to return to my Outpost-like game in the future, but right now I am full-speed ahead on my text adventure.

Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on September 05, 2017, 02:17:54 PM
Very nice! Sounds like you got quite far with it.

Are you using source control? If so is the code publicly visible? I'd be interested to see what you've come up with.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on September 05, 2017, 03:19:55 PM
Not using source control. The code is mostly built within the interface, so unless you know the interface, it can be a bit difficult to follow/trace the variable. I know, from working with my code a lot, where variables come from, and know the calculations performed on them, so I can follow my code quite easily, but I could definitely see how it would be problematic for others to read.

The game engine I'm using is called Quest, and allows you to do it purely within the interface, use JavaScript ( I think its JavaScript at least) exclusively, or a combination of the two. However with that said, it has its annoying quirks and certain bits of code doesn't work precisely as I'd expect, having self-taught myself the basics of C++. For example, in C++, if you have two code blocks, ie an if statement and a while loop, in C++, you expect that it will finish all the code within one block first and then move onto the next block of code. In Quest, sometimes it will do so, and sometimes it will only implement half a code block, move onto the next code block, and then complete the other half of the code block of the first. This makes a lot of different things that require a sequential conditional sequence of events to go out of sequence and cause all sorts of headaches. Its a pain, but otherwise most of the time things go according to plan and I have made workarounds to this weird skipping of sequential steps... in most cases at least.

Technically you could take a look at the code by hitting code-view in the UI to see what it looks like in the code, but I don't have that stored in a SVN or other kind of source control. My code is easy for me to read, but as I've had to make a lot of workarounds to failings with the Quest Engine, it would have a lot of practices that most seasoned developers would avoid. As an example, the way custom functions are called and return with a value is very different from C++, but in-engine functions like getrandomint(1,3) [chooses a whole, integer number between 1 and 3] function much like pre-built c++ functions. Its very strange... and thus I have a huge number of nested if-else statements, switch statements, and loops, instead of custom-function calls. It really irks me, but as I require things to occur in a very specific sequence of events, the only way I've found do so within the Quest engine is to use massive numbers of nested if-elses, loops, and switches. Its very hard to do procedural abstraction or separate code into human readable chunks, in the Quest engine... which is probably why I've not seen any major game come out of it before.

So, I'm happy my game works the way it does, it just doesn't necessarily look pretty under the hood. However, as I said before, I've worked with my code a lot and know how to trace my variables so the dirtiness of the code has no impact on my ability to add/remove things, or refactor the code base... within reason of course.

Now if people are desperate to see it I can upload it in its current state and just post a list of commands here, or people can wait until I clean things up a bit (as the adding of the room generation was a major refactor and should remove the old, unnecessary code and complete the refactor before releasing a public build, yes?) and release in hopefully less than a week.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on September 06, 2017, 12:10:02 AM
Interesting project. Maybe a moderator can split this thread into a new topic.

In Quest, sometimes it will do so, and sometimes it will only implement half a code block, move onto the next code block, and then complete the other half of the code block of the first.

This might be due to the asynchronous nature of many JavaScript methods. JavaScript isn't threaded, so to avoid blocking the main thread during long running operators (like network fetches, disk reads, etc.), many methods have a completion callback. If you have an example of where this behaviour occurs, perhaps we could take a look and see why.

A related topic would be JavaScript Promises. They're fairly new to JavaScript. They have a way of allowing asynchronous code to be made to look much more synchronous. They're especially powerful when combined with Generator functions, and the new "await" keyword.

Edit: Btw, I'd like to see some more web developments skills being developed within the OPU community. Having an active JavaScript based project could be good for that, even if the project itself was not web development.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: leeor_net on September 06, 2017, 02:36:31 PM
Splitting isn't a bad idea, actually. Not sure where to make the split. Lordpalandus, this is your thread -- if you'd like a split let me know and link to the first message to split at and it will be done. :)
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on September 06, 2017, 11:44:52 PM
Splitting isn't necessary. Once I clean up the game and put in the command list, I'll create a new thread... probably in General Interest? with the link for the game download in the next thread.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on July 20, 2018, 01:55:21 PM
Long time, no posts. Regardless, I have not given up on this game idea, I've just not been ready to develop such a grand undertaking, as I lacked the skills and know how to accomplish it.

I'm not saying I currently possess the skills to do it, but I feel much more confident about doing it now that I've been developing my Roguelike for several months now and am getting used to programming in a language, debugging it, designing and implementing features, redesigning and refactoring (a skill I now appreciate a lot more having needed to use it repeatedly in the Roguelike), and playtesting the Roguelike to find ways of continually improving it.

I do not know when I'll start developing this one, but what I intend to do, is to create the design document, in stages, and post it here for people to read and comment on, if they so desire. I learned from trying to do the previous documents that trying to do it all at once in a single document was too daunting for me and thus I kept running into issues. Thus, I am going to release the DD in stages.

The running title, unless I decide to change it, is "The New Terrans". It will take a lot of inspiration from Outpost 2, but it will not be a direct 1:1 copy/remaster type of thing. The first file of the DD is the Faction Benefits Overview; the two factions are The Terraformers and The Survivalists (working names, probably rename later). I may add to the file or remove things from the files I post, as I work on the DD, but if I do modify them I'll upload new ones with a mentioning of the changes to the files. As DDs do change over time (particularly true for my Roguelike), I am willing to take feedback and tweak / completely overhaul things as suggested by the community here.

EDIT: Added a file explaining how Morale will work out.
EDIT2: Added another file with the weapon systems, that will be in the game. Not fully fleshed out yet, as I'm sure some of these will potentially annoy some of the userbase here, so wanted to get feedback on them before putting more time into them. Also, once I get more of the DD rebuilt, I'll update the first post of this thread with the new information there.
EDIT3: Added Disasters.
EDIT4: Made some changes to Morale, and added a new file called Game Concepts, which goes into detail explaining various jargon.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on July 22, 2018, 05:19:38 AM
Good to hear you're still working on stuff.

In terms of getting feedback, if you have a section that fits within a page or so, maybe consider including it quoted right in your post. That way people don't have to go through the trouble of downloading the file to give you feedback. It also sets a smaller focus on a specific area you're seeking feedback, which increases the likelihood people will respond. A small paragraph is much less daunting to read than a full document. I think that also fits in well with your plan to work on the document in pieces.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on July 22, 2018, 10:25:46 AM
Good idea. I'll look into it!
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on July 22, 2018, 01:29:03 PM
When I hear other people say they'll "look into" something, I generally assume they're not going to do it. It's usually code for "that may be a good idea, but I'm lazy, and don't want to admit it, so I'll be non-committal until other people forget about it".

I suspect you might actually be different though.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on July 22, 2018, 03:40:33 PM
Except when I'm arrogant and think it won't happen to me. ie not having a reliable Code Repository in case something bad happens. Like recent events.


Anyway, here is a new file, Combat Vehicles. I'll summarize it's contents and if you want further details you can download it and take a look at it.

Both factions have three chassi of vehicles; Light, Medium and Heavy Tank. Terraformers also have Drones and Survivalists have Arachnids (more on these later)

Each chassis, has either movement penalties or movement bonuses depending on the terrain; ie Tracked gets a speed boost on difficult terrain but a speed penalty on pavement (my replacement for bulldozing; more on that later, when I discuss civilian vehicles), whereas Wheeled is the opposite. Half-Tracked gets a smaller bonus on both difficult terrain and pavement, but gets a movement penalty on easy terrain.

Light Tanks can only use weapons that do not require Rare Metals; Medium Tanks can only use weapons that require Rare Metals; Heavy Tanks have double of any Weapon. Thus, in terms of an example from Outpost 2, the Lynx could use a Laser or Railgun, but not a Thor's Hammer, while a Panther could use a Thor's Hammer, but not a Laser or Railgun.

Each Tank also has an activatable ability, that has a benefit, a drawback, and a tactical value for using it.

Armor functions differently in this game compared to Outpost 2, functioning more like Armor in a FPS. It blocks a percentage of damage dealt to HP while it lasts. You can get field repairs of Armor, for free, as long as you have at least 1 point of armor remaining; repairing field HP damage costs resources. Once armor is gone completely you get 100% free armor by fully repairing the vehicle to full HP (ie at a Garage) or you use the Heavy Tank's ability.


Combat Bots summary:

Both factions have Bots; Terraformers have Drones and Survivalists have Arachnids.

Drones can fly and are only affected by specific weapon systems; example: Meteor Defense (both factions has one) can shoot at Drones, Missiles, and Meteors. Arachnids are generally cheaper to produce, immune to Electromagnetism (the EM in EMP), and have uniform movement speed regardless of terrain.

Drones: Field Drone, Assassin Drone, and Bomber Drone.
Arachnids: Spider, Scorpion, and Tick.

Field Drone/Spider have minor differences.

Assassin Drone can one-shot any Arachnid, but does minimal damage to all other targets. Bomber Drones can drop either an EMP bomb, Starflare explosives, or a Minefield, but must reload between bombings.

Scorpions are cheap and easily mass produced, making huge swarms of them difficult to defeat; they also have pretty good armor despite their size. Ticks are armed with a very powerful one-use Supernova explosive, able to one-shot most targets in the game. However, if they are destroyed, they spontaneously detonate their explosive package, resulting in killing anything that is too close, friend or foe, making it a bad idea to rush a group of them together, as all the other player needs to do is to kill one of them, to kill the rest.

EDIT: Modified the main post of this thread.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on July 23, 2018, 01:58:49 PM
New File: Civilian Vehicles

6 Civilian Vehicles: Robo-Earthworker, Robo-Assembler, Robo-Hauler, Robo-Constructor, Robo-Explorer, and Robo-Transport.

Robo-Earthworkers can build tubes, walls, gates, pavement, lava walls, file/create holes, and smooth/pack hills. Pavement gives a uniform movement&construction speed bonus regardless of terrain. Meteorites create holes on impact, and holes are difficult terrain. Hills are impassable and can provide walls of funnelling enemy forces.

Robo-Assemblers are one-use vehicles that deploy into a myriad of different structures, such as a Common Mine or a Laser Turret. You must have the available resources to deploy into a specific structure, otherwise it fails to occur.

Robo-Haulers are effectively OP2 Cargo Trucks.

Robo-Constructors can build structures in two ways: 1) A structure factory assembles the kit and the constructor deploys the kit. 2) They can build it without having to assemble the kit first, but it costs 33% more resources to build the structure in this fashion. They can repair structures and armor up to 100%, but cannot repair vehicles.

Robo-Explorers can survey for ore yields, can find salvageable metals for pickup, can determine the current production of an enemy structure and can steal enemy research if the lab is EMPed.

Robo-Transports are used to transport people from one Command Center to another. If there isn't a tube connection to the new base, you need to bring colonists from one base to the other. They can also be used to kidnap colonists from the other faction if the appropriate structure is EMPed. Residences give workers, Universities give Scientists and Nurseries give Children.


New File: Heavily Modified Structures:

Structures in this file are: GORF, DIRT, Meteor Defense, and Garage.

GORF = Recycles resources when colonists consume goods, recycles Scrap, and can link a Robo-Hauler to it to act as a "Garbage Truck".

DIRT = Auto-repairs structures up to a specific percentage based on current capacity; if overcapacity, it reduces the maximum healed to percentage. Restores armor up to 100% for free, but HP costs resources.

Meteor Defense = Both factions have one; used to destroy meteors and if destroyed, you don't suffer a disaster morale penalty. Takes two to destroy a large meteor, else it is converted to a small one. Bunch of other faction specific stuff with them as well.

Garage = Unlocks a "Repair" button on all vehicles that allows them to head to a Garage and repair themselves and then leave the garage. Or you can manually send vehicles to it and they will stay there. Or you can hit a "Purge" button on the garage that forces all military vehicles out, that rally near the Garage, to act as an ambush (civilian vehicles stay inside)


New file: Terrain; most of what is said is summarized elsewhere, but I have it now all in one file. Also discusses one potential way of doing terrain.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on July 24, 2018, 10:03:34 PM
Have these summaries been something of what you had in mind, Hooman, or was it something else?

Also working on a file called AI Challenges. I'm not going to bother attempting to summarize it as I ramble a bit (more like a lot) and theorize and pose potential solutions to various problems. Will upload it later.

EDIT: Uploaded the file. Please excuse the rambling. I'll have to take the time to test out various methods and find out the results before,... stuff. Anyway. My head hurts now. Or maybe don't look at the file >.>
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on July 26, 2018, 04:23:23 AM
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.

Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on July 26, 2018, 10:42:23 AM
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.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on July 27, 2018, 12:11:43 PM
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.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Vagabond on July 27, 2018, 12:44:35 PM
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.

Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on July 27, 2018, 01:07:54 PM
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.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on July 30, 2018, 12:20:12 PM
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.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on August 03, 2018, 03:39:03 PM
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?
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on August 05, 2018, 01:33:09 AM
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.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on August 05, 2018, 03:00:13 AM
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.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on August 05, 2018, 04:06:31 AM
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?
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on August 05, 2018, 12:50:08 PM
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.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on August 05, 2018, 01:22:11 PM
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.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on August 05, 2018, 05:23:36 PM
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.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Hooman on August 06, 2018, 06:00:51 AM
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.
Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on August 06, 2018, 04:30:47 PM
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.

Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: Vagabond on August 06, 2018, 11:32:18 PM

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,

Title: Re: Outpost 2-LIKE game - Community Input requested
Post by: lordpalandus on August 16, 2018, 12:31:56 PM
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.