Open Outpost

[croxis]

After finally wrestling the network code into working status (no wonder whyt he library is called Twisted...) I am happy to finally announce Open Outpost.

Feel free to post bugs in this thread or on the sites bug tracker.

Notes:
* Gliese is the only star system with planets.
* I'm working on the UI code to give it the classic outpost look
* Colony reports are currently being piped to the command prompt window.  This will obviously change as soon as I get the UI system going.
* Windows users must extract the two files in the patch to C:\Windows\System32.  If it asks to overwrite, say no.


Downloads:
None atm while updated code is being merged in

Open Outpost is being written in Python and uses the Panda3D engine as the 3D back-end (Python-Ogre refuses to compile on my system).  Currently it is using an orthographic camera to render it as isometric, using either the legacy assets or origional textures.  Eventually the game will move to fully 3D content, but right now I'd rather spend the time making a game than a bunch of otherwise useless models.  

The goal is to recreate the intended feature set of the game (although probably not behavior) yet update to more modern gameplay conventions.  Release 1.0 will be equivalent to the Outpost 1.0 featureset.  Release 2.0 will be equivalent to Outpost 1.5, with addition of multiplayer. 3.0 will try to make the game that was promised to us on the box, in the manual, and in beta previews.  Then who knows from there.

Here is the awesome part.  This is open source.  Code is already in the repository.  If you want to program a feature I might not get to for a while, go ahead.  If you think you can do something better? By all means!  And most importantly, if I stop working on it or vanish from the face of the Earth, all the work will still be there.

Right now there isn't much.  The basic client/server communication is in place. There is a turn counter (woohoo), a library to clip textures from the origional graphics, and a random map generator which needs to be reconfigured to make alien planets.  

This is also cross platform, it currently works under linux and windows, and mac support will be available with the next version of Panda3D.

Quick and dirty FAQ:

"Outpost sucks, why arnt you doing Outpost 2?"
City builders are my second favorite genera (after space combat/economic games).  I'm going to make what I enjoy playing the most.  I have no specific issue adding combat and moving away from the tile system, in fact that is the plan. Just not now.  As for realtime, see multiplayer below.

"Outpost takes a long time, wouldn't multiplayer be boring?"
Mind you multiplayer is very far away right now.
Yes it does, thats why it will be modeled after Civilization 4's Pitboss server.  The server admin sets a maximum turn time limit (say 6 hours, or 24 hours).  The next turn happens when everyone has clicked on end turn, or the server time limit expires.  Then the timer starts over and waits until everyone is ready for the next turn or the timer expires.
The network library I am using is very versatile in the communication it can do.  In theory the serve rcan send everyone a next turn email providing a detailed status report, contact them on an instant messenger client, or bridge ingame chat with an IRC bot.

"Why a 3d engine? Why python?"
Even using orthographic projection a 3D engine has native z-buffer support, in addition of allowing the use of other affects such as particle emitters and lighting effects.  And why python? because I already know Python and it is a language known for fast development time.  It has great integration with C libraries, so if there is parts of the code that is slow, it can be rewritten in c or c++ and integrated with the rest of the python code.

"So is this a remake? A clone?"
It is going to be Outpost-like.  It wont be the same exact game (and really, do you want it to be?)

Feel free to post suggestions, rants, ideas here or on the project site bugs/blueprints.

[Sirbomber]

I have no specific issue adding combat and moving away from the tile system, in fact that is the plan.

No.  Either remake Outpost 2, or remake Outpost 1(.5).  Don't make some new frankensteinian combination of the two.  Combat has no place in Outpost 1 (other than Mass Driver abuse).

[croxis]

Combat would have no resemblance to Outpost 2, and probably wouldn't resemble anything like an RTS or TBS.  I put it 4th to last on a list of over 40 general features for a reason -- it is going to be highly dependent on how everything else pans out. It will probably be abstracted out so the player wont be moving units around like Civ or SMAC.  Considering the game is suppose to be a colony simulator in a harsh environment any armed conflict should be highly expensive: whatever form it ends up coming in (if at all) it would only be a viable option if the other guy(s) are going to seriously screw you over, or if they have something you really really REALLY want.

I'd much rather discuss on improving the existing Outpost features that are much closer to implementation.

edit: But seeing as players can found colonies on other planets in the system, I don't see why mass drivers can't be used for interplanetary bombardment.

[WooJoo]

so how do i grab it?

[Spikerocks101]

I'm with woojoo, i didn't read any thing you typed, i just want to play (put this in the readme if you want people to read it )

[croxis]

