Outpost 2-LIKE game - Community Input requested

[lordpalandus]

Thanks for the insight on how morale works, Hooman. I always thought that idling the nursery had a much greater impact than what is shown.

A valid point leeor_net. Though from several developer interviews of those giant corporations, they create a huge design document and then ignore it throughout most of the development process... at least that was the case with Diablo 3, Duke Nukem Forever, and Aliens: Colonial Marines... and see how well those turned out

[lordpalandus]

Sorry for the long delay, in replying. Turns out my idea needs a few more revisions. However, I am temporarily shelving this for later. Since its been almost over 2 years since I've started this project, and haven't made anything financially viable with it, and doesn't appear I will be anytime soon, I'm putting this on the backburner to focus on a different project.

I've been working on a text-based adventure for the past couple weeks, and honestly, I'm finding it much easier to code for and the code I have made for it, does what I want it to do. I've found making the text-adventure to be much more enjoyable and fulfilling than working on this remake. Probably because when I do run into a problem I can fix it and I actually understand what I'm doing. I feel confident that I will be able to make something financially viable with my text-based adventure and thus I've been just focusing on it lately. I'd be happy to share it once I've finished implementing a few more features, and get some feedback on it from people here. It has a fully functional combat system, that I designed and coded myself, a variety of items, and game failure states already put in. I'm really enjoying making the text adventure and it is showing a lot of promise for a very interesting game.

I'd like to do something with my Outpost 2 remake, but my finances have dwindled over the past 2 years, and I really need to either get a day job or focus on producing a game in an engine that I can actually use reliably and solve problems that I have with it, in a few days, rather than with UE4 having some problems take months to figure out. I'd like to return to this later, but right now I need to focus on my finances and I honestly don't think I can have an RTS produced within a year... whereas this text-based adventure, I can easily see it being completed within a year and have something unique that other text-based adventures don't have, and thus set it apart from other titles. As I've been busy with it, I kind of forgot about OPU, and thus this is why I'm replying now to give everyone a heads up. I'm sorry if this is a bit disappointing, but I've not made any money for the past 3-4 years, as I've been focused on designing and developing games, and thus I need something to change soon, or I'll have to leave game development, completely.

[White Claw]

No worries (at least not from me, anyway). Life is life, and taking care of yourself is certainly important. Game development is a hard industry, so good luck!

[Hooman]

Hey lordpalandus, nice to hear from you.

Reading your concerns, I'd say take care of yourself first. Sounds like you already know what you need to do, so go ahead and go it. Guilt free.


As for making it producing games, don't feel you need to go all-in on a personal project with a make it or die trying mentality. I know there is a common mindset that you have to go all in to be successful. It turns out this is actually false. Statistically, the people who are the most successful at starting a business or completing some venture are not the ones that go all in, but rather the ones who maintain some day job to pay the bills while they work on their side project. Those who do transition to earning a living from their side project usually wait until it's already earning enough money to life off of, or even to replace their full time salary, and have reached a point where they just don't have the time to continue growing their side project and work full time. Both those conditions are important.

There are a few reasons to maintain a steady day job works better than going all in. One is the day job will force you to learn skills that may be very valuable to you in your own ventures. It's easy to push off future problems for another day, and never end up developing the skills for when you need them. The immediacy of a day job helps to combat that. Another big reason for having a day job is managing risk. If you rely on your side project for income, you won't be in a good position to take big risks with it, since failure has much bigger consequences. Having the security of a day job lets you experiment more and find out what works. It's those experiments that often lead to rapid growth and overall success.

Here's a gambling analogy. Lets say you gamble on something, winner takes all, with over 50% win ratio for you. This means the more you play, the more your should expect to win. The more you bet each round, the higher your expected earnings. Sounds good. Except for one problem. If you always bet everything, always going all in each time, your probability of going broke approaches certainty the more games you play (even with 99% win ratio). In other words, long term success doesn't generally follow a sequence of high stakes risks, even if each one is in your favour.


As for getting a day job, did you have any particular jobs in mind?

[lordpalandus]

Less a day job, and more a project-focus change, Hooman. I believe I can make the text adventure marketable within 6 months tops, as I'm progressing quite rapidly at it. I have a variety of features in mind that will set it apart from the usual text-adventure or non-visual novel and thus ensure that it can be sold. There does seem to be people interested in playing text-based adventures, but the question will be whether people are willing to PAY for one. But, I'll look into that issue later; for now, just work on it and once its in a playable state, get feedback on it.

