Outpost Universe Forums

Projects & Development => Outpost 2 Programming & Development => Tutorials => Topic started by: Sirbomber on March 24, 2011, 07:44:09 AM

Title: Outpost 2 Coding 202: Part 0
Post by: Sirbomber on March 24, 2011, 07:44:09 AM
Alright, I guess I should finally get around to doing this.  So, unlike the first set of tutorials, where I just wrote them in advance and said "now you try" we're going to try and work on a project as a group and get it to a state that could reasonably be described as "done" or at least "done enough".

...So, what do people want to work on?  It should be something useful, new, and reasonably challenging to work on.  For example, a new campaign would be cool, and it would require some fairly intelligent AI, but the AI may end up being the only challenging part, with the rest being fairly tedious mapping and unit placement.  On the other end of the spectrum, an AI that could take the place of a human opponent would be an amazing achievement, but do we really think we could get that done?

Anyways, anyone who is interested should say something along the lines of "I'm in" and also post a project suggestion.
Title: Outpost 2 Coding 202: Part 0
Post by: Lord Of Pain on March 24, 2011, 08:26:03 AM
If It's somthing hard your looking for, I can brainstorm plenty of chalanging things.


I was thinking of making a campaign for outcasters. We would also need an experianced hacker in order to implant the oucaster symbol into the side screen under the minimap panel buttons. I have an image rough draft. It Litterally looks like a yellow letter 'Q' .. Now as for how Eddy B got this done I don't really know, and yes i would like a new loading screen. If this sounds too dificult for us, we could just leave it to the original op2 game client.

Is that challenging enough?

Also, I was thinking of making a new tileset (i actually have some started) I call it ICEwell pallete (not related to Iceworld or green world). Although at first i wasn't sure if Iceworld was ready enough to be playable on, so i went ahead and started moding the original tileset in op2. I used the program 'GIMP' to tint the color of the already existing tileset.. This was however not very effective enough to be considered anywhere close to eye candy. But i also have some original tiles (not many but some) which can be used.

What we could also do is alter the looks of a few structures to look like its an original colony (race) on op2. If we do this however, we would have no choice but to make a seporate game client liek eddy-b did for renegades so it does not mess up existing plymouth units in the game.

I already have an agridome im working on, it's way more than half done. The only way it's veiwable in game is as a tileset (no function) other than that it's pretty close to finished.

Also i was thinking of a metalic terrain (which i have made) though never released. Im still working on it.

Here is a list of objective tiles we could use in the metal tileset:

-Metalic concrete surface - (Tile/Fast/made by robodozer) Will have the same affect on moving units as bulldozed terrain, just instead it's metalic pavement.

-Cargo crates - (Tile/Prop/impassible) For Scenery and evidence that colonist are unpacking or packing to evacuate. Should appear closed and full with no indication of contents.

-Metal Canister - (Tile/Prop/Impassible) It would also be scenery, perhaps holds water thawded away from the ice on the moon which the story takes place. It should appear ful lof water if made possible.

-A new ore smelter, with three pipes going into the ground.

***Have to cut off here, next class, I will be back to edit more content shortly***
Title: Outpost 2 Coding 202: Part 0
Post by: Sirbomber on March 24, 2011, 08:47:26 AM
We're not going to work on your own personal project for you.
Also, this is Outpost 2 Coding, not graphics hacking.
Title: Outpost 2 Coding 202: Part 0
Post by: Spikerocks101 on March 24, 2011, 10:11:46 AM
I will love to learn some new stuff, but as for any ideas, I'm blank. In lines with a new campaign, how about a Multiplayer-Campaign (like Survivor, but a series of levels... for the hell of it). I always hated Survivor, but it clearly seems to be the most popular for casual players.
Title: Outpost 2 Coding 202: Part 0
Post by: Lord Of Pain on March 24, 2011, 10:13:04 AM
Quote
It should be something useful, new, and reasonably challenging to work on.
Sorry about that, i thought you meant it could be anything which included what you said.

Although it was under those guide lines.

So what is aloud to be suggested in coding 202?
Title: Outpost 2 Coding 202: Part 0
Post by: Sirbomber on March 24, 2011, 11:27:58 AM
You can suggest whatever you want.  Doesn't mean I have to run with it.

I'd recommend that any suggestions should require a fair amount of coding.  Campaigns, mods/add-ons, etc.  I think hacking the EXE would be a bit too much at this point, but if that's what people want, okay.

I won't accept suggestions that rely too heavily on mapping, art, etc, since that's not really the point.  That doesn't mean we can't make new maps for whatever we end up making, of course...