I'll put together a windows binary of the prototype tomorrow.  Sadly there isn't much to "play" yet.

[WooJoo]

Oh i just want the source or something i can compile  -_- <<<< linux

[croxis]

Oh good.  This is easy (for me).

Linux Install Instructions

• Install the Panda 3D package for your distribution (or get the source and compile yoruself if youa re one of THOSE people   ).
• Install Bazaar
• Pull the code from the repo with the command: bzr branch lp:openoutpost
• You will need a copy of original Outpost.  In the Assets folder of OO make a new folder called Legacy.
• From the origional Outpost copy the BITMAPS folder into Assets/Legacy (so Assets/Legacy/BITMAPS/bunchof.BMP)
• Fire up two terminals.
• in the OO directory run: python server.py
• In the other terminal run: python Outpost.py

Let me know of faulty instructions or nasty bugs

[WooJoo]

im not sure if im doing it wrong or its maybe not set to be fetchable vio bzr but
by using bzr i only get a msg that the connection didnt work -_-

can you dump a trunk copy?? ^^

[croxis]

Launchpad uses bazaar exclusively so I'm not sure what the problem may be.  you could try bzr branch lp:openoutpost/trunk. Regardless, the code is now on the download page on the project site (you will still need to install Panda3D on your own, for now anyways).

Just read up on the documentation for Bazaar. the command bzr status will print out all the plugins installed.  If launchpad isn't listed that is probably why the bzr checkout isn't working.

[croxis]

Took a week off from development to job hunt (failure on that account. sigh).

Minor update.  Building graphics are now put in when a building is built (the whole building timer isn't in place, I got some backwork stuff to do for that and clean up the network protocol a little bit).



As you can see there are still some issues to be resolved.  I can't seem to get the camera/mesh angles right.  If anyone knows the formula for the camera angle relationship to the perceived angles of the files, I will love you for a long long time.

The next big hurdle is building connection check. I've been trying to look into some theory behind it, but without knowing the right vocabulary I can't ask the right questions.  The only solution I can think of without running into infinite loops or other bugs is a simple A* pathfinding for the buildings, where anybuilding/tube is passable "terrain" and unbuilt tiles are impassable.  The building then tries to find a path to the command center and if successful gets added to the colony's connected building list.  The check would only be done on the building built and on any buildings of a level when a building is demolished/destroyed.  But this method just seems to be computationally expensive compared to any better alternatives there might be out there.  Any suggestions?
 

[Sirbomber]

1) Rather than use OP1's ugly graphics, why not use new ones?

2) In the original OP1, buildings could only be connected to the colony by tubes and not by other buildings (unless you were the AI).

[Hooman]

Well, you are basically looking for something like a path finding algorithm. In the case of adding 1 new building, A* sounds like a reasonable choice, but perhaps not the best way. However, when recomputing connectivity information for a large number of buildings, there are certainly better choices. When a building is destroyed, or perhaps loading a saved game, or scenario with pre-existing buildings, you probably want something more global in scope.

With A*, you're computing a shortest path between two points. What you actually want, is just plain connectivity (yes/no), and don't really care if it's the shortest path. You might also want to be able to do this for a bunch of buildings at once.

Consider the global case first. Say a game was loaded, or a scenario with existing buildings was needs to be initialized. What you can do is start at the Command Center, and expand out from there activating things along the way. The most natural way to think of this conceptually is with a Breadth First Search (BFS). Starting off, the command center is active. You check for neighbors of the active nodes (neighbors of the command center), and mark them as active too. Then you repeat with this new set of active nodes.

BFS
Or rather, to state this in a way with a nod toward efficiency, you proceed by processing one of the remaining exterior nodes. The command center will be an interior node once you've checked for all it's neighbors, and each neighbor you found will be a new exterior node. You don't need to process the command center again once you've marked it as interior (that is, once you've processed it's surrounding neighbors). You then check the list of exterior nodes that have recently been marked as active, remove one from that list, and try to find it's neighbors to be marked as active and placed on the exterior node list. (Make sure they aren't already marked as active, so you don't get stuck in an infinite loop adding the same nodes over and over again until you run out of memory). As you process each node, you move it from the exterior list to the interior list, and the algorithm terminates when there are no more exterior nodes to process. (You initialize the algorithm by placing the command center, or rather, all command centers, on the exterior list, and marking them as active). For this algorithm, you'd probably want to use a linked list to maintain the exterior list. The active flag can be placed in the unit data, and should be initialized to false before starting the algorithm. A next link could also be placed in the unit records for the linked list of exterior nodes, but usually this is maintained externally.