[Hooman]

There are ways to test a market before producing the product. I'd highly recommend looking into it. It's much better for you to test up front, than to potentially waste 6 months on something that nobody wants. It also lets you tweak the direction if you realize what people want is just slightly different. That takes considerably less effort the sooner in the development cycle you catch it.

One of the most common reasons for not testing the market, is not realizing you can do it before developing a product, or not knowing how to do it. It's very easy to push something off if you don't know how. It's uncomfortable. Deal with it later. Though avoiding the uncomfortable things is often setting yourself up for trouble.

Another reason for not testing the market, is people object to some of the methods presented. There are many ways to do it, so choose something that works for you. Indeed, you'll often come across some very sleazy sounding tactics, like putting up a page to sell the product, and measuring how many people buy, even though you don't yet have a product to give them. This can actually be illegal in some places, especially if you're actually collecting the money. A softer variant of that is to have a buy button, but rather than going through order completion, it informs the user the product is not ready yet, and the expected release date. Knowing how many people see the page, and how many people click the "buy" button, would then give an indication of market demand, both in terms of raw numbers, and percentage conversion rate. Though keep in mind not everyone that clicks "buy" would necessarily have completed the order even in the case where there was a product to sell. This method might still seem misleading, since you're getting users to click a "buy" button, when it's impossible to actually buy. A softer method still might be to have a "learn more" button, that gives more details of your game, and the date it's expected to be released. There are other tactics as well. Some might involve leaving an email signup for people who want to be informed when the game is released. This is likely to provide a better estimate of demand than simple page clicks to learn more, since some people like to look around with no intention to buy. It also helps filter for people who are willing to take action towards your product, which is a very good sign.

[leeor_net]

... at least that was the case with Diablo 3, Duke Nukem Forever, and Aliens: Colonial Marines... and see how well those turned out

We don't speak of Duke Nukem Forever.

Ever.

Also, you're not building a project with a multi-million dollar budget with hundreds of developers so I think it's safe to say my point stands.

[Sirbomber]

Now I'll come right out and say I don't know what I'm talking about.  But, if you want to make game development your career path, perhaps it would be better for you to make something for yourself, something you and your friends would find fun, rather than something to generate income (not that it can't do that too, fingers crossed).  But you could then use that to build your resume and hopefully land a job where you can meet people you can learn from, and get some training and experience.  That might be a better launchpad for your career.  But I'm sure someone else will come along and correct me if I'm steering you in a bad direction.

[Hooman]

Yes, I think finding a suitable job is probably the best thing you can do right now. That could open a lot of doors for the future.

[Vagabond]

lordpalandus,

I'm curious to hear how the text based adventure game has been going.

-Brett

[lordpalandus]

Well, I've tossed out a few prototypes already, as I found certain mechanics that I was trying to go for just didn't work at all for a text-based adventure. Mechanics such as:

- Stealth mechanics; no real sense of risk as you can take as long as you like to do any action (technically you can use timers, but without a visual element, time can be seen as unfair in a game where you can't see things that aren't described to you with text). Thus, have decided to avoid having stealth mechanics in my game.

- Announcing actions; in Dark Souls, if you observe your foes, you can learn their attack patterns and where the attack will land. I tried a system like this, in text-only format, but found that it just wasn't all that fun. The beauty of dark souls way of doing things requires a visual element to work properly. Thus aborted a prototype with it.

- Adaptative AI; I tried to implement a basic adaptive AI system, where if a player would input a series of commands, the game would learn and then take an appropriate action to counter that strategy. However, I found that this requires a fair bit more code than I believe I can possibly do, and I found it was far too easy to cheese the AI, so aborted a prototype with this system in it.

- Range / Co-Ordinates; I fiddled with the idea of trying to do multiple target battles that could take place within a room that was say 3 x 3 squares, where an enemy would have coordinates of (0,0) to (2,2), and could move 1 square per player action. However, without a way to visually represent even the most basic thing with a grid, I found it too cumbersome to use a system like this in a text-adventure.

- I also tried out several different types of basic systems, necessary for the kind of text-based adventure I'm going for; ie various ways of representing the player's inventory (without cluttering the interface), different ways of equipping AND unequipping items, different ways of handling combat encounters, and different ways of casting spells.

