Outpost 2-LIKE game - Community Input requested

[Hooman]

Perhaps off topic rants need to be taken elsewhere. I decided to start a couple of extra threads:
Division Is Slow
A Note On Floating Point

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?

[lordpalandus]

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.

[Sirbomber]

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?

[lordpalandus]

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.

[Hooman]

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.

[lordpalandus]

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.

[Hooman]

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?

 

[lordpalandus]

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.

[Leviathan]

Hi

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?

[lordpalandus]

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.

[leeor_net]

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.

[Sirbomber]

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.

[Arklon]

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.

[leeor_net]

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.

[lordpalandus]

@leeor_net;
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.

@Sirbomber;

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.

@Arklon;

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

@Leeor_net;

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.

[leeor_net]

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.

[lordpalandus]

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.

[Highlander]

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.

[lordpalandus]

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?

[Arklon]

@Arklon;

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.

[leeor_net]

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.

[lordpalandus]

@Arklon;

Ahhh, thanks for the clarification.

@leeor_net;

Comments:
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.

[leeor_net]

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.


EDIT

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.

[Sirbomber]

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?

[lordpalandus]

@leeor_net;

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.