Of course, it need not be a breadth first search. I just figure that's the easiest way to think of it conceptually. You might also use a depth first search. This uses recursion and the stack instead of a linked list. Rather than expanding out in circles about the active points, you could expand out in lines as far as they'll go, and then backtrack looking for branch points. This is more like tree traversal. Depending on the structure of the graph, there will be different memory requirement tradeoffs between the two algorithms. If the graph has a high branching factor, but low depth along each branch, then the DFS will probably use less memory. If the graph has long paths with little branching, than the BFS might use less memory.

DFS
Initialize all nodes to inactive. For each command center, do the following. Mark the node as active, and for each neighbor, which isn't already active, recursively mark it as active and check all it's neighbors.


Now, that covers initialization, or reinitialization when a building is destroyed. How about when a new building is built?

In the same case, you build a unit, and check if any neighbors are active, and if so, the new building is active. If not, well, nothing left to do. This works fine as is for leaf buildings at the fringe of a colony, but what about a new connecting building that is reattaching a branch to the main colony trunk. In that case, you'll also have to activate any non-active buildings that it connects to. This can be done by using one of the above two algorithms, without first initializing all nodes as inactive, and starting with the new building as the starting point.


Pseudo-code:
(Assumes a few global arrays/objects exist, and ignores Sirbomber's comment about only activating with tubes)

Code: [Select]

void MarkAllInactive()
{
  int i;
  for (i = 0; i < numBuildings; i++)
  {
    building[i].active = false;
  }
}

struct Point
{
  int x;
  int y;

  Point(int x, int y)  // Constructor
  {
    this->x = x;
    this->y = y;
  };
  Point operator + (Point &other)  // + operator
  {
    return Point(x + other.x, y + other.y)
  };
};
Point direction[] = {
  { 0, -1 }, // Top
  {-1,  0 }, // Left
  { 1, 0 }, // Right
  { 0, 1 }, // Bottom
  // ... keep adding more if all 8 surrounding tiles are adjacent
};
const unsigned int NumDirections = sizeof(direction)/sizeof(*direction);

void ActivateBFS(int startBuildingIndex)
{
  int i;
  LinkedList<int> exteriorNodes;

  exteriorNodes.Add(startBuildingIndex);
  building[startBuildingIndex].active = true;

  while (exteriorNodes.numNodes > 0)
  {
    currentBuildingIndex = exteriorNodes.RemoveHead();

    for (i  = 0; i < NumDirections; i++)
    {
      neighborBuildingIndex = map.Tile(building[startBuildingIndex].location + direction[i]).buildingIndex
    // Make sure the index is valid here, perhaps by checking...
    if (neighborBuildingIndex != -1)  // Obviously -1 isn't a valid index
    {
      // Make sure the building hasn't already been marked as active
      if (!building[neighborBuildingIndex].active)
      {
        building[neighborBuildingIndex].active = true;
        exteriorNodes.Add(neighborBuildingIndex)
      }
    }
   }
  }
}

void ActivateDFS(int startBuildingIndex)
{
  int i;

  building[startBuildingIndex].active = true;
  
  for (i = 0; i < NumDirections; i++)
  {
    // Assuming the map hold an array of building indexes, for simplicity
    neighborBuildingIndex = map.Tile(building[startBuildingIndex].location + direction[i]).buildingIndex
    // Make sure the index is valid here, perhaps by checking...
    if (neighborBuildingIndex != -1)  // Obviously -1 isn't a valid index
    {
      // Make sure the building hasn't already been marked as active
      if (!building[neighborBuildingIndex].active)
      {
        ActiveDFS(neighborBuildingIndex)
      }
    }
  }
}

// Call on load, or when a building is destroyed (BFS version)
void InitializeActiveBFS()
{
  int i;

  MarkAllInactive();

  for (i = 0; i < numBuildings; i++)
  {
    if (building[i].type == CommandCenter)
    {
      ActivateBFS(i);
      // Optionally, instead of the above call, we could "push" the CC onto the exterior list (mark as active and add), and use the loop from ActivateBFS
    }
  }
}

// Call on load, or when a building is destroyed (DFS version)
void InitializeActiveDFS()
{
  int i;

  MarkAllInactive();

  for (i = 0; i < numBuildings; i++)
  {
    if (building[i].type == CommandCenter)
    {
      ActivateDFS(i);
    }
  }
}

void ActivateNewBuilding(int buildingIndex)
{
  int i;

  // Check for active neighbor
  for (i = 0; i < NumDirections; i++)
  {
    neighborBuildingIndex = map.Tile(building[startBuildingIndex].location + direction[i]).buildingIndex
    if (neighborBuildingIndex != -1)
    {
      if (building[neighborBuildingIndex].active)
      {
        // This building, and all connections are active
        ActivateBFS/DFS(buildingIndex);
        return;  // No need to keep checking
      }
    }
  }
}

[croxis]

1) Me making new graphics = me spending less time making the new graphics actually *do* something.  New graphics will need to be made for distribution though.  And I actually think the graphics were quite good for the time.