So... after all of that, I've now (I hope) got something I feel will be quite doable within a text-based adventure game and will likely be something I'd enjoy playing to boot. With all the prototyping I've done, I've gotten quite familiar with the engine and ways of doing simpler things much more efficiently. I've been able to figure out much more easily when its more appropriate to refactor the code and when its easier to just redesign from scratch and I'll pick the right one for the job; sometimes its better to refactor; other times when a system is so heavily embedded in the code, its better to redesign. Anyway...

The game itself will be somewhat of a hybrid between three games; Morrowind, Dungeons of the Unforgiven, and Ancients: Deathwatch; if you've never played those games, then that list may be completely useless to you. Basically, you have a variety of skills that are used by all the major actions/activities in the game, and you earn a lot of XP when you fail, and some XP when you succeed. Killing monsters provides XP for your character level, and your character level determines your maximum HP/MP; so Skills are not used for levelling the Character, but are independent. Thus, you can build your character, to suit your personal playstyle rather than being pigeon-holed into a specific class. There is a town that you can be safe in and spend your hard earned coins at various vendors. The end-goal is to defeat the boss in the deepest levels of the dungeon; the dungeon itself is broken up into sections, with an optional boss in the final floor of that section. That is a basic explanation of what I'm currently going for. When it is a bit fleshed out with content to actually play with, I'll drop a link here for you to take a look at and give me some feedback.

If you have any questions, ask away!

[leeor_net]

I've been wondering about this project lately. Have you come up with anything concrete? Do you have any source code? What language are you using?

I've been thinking more and more about an outpost 2 like game myself (either a direct clone or something new that takes gameplay inspiration from the original). Granted I've still got OutpostHD on my plate but if there was a primary developer working on such a game I'd be happy to provide assistance either in the form of code reviews, feature implementation, etc.

BTW, I wanted to thank you for sticking around so long especially through some of the adversity you've experienced in this thread. Would like to hear more from you. Hop on to IRC some time!

[lordpalandus]

This outpost-like game is on the backburner at the moment.

I'm focused on my text-adventure which is very much operational, very-playable, fairly gameplay style balanced, and has very few bugs. Only issue is that I don't have the tutorial ready (as I know my commands and the way the game functions quite well as I've played it so much) and the in-game command list is only partially complete as I've been focused on the room-generation code as of late.

In terms of content for the text-adventure it has:
- Three distinct, and fairly balanced playstyles = pure mage, pure melee, and the stealthy assassin, which I've tested thoroughly and each are viable in both early and mid-game (unsure of endgame as I've not built it yet). The game allows you to also create your own playstyle if you don't like these, but these are the ones I've built and been able to test to ensure they are balanced (balanced in terms that each has their benefits and flaws, but each can do early game, and mid-game with approximately the same level of challenge). Any playstyle can use any item, can cast spells, and can perform any combat action, but different styles have different item requirements to make them successful. What I mean by this is that, if you want to be successful at pure mage, you won't use armor or shields, as every point of protection from them, increases your spell costs, to name one example.
- Two sections of the dungeon (each section is 3 floors) are built, with a boss fight for each section and powerful boss loot as a reward if you kill them.
- Multiple combative-ways of handling encounters... or you can decide to just flee a battle instead; if its the first round, you can flee without them noticing as well.
- I've decided upon the story, and I've decided upon how it will be portrayed to the player.
- Unique room generation, so that each room is interesting, with both fluff to build the scene and some interactables that have the possibility of loot but also the possibility of danger.
- You acquire experience to gain character levels, that only increases specific attributes (dependent on chosen race) and HP/MP. You also acquire training for attributes by succeeding at tasks, but more from failures (the idea that people learn more from a failure than a success) and once had enough training, an attribute goes up.
- You acquire soul shards to be spent at the Celestial (think of soul shards as a currency like in dark souls and the Celestial as a divine being equivalent of Vulgrum from Darksiders) Can spend soul shards on almost anything except for XP for character experience. So if the RNG hasn't favored you, you can mitigate it by purchasing things like spells or training.
- The goal of the game is to reach the bottom most floor (with a level design somewhat reminiscient of Diablo 1, with different sections underneath each other), and defeat the Chaos God. You can encounter avatars of this diety called Chaos Primals; they give great loot and great character XP, but can drain your experience points and every one killed, makes all future ones that much nastier.