Also: Great idea, Spike.
Title: Outpost 2 Coding 202: Part 0
Post by: TH300 on March 27, 2011, 06:10:30 AM
I'd love to make a general ai. Thats the thing that I'm currently most interested in. A campaign would also be interesting (be it singleplayer or multi), but I have the feeling that it would mean more work than a general ai and give us less. A general ai can make every existing map more enjoyable. A campaign is just 12 missions (if it comes to that) which are enjoyable. For the ai, we could build on those initial thoughts (http://forum.outpost2.net/index.php?showtopic=5127).

Moreover, I am more an algorithm developer. I don't have as much fun when doing a special ai. So, if we make a campaign, I may end up making the maps.

I'm seeing some suggestions here, that require hacking of the exe. Although that can be done, you never know if you can hack it enough to make your idea work. But that information is needed before I'll contribute anything.
Title: Outpost 2 Coding 202: Part 0
Post by: Spikerocks101 on March 27, 2011, 06:34:20 AM
Well, Bomber, since you suggested this idea of a project, you can very well choose. It seems unlikely that more ideas will come, so I wouldn't wait to much longer to start getting things organized for any of these ideas.
Title: Outpost 2 Coding 202: Part 0
Post by: Sirbomber on March 27, 2011, 07:25:48 AM
It's only been a few days, let's see if anything else turns up.
Title: Outpost 2 Coding 202: Part 0
Post by: CK9 on March 27, 2011, 10:19:35 AM
AI is the main thing people have been wanting forever.  Everyone's talked about how nice it would be, but nothing's been done towards it.  So, let's go all in and work on an ai.
Title: Outpost 2 Coding 202: Part 0
Post by: jcj94 on March 27, 2011, 07:28:05 PM
I'd love to help.  I've done only a few missions, and I'm working on sketching a couple of map idea out for a couple of 2 team multiplayer games.  If you guys can come up with something idea for me for maps, I'd help sketch a basic layout.

So I guess its time to say... All in favor say Aye!

Aye!

And, as for my idea:

    Maybe some new unit types.  Maybe a third colony.  (hint)

    I have never made a new unit type, and would like to learn how, if there is a way to do that.
Title: Outpost 2 Coding 202: Part 0
Post by: TH300 on March 28, 2011, 03:22:28 AM
Quote
I have never made a new unit type, and would like to learn how, if there is a way to do that.
No one has ever made a new unit type (unless you count the double turret gp as one, but that is taking only existing stuff and combining it new). Hence no one knows how to make new units. It may even be impossible or require recoding of half of the game.
Title: Outpost 2 Coding 202: Part 0
Post by: Sirbomber on March 28, 2011, 05:12:42 AM
BB did it once, just as a proof of concept.  I don't think it's really all that feasible though.
Title: Outpost 2 Coding 202: Part 0
Post by: Hooman on March 28, 2011, 09:30:04 PM
There is enough reliance on virtual functions that I believe you could implement a unit with completely new behavior without massive reprogramming. It would still be a lot of work though.

There is also the question of actually creating the new unit in game. Starting a level with pre-created custom units might be easier than allowing them to be built in game. Many checks are done based on ranges of unit type id values corresponding to generic things like vehicles or buildings or weapons. If you wanted to add a new unit without replacing an old one, you might run into difficulty due to the static sizing. You could perhaps fake it by reusing the same id for a new unit, but then that creates ambiguity if you want to produce the unit at a factory.

A possible solution might be to build it using a new id, but then switch the id after creating to match something in the appropriate range.


I do remember BlackBox did something interesting, and I think it might have involved some trickery with unit type ids, but I could be mistaken. It's been a while and I don't think I ever really knew that many details to begin with.
 
Title: Outpost 2 Coding 202: Part 0
Post by: Spikerocks101 on March 28, 2011, 09:34:54 PM
Thou, just saying, I know nothing about how to go about adding a unit to the game, so I would be little to no help in that aspect. Also, what would we add? I think the game needs more sheet vol editing, adjusting values of things, then new units. To be honest, I don't even use all the units in the game properly, and am not really for having even more units. Thou, if possibilities are possible, adding a feature to the game would be nice. Like, for example, a way to trade techs with each other, or even a bug fix on that blasted Sticky Foam tech (which, btw, should be, for now, taken out of the game due to uselessness).
Title: Outpost 2 Coding 202: Part 0
Post by: TH300 on March 28, 2011, 09:58:38 PM
Quote
Thou, just saying, I know nothing about how to go about adding a unit to the game, so I would be little to no help in that aspect.
I guess, thats more or less true for most of us and probably all people who are going to participate. The people who know how to do it, didn't offer their help and if they don't change their mind, we simply cannot do it.
Title: Outpost 2 Coding 202: Part 0
Post by: jcj94 on March 29, 2011, 06:50:11 AM
That isn't a good thing.

And Spike, what stickyfoam glitch?  They seem perfectly fine to me.

I'll have to go and look at some ancient threads about the things you guys mentioned.  I want to see if there is a way to do something like building off the Double GP.

 
Title: Outpost 2 Coding 202: Part 0
Post by: Sirbomber on March 29, 2011, 06:59:24 AM
It's probably gonna be that multiplayer co-op campaign or the AI thing.  People should choose which they'd rather do and then we'll start by the end of this week (if all goes well).
Title: Outpost 2 Coding 202: Part 0
Post by: Lord Of Pain on March 29, 2011, 10:28:34 AM
well easiest (and obvious) way of putting it is to make a poll to decide what we want... i will make just that.

EDIT: sorry spike, i was too fast, it already made.
Title: Outpost 2 Coding 202: Part 0
Post by: Spikerocks101 on March 29, 2011, 10:30:02 AM
Err, we dont need a poll, since its more of "whose going to help gets to choice" kinda thing. The general public really doesn't get any say in this, imo.
Title: Outpost 2 Coding 202: Part 0
Post by: Sirbomber on March 31, 2011, 09:46:51 PM
Alright, everyone is willing and able to work on this, post below.  Include your current (estimated) skill level, noteworthy stuff you've produced/worked on/whatever, estimated time you can devote to this project, pace you'd like to work at, and whether you'd rather work on the AI or the campaign.

Example:

Tankn0[size=0] [/size]0b
SKIL LEFIL: BLARY[size=0] [/size]EUGH
AKOMPLSIHMINTZ: KONKIRD TE[size=0] [/size]H ME[size=0] [/size]S HA[size=0] [/size]L
AFAYLIBEL: WIN NOT MAYKN SOLGRS GETT ON DER NEES.  ALZO, MOZT OF JUUN ND JOOL I
DZIRD PAYZ: 1 NU TOPIK EFREE WEKK
WUUD RATHR WERK ON: U[size=0] [/size]R DU T HAZ ALWAZ BEN 2 DY SOL[size=0] [/size]GR
Title: Outpost 2 Coding 202: Part 0
Post by: Spikerocks101 on March 31, 2011, 11:20:15 PM
Yeah... thats why Tank should stay in the mess hall >_>

anyways
Skills: Decent at C++, know most of the STD lib, knows about AI making and game design (decent programmer, to say the least)
Accomplishments: Err, no real finished projects, but have made so demos of things
Time available: Alot. On the IRC nearly 24/7 :P
Time frame: Don't care. It's just a learning experience with me
Project: Don't care, but since I know we will get more support if we work on a general AI (TH300 and _A_ both seem to be willing to assist in such a thing), I'll go with that :P
Title: Outpost 2 Coding 202: Part 0
Post by: TH300 on April 01, 2011, 01:57:14 AM
Skill Level: pretty good C++, some education in computer science, including software engineering.
Stuff that I made: the screenshot utility (which is an op2 exe mod), the "Guards" map (basic multiplayer map). A few programs in C++ that I never released to the public.
Time that I'll have for this: Until ~August an estimated avarage of 4 hours per weak. From mid August on probably 2-3 hours per day.
Pace: slowly
Project: General AI
Title: Outpost 2 Coding 202: Part 0
Post by: jcj94 on April 01, 2011, 10:10:37 AM
Skills: Halfdecent/decent C++ and knowledge of techtree for weapons/ morale techs
Accomplishments:  La Corrida Tigers map, not entirely done, but useable enough.
Availability: Starting June 5: whenever I can get on a computer, so pretty much all dah time
Time Frame:  WHEN IT GETS DONE!
Project:  General AI
Title: Outpost 2 Coding 202: Part 0
Post by: BlackBox on April 03, 2011, 01:43:28 AM
I wouldn't be opposed to helping with a general purpose AI at some point. That being said there are other, loftier goals that would be kind of cool to see implemented (e.g. rewriting the game, though that's probably a bit out of the scope of a project like this).