2) I remember reading that there was also had a hard codeed 4 tube iteration limit.  The problem is I don't know how it was iterated. The problem I am worried about is if a connection is destroyed.  Here is ascii art. (B is building, C command center, everything else is tube)

Code: [Select]

B--B--(rest of colony)
|   |
B--C--(rest of colony)

Now say you get hit with a mass driver and you lost some buildings

Code: [Select]

B  B--(rest of colony)
|   |
B  C--(rest of colony)

I'm not sure an effective way to check the two buildings on the left getting disconnected from the command center and the rest of the colony.

My other problem, at least for being tile based like this, is I can't find any gameplay justification for having tubes.

[Hooman]

That's why...

// Call on load, or when a building is destroyed (BFS version)
void InitializeActiveBFS()
{
 int i;

 MarkAllInactive();
...

[croxis]

My bad Hooman.  My post was in response to SirBombers, I actually didn't see your's :/  It was very useful information though, it helped fill in the conceptual blanks I still had on what is actually going on.  I grabbed a library which does a lot of this in its magic black box, but it is in python. I will have to make a c/c++ library down the road as it will more than likely be SLOW for large colonies as well as optimize it for the needs of the game.

I am now at version 0.2 in the roadmap and it has been pushed to trunk.  Structures now have an under construction state with appropriate graphics.  Structures now have basic connection checking in place.  If it needs a connection it wont let you build if it doesn't have one.

There are still issues that need to be worked out with the existing system.  I need to extend the legacy graphic loader to use the construction graphic properly, there are still alignment issues with the sprites.  


I am making a gameplay change.  Structures can be built next to each other without the need for connecting tubes. I can't think of any justification for otherwise, and it would help with the aesthetics of the colony (something other than a grid).  Tubes will still have uses.  Structures under construction that need connections will require an active connection to be built, but wont be able to connect other structures.  When "trucks" or other units that need pathfinding are added, they will be able to go over tubes, but not buildings.

I can make a build upon request.

[WooJoo]

i tryed my best to get it running but just got some error msgs

server

Code: [Select]

Traceback (most recent call last):
  File "./Server.py", line 177, in <module>
    main()
  File "./Server.py", line 165, in main
    game = Game(eventManager)
  File "$$$/openoutpost/Network.py", line 27, in __init__
    self.loadStructures()
AttributeError: Game instance has no attribute 'loadStructures'

and the oupost .py

Code: [Select]

DirectStart: Starting the game.
Warning: DirectNotify: category 'Interval' already exists
Known pipe types:
  glxGraphicsPipe
(all display modules loaded.)
Traceback (most recent call last):
  File "./Outpost.py", line 47, in <module>
    from UI import AIMenu, Picker, ContextMenu, UI
  File "$$$/openoutpost/UI.py", line 10, in <module>
    import Menu
ImportError: No module named Menu

hope thats not waste of your time and helps youu somehow ^^

//note this is from the old version not 0.2

[croxis]

Yah I was an idiot and forgot to add some files that I had in my development folder but I didn't add to the repository and downloads *whistles*.  Note to self, test stuff before releasing it.

[WooJoo]

xD the repo got also the lost file syndrome ^^ well well still i didnt got the change to play it once xD

[Leviathan]

Good luck on the project

Good to see new projects around!

[croxis]

I put together a quick little video demonstrating construction and level changing.  There is a definite bug in the construction process (or one Agridome was built by unions and the other not).  Also all 100 colonists died of starvation in the making of this video.

http://www.youtube.com/watch?v=X4v0oT-qduw

[Spikerocks101]

looking good, now, add some nukes...

[Hidiot]

You are well on the way of being thrown out with rocks and blight containers.

[croxis]

The problem with armed conflict in a sandbox game is there needs to be a reason for it.  Either it is zealous ideology conflicts, someone will do something that will screw another side over, or one side has something the other wants. I can see possibilities mid to late game, such as terraforming or salvaging the starship wreckage, but with so much focus spent on just surviving it is foolish to divert resources to do combat.

[Sirbomber]

So, how's it going?

Make sure you remake OP1 the way it was meant to be, and not the way it turned out...