This is the game in a nutshell. I'm hoping to, after I complete the room generation code for the current levels (the new room generation code is functional for LV 1 and 2, but not 3, 4, 5 or 6 yet), to complete the command list (ingame) and then post a build of the game here for people to muck around with. I'm finding playing my own game and developing it, is both quite enjoyable... well, it is when the code does what I want it to do and not skip sequential steps (grumble grumble grumble).

=====

Adversity is understandable. Cynicism with multiple failed projects, and no game developer houses picking up the game after years and years, can definitely rub people the wrong way. And when some look promising for a time, and then the developer never shows pictures or actual code from these new projects that pop up for a time, and then the developer of it disappears from the forums permanently, can definitely make some people feel jaded to the point of... "Great, another project is here and my bet its going to be gone in 6 months time... lets not get our hopes up, like we did for the last 10 projects!"

I would like to return to my Outpost-like game in the future, but right now I am full-speed ahead on my text adventure.

[leeor_net]

Very nice! Sounds like you got quite far with it.

Are you using source control? If so is the code publicly visible? I'd be interested to see what you've come up with.

[lordpalandus]

Not using source control. The code is mostly built within the interface, so unless you know the interface, it can be a bit difficult to follow/trace the variable. I know, from working with my code a lot, where variables come from, and know the calculations performed on them, so I can follow my code quite easily, but I could definitely see how it would be problematic for others to read.

The game engine I'm using is called Quest, and allows you to do it purely within the interface, use JavaScript ( I think its JavaScript at least) exclusively, or a combination of the two. However with that said, it has its annoying quirks and certain bits of code doesn't work precisely as I'd expect, having self-taught myself the basics of C++. For example, in C++, if you have two code blocks, ie an if statement and a while loop, in C++, you expect that it will finish all the code within one block first and then move onto the next block of code. In Quest, sometimes it will do so, and sometimes it will only implement half a code block, move onto the next code block, and then complete the other half of the code block of the first. This makes a lot of different things that require a sequential conditional sequence of events to go out of sequence and cause all sorts of headaches. Its a pain, but otherwise most of the time things go according to plan and I have made workarounds to this weird skipping of sequential steps... in most cases at least.

Technically you could take a look at the code by hitting code-view in the UI to see what it looks like in the code, but I don't have that stored in a SVN or other kind of source control. My code is easy for me to read, but as I've had to make a lot of workarounds to failings with the Quest Engine, it would have a lot of practices that most seasoned developers would avoid. As an example, the way custom functions are called and return with a value is very different from C++, but in-engine functions like getrandomint(1,3) [chooses a whole, integer number between 1 and 3] function much like pre-built c++ functions. Its very strange... and thus I have a huge number of nested if-else statements, switch statements, and loops, instead of custom-function calls. It really irks me, but as I require things to occur in a very specific sequence of events, the only way I've found do so within the Quest engine is to use massive numbers of nested if-elses, loops, and switches. Its very hard to do procedural abstraction or separate code into human readable chunks, in the Quest engine... which is probably why I've not seen any major game come out of it before.

So, I'm happy my game works the way it does, it just doesn't necessarily look pretty under the hood. However, as I said before, I've worked with my code a lot and know how to trace my variables so the dirtiness of the code has no impact on my ability to add/remove things, or refactor the code base... within reason of course.

Now if people are desperate to see it I can upload it in its current state and just post a list of commands here, or people can wait until I clean things up a bit (as the adding of the room generation was a major refactor and should remove the old, unnecessary code and complete the refactor before releasing a public build, yes?) and release in hopefully less than a week.

[Hooman]

Interesting project. Maybe a moderator can split this thread into a new topic.

In Quest, sometimes it will do so, and sometimes it will only implement half a code block, move onto the next code block, and then complete the other half of the code block of the first.

This might be due to the asynchronous nature of many JavaScript methods. JavaScript isn't threaded, so to avoid blocking the main thread during long running operators (like network fetches, disk reads, etc.), many methods have a completion callback. If you have an example of where this behaviour occurs, perhaps we could take a look and see why.

A related topic would be JavaScript Promises. They're fairly new to JavaScript. They have a way of allowing asynchronous code to be made to look much more synchronous. They're especially powerful when combined with Generator functions, and the new "await" keyword.


Edit: Btw, I'd like to see some more web developments skills being developed within the OPU community. Having an active JavaScript based project could be good for that, even if the project itself was not web development.

[leeor_net]