As far as the unit hacking is concerned, since I know everyone has been interested in new units for a while, (the "proof of concept" Sirbomber mentioned) first off it did not create a new map_id, I just reused one that is completely unusable (0x4b, the "BFG" unit I believe). My unit was basically derived from the EMP missile with a different payload (it created an atheist building explosion instead of the EMP blast. Initially the project started out as an experiment in replacing vtable entries in the EMP missile and I then wondered about making another missile so both EMP missiles and my "nuclear missile" could be built, as opposed to modifying the behavior of the EMP missile).

The biggest hurdles were having to fully define a unit (i.e. figure out all the entries in the vtable as well as the struct size and fields), a large part was already figured out but obviously to make my own from scratch I had to write a lot of particularly uninteresting code (like some factory functions to create the unit given some information about its position on the map).

After this was done I was able to create the spaceport with the missile on its launch pad. However it still didn't work totally properly:

The main issues with creating units are, like Hooman said, there are all kinds of hardcoded checks for the map_id of a particular unit when deciding what to do. For my missile to work at least partially I recall having to patch at least 10 places, probably more, where there were checks for the type of object on the launch pad (for example whether it should be allowed to load cargo, whether it can launch without a cargo, whether to show the targeting cursor, etc).

So yes, making new units is possible but for them to actually be properly creatable and functional for players a whole bunch of other code has to be touched.
Title: Outpost 2 Coding 202: Part 0
Post by: Sirbomber on April 03, 2011, 08:43:30 AM
Haha, maybe Coding 303 will be a rewrite/sequel. :P

Anyways, looks like people wanna do the AI.  I'm a little concerned that this may be a bit out of reach, but hey, gotta try, right?

