Outpost 2-LIKE game - Community Input requested

[CK9]

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

[leeor_net]

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.

[lordpalandus]

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.

[leeor_net]

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.

[Hooman]

long stretches where things are on hold for a short while

I call contradiction on this.

Good to hear you're still working on the project.

[leeor_net]

I was tired when I wrote that. Sue me. lol

[Hooman]

Are you leeor_net? Yes? You have been served.

[leeor_net]

Nice. lol.

[leeor_net]

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.

[lordpalandus]

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.

Thoughts?

[leeor_net]

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.

[lordpalandus]

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. 

[lordpalandus]

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.

[Vagabond]

lordpalandus,

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!

[leeor_net]

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.

START SMALL.

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.

[Hooman]

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.

[leeor_net]

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

[lordpalandus]

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

=====

Edit:

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.

[Hooman]

You're fired. Now get in the tube. 

[lordpalandus]

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.

[Sirbomber]

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.

[Hooman]

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.

[lordpalandus]

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.

[Hooman]

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


For reference, if you enable logging to MORALE.LOG you'll see something like this (early game):

13056: Events:                      3
Conditions:
  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
Conditions:
  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.

[leeor_net]

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.

Woot!

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.