Splitting isn't a bad idea, actually. Not sure where to make the split. Lordpalandus, this is your thread -- if you'd like a split let me know and link to the first message to split at and it will be done.

[lordpalandus]

Splitting isn't necessary. Once I clean up the game and put in the command list, I'll create a new thread... probably in General Interest? with the link for the game download in the next thread.

[lordpalandus]

Long time, no posts. Regardless, I have not given up on this game idea, I've just not been ready to develop such a grand undertaking, as I lacked the skills and know how to accomplish it.

I'm not saying I currently possess the skills to do it, but I feel much more confident about doing it now that I've been developing my Roguelike for several months now and am getting used to programming in a language, debugging it, designing and implementing features, redesigning and refactoring (a skill I now appreciate a lot more having needed to use it repeatedly in the Roguelike), and playtesting the Roguelike to find ways of continually improving it.

I do not know when I'll start developing this one, but what I intend to do, is to create the design document, in stages, and post it here for people to read and comment on, if they so desire. I learned from trying to do the previous documents that trying to do it all at once in a single document was too daunting for me and thus I kept running into issues. Thus, I am going to release the DD in stages.

The running title, unless I decide to change it, is "The New Terrans". It will take a lot of inspiration from Outpost 2, but it will not be a direct 1:1 copy/remaster type of thing. The first file of the DD is the Faction Benefits Overview; the two factions are The Terraformers and The Survivalists (working names, probably rename later). I may add to the file or remove things from the files I post, as I work on the DD, but if I do modify them I'll upload new ones with a mentioning of the changes to the files. As DDs do change over time (particularly true for my Roguelike), I am willing to take feedback and tweak / completely overhaul things as suggested by the community here.

EDIT: Added a file explaining how Morale will work out.
EDIT2: Added another file with the weapon systems, that will be in the game. Not fully fleshed out yet, as I'm sure some of these will potentially annoy some of the userbase here, so wanted to get feedback on them before putting more time into them. Also, once I get more of the DD rebuilt, I'll update the first post of this thread with the new information there.
EDIT3: Added Disasters.
EDIT4: Made some changes to Morale, and added a new file called Game Concepts, which goes into detail explaining various jargon.

[Hooman]

Good to hear you're still working on stuff.

In terms of getting feedback, if you have a section that fits within a page or so, maybe consider including it quoted right in your post. That way people don't have to go through the trouble of downloading the file to give you feedback. It also sets a smaller focus on a specific area you're seeking feedback, which increases the likelihood people will respond. A small paragraph is much less daunting to read than a full document. I think that also fits in well with your plan to work on the document in pieces.

[lordpalandus]

Good idea. I'll look into it!

[Hooman]

When I hear other people say they'll "look into" something, I generally assume they're not going to do it. It's usually code for "that may be a good idea, but I'm lazy, and don't want to admit it, so I'll be non-committal until other people forget about it".

I suspect you might actually be different though.

[lordpalandus]

Except when I'm arrogant and think it won't happen to me. ie not having a reliable Code Repository in case something bad happens. Like recent events.

---

Anyway, here is a new file, Combat Vehicles. I'll summarize it's contents and if you want further details you can download it and take a look at it.

Both factions have three chassi of vehicles; Light, Medium and Heavy Tank. Terraformers also have Drones and Survivalists have Arachnids (more on these later)

Each chassis, has either movement penalties or movement bonuses depending on the terrain; ie Tracked gets a speed boost on difficult terrain but a speed penalty on pavement (my replacement for bulldozing; more on that later, when I discuss civilian vehicles), whereas Wheeled is the opposite. Half-Tracked gets a smaller bonus on both difficult terrain and pavement, but gets a movement penalty on easy terrain.

Light Tanks can only use weapons that do not require Rare Metals; Medium Tanks can only use weapons that require Rare Metals; Heavy Tanks have double of any Weapon. Thus, in terms of an example from Outpost 2, the Lynx could use a Laser or Railgun, but not a Thor's Hammer, while a Panther could use a Thor's Hammer, but not a Laser or Railgun.

Each Tank also has an activatable ability, that has a benefit, a drawback, and a tactical value for using it.

Armor functions differently in this game compared to Outpost 2, functioning more like Armor in a FPS. It blocks a percentage of damage dealt to HP while it lasts. You can get field repairs of Armor, for free, as long as you have at least 1 point of armor remaining; repairing field HP damage costs resources. Once armor is gone completely you get 100% free armor by fully repairing the vehicle to full HP (ie at a Garage) or you use the Heavy Tank's ability.