What do people think about this tentative schedule:Feel free to comment/complain/nitpick (in Hooman's case) as needed.
Title: Outpost 2 Coding 202: Part 0
Post by: CK9 on April 03, 2011, 09:51:31 AM
Quote
...We'll test this on standard maps, but if people can make some custom ones with some really difficult features, that would be helpful....
Look no further than here!  Remember the one map I had started working on that was just too big to work?  Two of the the corners had semi-mazes made of cliffs that could be used to test the pathfinding.  All I'd need to do is copy them to a smaller size and fill in the gaps.

No matter which project is chosen, make sure to make a tentitive scheduel.  Without a deadline, most people have a tendancy to put things off indefinately.
Title: Outpost 2 Coding 202: Part 0
Post by: Sirbomber on April 03, 2011, 10:21:41 AM
Fair enough.  Okay, we're going to start with Map Analysis on Wednesday.  I'll kick off the discussion by posting what kind of information I think the AI will need, and then the rest of you will join in on the discussion with your own thoughts.  Part of the discussion should probably be about ways we can divide the work among ourselves.  After two days, we'll figure out who's doing what and get to work (try to be reasonable here and don't bite off more than you can chew).  I'd like to be done with that in about a week, so let's give ourselves until the 13th.  We can then take another week, if needed, to fix any lingering problems and make a few improvements, but I really would like to move on by the 20th.

In summary:
Start date: 4/6/11
Discussion ends by: 4/7/11
Tasks assigned by: 4/8/11 (begin work here)
Goal date: 4/13/11
Deadline: 4/20/11
Title: Outpost 2 Coding 202: Part 0
Post by: TH300 on April 03, 2011, 12:17:29 PM
I think, that plan is too ambitious.

And your schedule looks somewhat reasonable, but could be improved:And lets follow a design pattern like the Waterfall model (http://en.wikipedia.org/wiki/Waterfall_model). Its not the best pattern, but it is simple and will give us better results than using no pattern at all.

Right now we didn't even agree on requirements that the ai shall fulfill. So, lets start with those: The bare minimum would be to have a LoS ai that is capable of winning on any map against any player. I'd personally aim towards a LR ai, because it wouldn't add much additional code and would ensure a useable code structure (whereas, if we start with a LoS ai, it could turn out, that turning it into a LR ai would require serious rewrites). Furthermore, it is probably wise to be aware of the additional goals, that you listed, during the design process.

I'll add my thoughts on decision making later.
Title: Outpost 2 Coding 202: Part 0
Post by: Sirbomber on April 03, 2011, 01:51:45 PM
Quote
The bare minimum [requirement] would be to have a LoS ai that is capable of winning on any map against any player.
Wait, you mean the AI is supposed to try and win?  I thought it was supposed to waste all of its ore on SULVs and Solar Satellites and then cause that weird acid trip bug from Swarm. :rolleyes:
 
Anyways, that big list I posted was actually intended to be the requirements the AI will need to function well (notice that one of them is in fact win the game).  I mean, that's why I spent an hour and a half writing it out.  Though yeah, research could be moved into decision making (what I called situation response; couldn't remember the phrase I was looking for when I wrote the list).  That's just how I do it (since the techs I get and the order I get them in are pretty much set in stone) but we probably don't want the AI behaving that way.

And yeah, I know we're being too ambitious, and I know the schedule is tight.  But I don't want this to stagnate, and we can always push deadlines back as needed.

As for "working on LR first", I don't think that would be best, and I don't see it requiring any significant rewrites if we start on LoS.  We could just have some way of detecting game mode or starting units and assign it a few extra LR-specific goals at the start of the match (specifically, find good ore and build the base before the BM, if any [which raises the question of how we'll assign AM/BM to the AI, but we'll tackle that when the time comes]).  Anyways, if you could list some of the concerns you have more specifically, that would help.



Last thing, and I mean this in the best possible way: if you're going to work on this I need you to remove the stick fr stop taking everything anybody says 100% literally.  When I say "If we need power build a Tokamak" I don't mean "STOP EVERYTHING YOU'RE DOING AND BUILD THAT TOKAMAK RIGHT NOW!!!!!!!" so much as "that's just one more thing the AI needs to consider doing to achieve its goal".
Title: Outpost 2 Coding 202: Part 0
Post by: evecolonycamander on April 03, 2011, 02:36:22 PM
so basically the whole concept of this AI is to actually have it almost function as a human player and not a dynamix AI. one that functions well enough to be a 'cut & paste' project allowing us n00bs to effectively make the crappiest map and having it be almost instantly playable with the bare minim of edits(x,y cords, Plymouth vs Eden start units, ect.).

am i off here as to the ultimate goal?
Title: Outpost 2 Coding 202: Part 0
Post by: jcj94 on April 03, 2011, 02:42:47 PM
*Slaps ECC*

.. Did you not read the
WIN
under the AI list?

IMA FIRING A mediocre employee.
Title: Outpost 2 Coding 202: Part 0
Post by: Sirbomber on April 03, 2011, 04:36:49 PM
No.  At the bare minimum, all the mission designer would have to do would be to include a library and call some kind of "InitAsAI" function.  The AI will be able to take care of itself from there.  If we're going to do this, let's do it right.

That said, in a perfect world, this thing would work so well that we could hack an "Add AI Player" button into the multiplayer setup dialog and play a few rounds with it.  But who knows if we'll actually get to that stage.
Title: Outpost 2 Coding 202: Part 0
Post by: Spikerocks101 on April 03, 2011, 05:16:49 PM
Should we get our own forum for this? Also, are we going to have regular times we meet on the IRC to discuss such things? I don't know much about project design, so I'm just fallowing.
Title: Outpost 2 Coding 202: Part 0
Post by: jcj94 on April 03, 2011, 05:23:36 PM
What do you mean our own forum?
I can see our own main topic (like the Outpost 2 Coding), but a whole new forum?

I'll be available to work over spring vacation next week.

 
Title: Outpost 2 Coding 202: Part 0
Post by: Sirbomber on April 03, 2011, 06:46:07 PM
He means a sub-forum dedicated to the Coding tutorials, kinda like how we have the AI Programming sub-forum inside the Programming sub-forum.  And that's really not up to me.

Anyways, arranging meeting times on IRC for the entire group will be impossible.  We'll keep discussion in the topic for the most part, unless you're working in pairs or something.
Title: Outpost 2 Coding 202: Part 0
Post by: jcj94 on April 03, 2011, 06:58:22 PM
Quote
unless you're working in pairs or something.
That will probrably happen a lot.

I work with ECC and TH300 on the IRC a bunch, so I can just talk to them for guidance/ info/ YOUR DOING THAT WRONG YOU'LL BREAK THE GAME!! stuff.
Title: Outpost 2 Coding 202: Part 0
Post by: CK9 on April 03, 2011, 11:45:18 PM
Quote
He means a sub-forum dedicated to the Coding tutorials, kinda like how we have the AI Programming sub-forum inside the Programming sub-forum.  And that's really not up to me.
 
Nor me (despite my promotion, lol)

Wouldn't this fit within the AI Programming sub-forum anyway?
Title: Outpost 2 Coding 202: Part 0
Post by: Sirbomber on April 04, 2011, 06:36:18 AM
Well, it's a tutorial first and a project second, so not really?  Besides, if we were to get our own sub-forum, we'd probably want the 101 stuff thrown in there as well (and locked, at this point).
Title: Outpost 2 Coding 202: Part 0
Post by: CK9 on April 04, 2011, 09:11:51 AM
K, I'll talk to hacker about it (I think he's more likely to respond in the mod/admin section)
Title: Outpost 2 Coding 202: Part 0
Post by: jcj94 on April 04, 2011, 10:35:24 AM
Quote
Shameless self-promotion!!!!
Could you shamelessly sef promote Op2?

Anyway, I agree with bomber on the new sub-forum.  About moving the coding tutorials would be fine, but make one that people (like subbed and ECC and I) can post our maps to that WON'T be used for discussion, for as we go through the tutorial.


Can't wait to get this GAI Started!
 
Title: Outpost 2 Coding 202: Part 0
Post by: Arklon on April 04, 2011, 11:28:04 AM
Quote
About moving the coding tutorials would be fine, but make one that people (like subbed and ECC and I) can post our maps to that WON'T be used for discussion, for as we go through the tutorial.
No, nobody is going to go out of their way to do something just for you just because you're unwilling to figure out your own way to organize your progress and so you demand that others do so for you.
Title: Outpost 2 Coding 202: Part 0
Post by: TH300 on April 04, 2011, 02:46:15 PM
Quote
As for "working on LR first", I don't think that would be best, and I don't see it requiring any significant rewrites if we start on LoS.  We could just have some way of detecting game mode or starting units and assign it a few extra LR-specific goals at the start of the match (specifically, find good ore and build the base before the BM, if any [which raises the question of how we'll assign AM/BM to the AI, but we'll tackle that when the time comes]).  Anyways, if you could list some of the concerns you have more specifically, that would help.
The best way of implementing LR would be to give the ai the ability to build up everything from a few vehicles. Even a mere LoS ai will need that ability, since it is possible that its base is destroyed or it has to relocate. So, technically, if we create a good LoS ai, we'll automatically get a LR ai. I just find it more organized to start it as LR ai. Even if we don't want this functionality, the ai must be able to build up new bases, so we'll have to write code that finds a base location and thats the hardest part of making the ai LR capable.

Quote
Last thing, and I mean this in the best possible way: if you're going to work on this I need you to remove the stick fr stop taking everything anybody says 100% literally.  When I say "If we need power build a Tokamak" I don't mean "STOP EVERYTHING YOU'RE DOING AND BUILD THAT TOKAMAK RIGHT NOW!!!!!!!"
Didn't understand it that way. Besides that I have to say, that
1. I have no way of knowing what to take literally and what not and
2. we have to write everything up clearly as soon as possible. Otherwise we won't be able to collaborate.

Thats why I repeated the obvious requirements. It has to be clear. So, again:
- able to win LoS/LR against any player
- plays with the same rules as human players
- can be integrated into any mission
- It is probably a good idea to make a list of situations that the ai shall be able to handle
- EXTRA: expand the multiplayer protocol to allow adding of ai players to existing maps

Did I forget anything?

To help us get started, I wrote up some thoughts. The first part is about ai quality. Although some of it may appear obvious, I want to be sure that everyone knows what to consider. So, I'll post it anyway. The second part is a suggestion for decision making.

Quote
Introduction
============

This document is a (more or less) random collection of thoughts. Its aim is to discuss how to judge an ai's quality and how an ai should work (in my opnion) to make it high quality. Although this may require talking about technical details of decision processes, that's not the primary concern of this document.
Note that it is assumed that the ai plays fair, i.e. it plays under the same conditions as a humand player, with the same amounts of resources, the same resource demands and the same knowledge.


Part 1: judging an ai's quality
===============================

Criteria
--------

The first that comes to mind is the ai's overall strengh, its ability to win games against experienced players. This should describe itself. Since an ai shall be a challange for strong and for weak human players, it should be at least as strong as the strongest player with the option of weakening it if desired. It is assumed that there are enough ways for weakening and it is thus a good idea to begin with creating an ai as strong as possible.

Another thing to look at is predictability. Outpost2's default ai's (if you dare to call them "ai") are pretty predictable which allows human players to exploit known weaknesses and thus makes the ai weaker alltogether. But a preditable ai is also less fun to play against, because it will always, in each game make the same decisions and the player will eventually get bored. Hence an unpredictable ai should be preferred over a predictable one. It is worth considering, though, that even human players are sometimes predictable if they make optimal decisions and the opponent is smart enough to anticipate those decisions. Here we have a little conflict with the goal of making an ai as strong as possible and it seems to be the best compromise that an ai should be unpredictable only to the point where more random behaviour would make it considerably weaker.

What does this mean?
--------------------

It is obvious that a human player fits into that pattern and hence an ai should be like a good human player. It should be capable of making plans, reacting to enemy actions, deciding who to attack, etc. It should be capable of finding a good base location in land rush games, building its base in such a way that an exploding advanced lab won't defeat it, doing research in an order that helps accomplish its goals, building extra ore- or military bases, micromanaging combat vecs and much more.


Part 2: How to achieve good quality
===================================

People may argue that they know better or that the great game "xy" does it the way "yz" and hence "yz" is the best way of doing it or scientists have found the best solution already. So let me tell you that these are just ideas which are open for improvement. Of course you'll have to explain why your solution is better.

The resource based approach
---------------------------

This is merely a scheme for organizing decisions. It is independent of how decisions are finally made. So, how does it work? As a human player I don't go, see that I want to achieve X, which requires me to achieve Y, for which I need Z and so on. That approach requires much thinking, because I have to resolve all dependencies the whole way to where I currently stand. For an ai this would mean much computing, less speed and much complication.

As a human player I see that I have an unused cargo truck and a smelter+mine where it could be used. No thinking required to figure out where the truck will go. When I have spare common metals and my armies are currently strong enough to keep up with all my enemies, I spend metals on expansion, because expansion ensures winning. Expansion is everything that increases ore production or population growth. Even if I don't have enough workers/Scientists to operate the new buildings, its good to have them before the colonists are available (just imagine how something could blow up one of your smelters and you have another one already built). Also, if I have spare workers and an ore production higher than what I need, I may idle a smelter and activate a consumer goods factory. When I have spare scientists I assign them to research. I know which research topic will boost which goal. Not much thinking required. When I have a convec with an Agridome and food stores are diminishing, I build the Agridome next to an operational building. If I have a convoy that is capable of building a base and building a base is judged as appropriate, I build a base at the best location that I can find.


Making decisions
----------------

This part is the most complicated one and it has so many possible solutions that I'm still unsure, whats the best.

I recently read about "Hierarchical AI". It is a way for both, collecting information of whats going on and making decisions. It works much like the military in the real world. Since I don't want to write more than neccessary, I am just poiting to http://www-cs-students.stanford.edu/~amitp...rarchalAI.html# (http://www-cs-students.stanford.edu/~amitp/Articles/HierarchalAI.html#).
A possible hierarchy for Outpost2 could be at the top the "ai commander" with the goal to win the game (or whatever we want it to do), below the (mostly independent) bases, below the armies that belong to the bases. Of course there will also be armies that don't belong to bases and there will be exchange of resources between bases. For some structures it matters where they are built (e.g. DIRTS, smelters), for some it doesn't (nursery, agridomes). I am not yet sure, which instance should decide about the operation of which structure type.


Particular decisions
--------------------

We'll need code that makes the following decisions:
- Finding a base location
- finding build-locations for single structures
- (micro-)managing armies
- building defence lines
- chosing research topic
- idling buildings / distributing colonists
- metal usage
The list is probably incomplete and we should complete it before starting coding. Note that the list has to fit to the "resource based approach", unless we want to do something different.
Title: Outpost 2 Coding 202: Part 0
Post by: Sirbomber on April 05, 2011, 03:19:08 PM
You say that you don't think "I need X to do Y to do Z" and that's true, most human players probably don't think that way (not consciously, anyways).  Unfortunately, most of your ideas operate under the assumption that the AI works like a human.  It's great that you and I can see an empty Cargo Truck and have it start mining, and you have no idea how much of a luxury it is to just be able to think "build this new Agridome next to another building with a tube connection".  But have you actually given any thought as to how the AI is going to figure out, "I have an idle truck and a mine and smelter to stick it on" or "the Agridome can go here and be connected to the tube network"?

Finding trucks (not actually code):
Code: [Select]
// Iterate through all AI Cargo Trucks
while (more trucks to look through)
{
    // Check status
    if (truck isn't in use)
    {
        // Now iterate through all mines
        while (more mines to look through)
        {
            if (Common Ore Mine)
            {
                // Iterate through all the Smelters "attached" to this mine
                while (more smelters to look through)
                {
                    if (Smelter has less than 2 trucks on it)
                    {
                        assign truck to this mine and smelter
                        record truck so we can restart it if it gets EMP'd
                        update Smelter/Mine truck count
                    }

                    if none found, do nothing?
                }

            }

            if (Rare Ore Mine or Magma Well)
            (repeat Common Ore Mine/Smelter code)

       } // done looking through mines

    } // if truck isn't in use

    if truck is in use, do nothing

} // end search

Code: [Select]
// Search for new building site connected to tube network
// Iterate through ALL buildings
while (still more buildings)
{
    // Check if they have a tube connection
    if (curBuilding.HasTubeConnection() )
    {
        // Check if there's room for this building
        // Low priority: Make sure the buildings are aligned and look pretty.
        if (space for this building)
        {
           Add building to build queue and assign a priority
           Reserve this location so that other buildings won't take its space
        }

    } // if tube connection found

} // done looking through buildings

bool HasTubeConnection()
{
    // Apparently it's unlikely we can make an ASM hack to do this, so...

    // Check around the building for tubes
    Get building's x/y dimensions and origin in terms of the top left corner

    // Use that data to check every tile around the building ("footprint" tiles)
    for each footprint tile
    {
        if (tube)
        {
              // Check NESW for more tubes until we hit a building.
              // If that building is a Command Center, return true.
              // Otherwise, continue checking for more tubes/buildings

        } // if tube found

    } // while still checking footprint tiles

    // If we get here, we couldn't find a tube connection
    return false;

} // end tube connection checker.  This reeks of recursion, so there's probably a better way, but I'm not good enough at this to think of it.

I appreciate your effort, but you're only concerned with the end result; what the player will fight against.  This is useless right now.  Before we can even think about that, the AI will need to understand the rules of the game and be able to play by them.  There will come a time for that document you're writing.  But that time is not now.
Title: Outpost 2 Coding 202: Part 0
Post by: Hidiot on April 05, 2011, 03:47:48 PM
I'm pretty sure we'll want to AI to be modular.

So for instance: first we want to make it know how to build a structure, then we want it to know how to place the kit, and then we want it to know how to build a base (place a kit relative to its other buildings)
Title: Outpost 2 Coding 202: Part 0
Post by: Sirbomber on April 05, 2011, 07:11:52 PM
Maybe we're using different definitions of the word, but what does that example have to do with modularity?  Do you mean we should be able to easily change the rules it uses for (using your example) building placement?
Title: Outpost 2 Coding 202: Part 0
Post by: TH300 on April 06, 2011, 12:54:14 PM
Quote
I appreciate your effort, but you're only concerned with the end result; what the player will fight against.  This is useless right now.  Before we can even think about that, the AI will need to understand the rules of the game and be able to play by them.  There will come a time for that document you're writing.  But that time is not now.
You are right: The AI needs to be able to play by the rules of the game. The "Particular decisions" section of my document was meant to tackle this. But I think that we should have the structure of the whole, before we start coding one part. I mean, if we want to do this thing hierarchic, we'll likely want code that does search for a building location in a given base. We need classes that represent a base (and other instances in the hierarchy). Everything has to interface with those classes.

My plan is to do a class diagram of everything before we do any coding other than prototyping. We don't have to, but if we don't, we may have to redesign the whole thing a few times.
Title: Outpost 2 Coding 202: Part 0
Post by: Sirbomber on April 06, 2011, 01:09:27 PM
Quote
I mean, if we want to do this thing hierarchic
You're the only one who's even mentioned that "AI Commander" thing.  I've glanced through the document.  Just looking at the "topmost-level" of decision making, the thing would have to be self-aware (and I for one will not be responsible for the robot apocalypse).  Also, the author hasn't even attempted to implement that.  It's all theory.  And we're just a team of amateurs doing this for learning and for fun.  Not going to happen.

The real problem here, TH300, is that you want this to be your project.  You're trying to get us to do things the way you want them done.  This is a tutorial first, and a project second.  We need to work on things in small, manageable chunks, starting off easy and working our way up to the big stuff.  Yes, this approach means we're going to have to deal with all kinds of problems later on.  There'll be a lot of extra work tying it all together and fixing the bugs that will inevitably arise when we do that.  But I'm not going to apologize for that.  If you can't handle working as a part of this team, then I think you need to step aside and let us get work done.

Part 1 will be posted within the hour (probably going to need an extra 30 minutes or so since I had to write this out).  I hope to see you there.
Title: Outpost 2 Coding 202: Part 0
Post by: Arklon on April 06, 2011, 01:17:20 PM
Quote
I mean, if we want to do this thing hierarchic
Reading that Hierarchal AI article, what it proposes seems incoherent, particularly the part about the "AI commander" making abstract, strategic decisions. It proposes very little in the way of HOW the AI will "look ahead", process "what-if" scenarios, etc., and it seems to me that in order for it to do that you'd be looking at something that'd be more along the lines of true AI, which would be unfeasibly complex for this project.

Quote
we'll likely want code that does search for a building location in a given base. We need classes that represent a base (and other instances in the hierarchy). Everything has to interface with those classes.
And how is it going to know what "a base" is, how is it going to know how, when, and where to make new "bases", etc.? It seems to me that you're thinking about this from a "it'd be totally cool if the AI did this!" perspective and not from a realistic, programming perspective.
Title: Outpost 2 Coding 202: Part 0
Post by: TH300 on April 06, 2011, 01:55:39 PM
Quote
Quote
I mean, if we want to do this thing hierarchic
You're the only one who's even mentioned that "AI Commander" thing.  I've glanced through the document.  Just looking at the "topmost-level" of decision making, the thing would have to be self-aware (and I for one will not be responsible for the robot apocalypse).  Also, the author hasn't even attempted to implement that.  It's all theory.  And we're just a team of amateurs doing this for learning and for fun.  Not going to happen.
Yes, its all theory. But all theory is any other approach that you present to me, even if it has been done already, unless you give me the source code of an existing implementation its all theory for me.

Quote
The real problem here, TH300, is that you want this to be your project.  You're trying to get us to do things the way you want them done.
As long as my ideas make sense, I see no problem with that. If my ideas don't make sense, I expect you to give better arguments than "its all theory". I have made programs from "its all theory".

Quote
This is a tutorial first, and a project second.  We need to work on things in small, manageable chunks, starting off easy and working our way up to the big stuff.  Yes, this approach means we're going to have to deal with all kinds of problems later on.  There'll be a lot of extra work tying it all together and fixing the bugs that will inevitably arise when we do that.  But I'm not going to apologize for that.
This may work, but it doesn't motivate me. I have written so many unmaintainable programs, because I didn't design them properly. I don't want to produce another piece of s***. If we do this how you want, we'll end up doing it once, producing something that we won't want to continue working on and then starting new, using the experience from the first try. That will repeat until we decide to design the thing properly before we start coding. ("will" means here that I see a chance of this happening of above 90%)

Quote
If you can't handle working as a part of this team, then I think you need to step aside and let us get work done.
Wait, if I debate your suggestions I cannot work in a team, even though you are the one who wants to end the debate?

Tbh. I had seen that coming: several people have several ideas of how to do it. I do currently not feel like pushing my ideas through. But this means, that if you want to do things that look too stupid to me, I'll loose motivation and help less. Don't worry, this point is still a bit away. Regardless of this, I enjoy programming more if I am working on a new, interesting algorithm that no one implemented before. Give me the chance to make algorithms, otherwise I won't be motivated and hence be less productive. And thats not any decision that I make, its my nature.


Reply to Arklon's post:

Quote
Quote
I mean, if we want to do this thing hierarchic
Reading that Hierarchal AI article, what it proposes seems incoherent, particularly the part about the "AI commander" making abstract, strategic decisions. It proposes very little in the way of HOW the AI will "look ahead", process "what-if" scenarios, etc., and it seems to me that in order for it to do that you'd be looking at something that'd be more along the lines of true AI, which would be unfeasibly complex for this project.
Strategic decisions could be
- army A is facing enemy army B and is inferior. Hence it needs to be reinforced. Thats not at all difficult: there will be data structures that represent single armies (of the ai; for human controlled armies, we'd have to create some heuristic to figure out which tanks belong to an army - something that we'll need anyway)
- in base C the only structure factory got destroyed. Produce a new one a the base with most available capacities and send it to base C.
- the enemy is advancing quickly in military research, we shouldn't fall behind and thus we focus on military research.
- food stores are diminishing, thus we build an agridome in any of our bases.
I cannot thing of any example that we couldn't implement. And we don't have to do the "look ahead" and "what if" parts. I agree that those are a bit out of range. I merely want the hierarchic structure.

Quote
Quote
we'll likely want code that does search for a building location in a given base. We need classes that represent a base (and other instances in the hierarchy). Everything has to interface with those classes.
And how is it going to know what "a base" is, how is it going to know how, when, and where to make new "bases", etc.?
- What a base is? - the ai simply keeps track of which buildings belong to which base when building them. If two bases are close together they may be treated as one base. The point is that each base will need certain structures to defend itself. If the next vehicle factory is miles away it won't help much if a base is under attack.
- When to make new bases? - when more resources are needed or when it makes sense to defend a bottleneck in the middle of the map or when more space is needed....
- Where to build new bases? - depends on what the base is for. A mining base will be built where good beacons are found, a strategic base will be built where the position is easily defendable. That may be hard to figure out, but we'll need that anyway.

Quote
It seems to me that you're thinking about this from a "it'd be totally cool if the AI did this!" perspective and not from a realistic, programming perspective.
I believe that it can be programmed, because its after all just a system of entities (which are represented by classes)

We can make programs which model parts of the real world. Object oriented programming gives us that. One condition is, of course, that the model doesn't contain too many details. But this is given, because Outpost 2 itself doesn't contain too many details.
Title: Outpost 2 Coding 202: Part 0
Post by: Sirbomber on April 06, 2011, 02:26:40 PM
-- hotlink removed due to suspicious domain --
http://lolpics.se/pics/482.jpg

Thanks Arklon.
Title: Outpost 2 Coding 202: Part 0
Post by: TH300 on April 06, 2011, 02:32:35 PM
Alright. Its your choice: Either behave like grown ups or do it without me. I am willing to take any reasonable argument against what I say. But I am not going to take offenses and silly posts like this one.

I am editing this post, because you asked to stop making new ones: if you claim that my responses are not intelligent, I take that as an offense. Stop it.
Title: Outpost 2 Coding 202: Part 0
Post by: Sirbomber on April 06, 2011, 02:42:05 PM
Your argument was basically "you can't prove that it won't work, therefore it will work."  You want an intelligent response, give me one.

Also, Arklon would like you to not use a word in its own definition:
Quote
- What a base is? - the ai simply keeps track of which buildings belong to which base when building them. If two bases are close together they may be treated as one base. The point is that each base will need certain structures to defend itself. If the next vehicle factory is miles away it won't help much if a base is under attack.
All your base are belong to us.


Anyways, I'm off to post part 1.  EVERYONE stop posting here so the new stuff doesn't get buried under this.
Title: Outpost 2 Coding 202: Part 0
Post by: jcj94 on April 06, 2011, 03:24:01 PM
I just want so say "I worked on something FREAKING AMAZING!"  I really don't mind who the credit goes to (but most SHOULD go to Sirbomber for starting the project and kicking our asses in gear).
Title: Outpost 2 Coding 202: Part 0
Post by: Sirbomber on April 06, 2011, 07:36:56 PM
This isn't about "credit" or "glory" or anything.  It's about getting crap done.