Outpost 2-LIKE game - Community Input requested

[leeor_net]

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.

[lordpalandus]

Good point, I shall. Thanks for the input, Leeor_net

[lordpalandus]

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

[leeor_net]

Any momentum on this? Haven't seen any updates and haven't seen you online on IRC in awhile.

[lordpalandus]

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.

[lordpalandus]

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.

[dave_erald]

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.

[leeor_net]

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.

[dave_erald]

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.

[leeor_net]

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.

[lordpalandus]

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.

[leeor_net]

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.

[lordpalandus]

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?

[Hooman]

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.

[dave_erald]

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.

• Colonies use mostly robotic systems to facilitate construction and resource management.
• Each faction now has for whatever reason a grudge against the others necessitating micro colonies in the asteroid belt
• Robotic construction allows for easy micro bases to be constructed and fought from
• A colony construction pod is shot to the asteroid that houses a deployable construction yard
• A robo constructor (maybe of the multi tasking variety ie. it builds structures, mines, tubes, walls etc etc) builds a short line of tube that branching support buildings can build off of
• A robot command center auto deploys five robo constructors and these are used in building ques (a wall uses one constructor, a vehicle yard takes three etc etc)
• As the base is largely robotic, unit management for individual game size is controlled thru power regulation, a Tokomak (doesn't have to be that just using for description sake)emits enough power for five buildings and ten units, more power stations more buildings and units
• Technology is not researchable during micro missions, only at large home bases with Laboratory facilities
• All home tech currently researched is available during away missions, or only part of it depending on how you want to control that
• something

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.

David

[lordpalandus]

@Hooman;

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!

@dave_erald;
Lots of interesting stuff will have to go through it and provide some comments in a bit.

[lordpalandus]

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!

Edit:

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.

[leeor_net]

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.

[lordpalandus]

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.

[Hooman]

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.

[leeor_net]

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'.

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.

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.

[lordpalandus]

@Hooman;
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).

@Leeor;

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.

[dave_erald]

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

[lordpalandus]

Thanks Dave, I appreciate that.

[leeor_net]

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.

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 Process^TM 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.

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.

• Resource Gathering
• Unit Placement
• Unit Upgrades
• Combat Elements
• Unit Targeting
• Unit Management

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:

• You get mined resources a fixed rate.
• Research can affect the rate at which you gather resources.
• Turrets serve as towers. Turrets cost resources.
• You start with Microwave/Laser turrets.
• Turrets can be upgraded based on Research.
• Research costs resources.
• You can build robotic vehicles with weapon platforms to aid your towers.
• Robotic vehicles cost resources to build.
• Robotic vehicles can be upgraded with more effective weapons.
• Robotic vehicles can be produced at a fixed rate.
• Research can affect the rate at which robotic vehicles can be produced.
• Walls can be built to help channel incoming forces.
• Walls can be destroyed.
• Research can strengthen walls with increased hit points.

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.