---

Combat Bots summary:

Both factions have Bots; Terraformers have Drones and Survivalists have Arachnids.

Drones can fly and are only affected by specific weapon systems; example: Meteor Defense (both factions has one) can shoot at Drones, Missiles, and Meteors. Arachnids are generally cheaper to produce, immune to Electromagnetism (the EM in EMP), and have uniform movement speed regardless of terrain.

Drones: Field Drone, Assassin Drone, and Bomber Drone.
Arachnids: Spider, Scorpion, and Tick.

Field Drone/Spider have minor differences.

Assassin Drone can one-shot any Arachnid, but does minimal damage to all other targets. Bomber Drones can drop either an EMP bomb, Starflare explosives, or a Minefield, but must reload between bombings.

Scorpions are cheap and easily mass produced, making huge swarms of them difficult to defeat; they also have pretty good armor despite their size. Ticks are armed with a very powerful one-use Supernova explosive, able to one-shot most targets in the game. However, if they are destroyed, they spontaneously detonate their explosive package, resulting in killing anything that is too close, friend or foe, making it a bad idea to rush a group of them together, as all the other player needs to do is to kill one of them, to kill the rest.

EDIT: Modified the main post of this thread.

[lordpalandus]

New File: Civilian Vehicles
Summary:

6 Civilian Vehicles: Robo-Earthworker, Robo-Assembler, Robo-Hauler, Robo-Constructor, Robo-Explorer, and Robo-Transport.

Robo-Earthworkers can build tubes, walls, gates, pavement, lava walls, file/create holes, and smooth/pack hills. Pavement gives a uniform movement&construction speed bonus regardless of terrain. Meteorites create holes on impact, and holes are difficult terrain. Hills are impassable and can provide walls of funnelling enemy forces.

Robo-Assemblers are one-use vehicles that deploy into a myriad of different structures, such as a Common Mine or a Laser Turret. You must have the available resources to deploy into a specific structure, otherwise it fails to occur.

Robo-Haulers are effectively OP2 Cargo Trucks.

Robo-Constructors can build structures in two ways: 1) A structure factory assembles the kit and the constructor deploys the kit. 2) They can build it without having to assemble the kit first, but it costs 33% more resources to build the structure in this fashion. They can repair structures and armor up to 100%, but cannot repair vehicles.

Robo-Explorers can survey for ore yields, can find salvageable metals for pickup, can determine the current production of an enemy structure and can steal enemy research if the lab is EMPed.

Robo-Transports are used to transport people from one Command Center to another. If there isn't a tube connection to the new base, you need to bring colonists from one base to the other. They can also be used to kidnap colonists from the other faction if the appropriate structure is EMPed. Residences give workers, Universities give Scientists and Nurseries give Children.

---

New File: Heavily Modified Structures:

Structures in this file are: GORF, DIRT, Meteor Defense, and Garage.

GORF = Recycles resources when colonists consume goods, recycles Scrap, and can link a Robo-Hauler to it to act as a "Garbage Truck".

DIRT = Auto-repairs structures up to a specific percentage based on current capacity; if overcapacity, it reduces the maximum healed to percentage. Restores armor up to 100% for free, but HP costs resources.

Meteor Defense = Both factions have one; used to destroy meteors and if destroyed, you don't suffer a disaster morale penalty. Takes two to destroy a large meteor, else it is converted to a small one. Bunch of other faction specific stuff with them as well.

Garage = Unlocks a "Repair" button on all vehicles that allows them to head to a Garage and repair themselves and then leave the garage. Or you can manually send vehicles to it and they will stay there. Or you can hit a "Purge" button on the garage that forces all military vehicles out, that rally near the Garage, to act as an ambush (civilian vehicles stay inside)

---

New file: Terrain; most of what is said is summarized elsewhere, but I have it now all in one file. Also discusses one potential way of doing terrain.

[lordpalandus]

Have these summaries been something of what you had in mind, Hooman, or was it something else?

Also working on a file called AI Challenges. I'm not going to bother attempting to summarize it as I ramble a bit (more like a lot) and theorize and pose potential solutions to various problems. Will upload it later.

EDIT: Uploaded the file. Please excuse the rambling. I'll have to take the time to test out various methods and find out the results before,... stuff. Anyway. My head hurts now. Or maybe don't look at the file >.>