Outpost Universe Forums

Projects & Development => GORF => Topic started by: croxis on February 19, 2009, 07:21:45 PM

Title: Open Outpost
Post by: croxis on February 19, 2009, 07:21:45 PM
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 (https://launchpad.net/openoutpost).

Feel free to post bugs in this thread or on the sites bug tracker (https://launchpad.net/openoutpost).

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.
Title: Open Outpost
Post by: Sirbomber on February 19, 2009, 08:39:16 PM
Quote
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).
Title: Open Outpost
Post by: croxis on February 19, 2009, 09:30:31 PM
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.
Title: Open Outpost
Post by: WooJoo on February 19, 2009, 10:27:21 PM
so how do i grab it?
Title: Open Outpost
Post by: Spikerocks101 on February 19, 2009, 11:58:06 PM
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 :P )
Title: Open Outpost
Post by: croxis on February 20, 2009, 01:32:39 AM
I'll put together a windows binary of the prototype tomorrow.  Sadly there isn't much to "play" yet.
Title: Open Outpost
Post by: WooJoo on February 20, 2009, 10:49:57 AM
Oh i just want the source or something i can compile  -_- <<<< linux
Title: Open Outpost
Post by: croxis on February 20, 2009, 01:20:25 PM
Oh good.  This is easy (for me).

Linux Install Instructions
Let me know of faulty instructions or nasty bugs
Title: Open Outpost
Post by: WooJoo on February 21, 2009, 02:05:22 AM
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?? ^^
Title: Open Outpost
Post by: croxis on February 21, 2009, 11:48:47 AM
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.
Title: Open Outpost
Post by: croxis on February 28, 2009, 03:05:00 PM
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).

(http://img8.imageshack.us/img8/9124/screenshotuntitledwindojl5.png) (http://img8.imageshack.us/my.php?image=screenshotuntitledwindojl5.png)

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?
 
Title: Open Outpost
Post by: Sirbomber on February 28, 2009, 03:08:18 PM
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).
Title: Open Outpost
Post by: Hooman on February 28, 2009, 04:35:25 PM
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
      }
    }
  }
}
Title: Open Outpost
Post by: croxis on February 28, 2009, 04:45:55 PM
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.
Title: Open Outpost
Post by: Hooman on February 28, 2009, 04:54:16 PM
That's why...

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

 MarkAllInactive();
...
Title: Open Outpost
Post by: croxis on March 03, 2009, 03:52:55 PM
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.
Title: Open Outpost
Post by: WooJoo on March 04, 2009, 03:56:17 AM
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
Title: Open Outpost
Post by: croxis on March 04, 2009, 01:19:12 PM
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.
Title: Open Outpost
Post by: WooJoo on March 04, 2009, 02:05:15 PM
xD the repo got also the lost file syndrome ^^ well well still i didnt got the change to play it once xD
Title: Open Outpost
Post by: Leviathan on March 06, 2009, 06:21:06 PM
Good luck on the project :)

Good to see new projects around!
Title: Open Outpost
Post by: croxis on March 07, 2009, 12:25:59 PM
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 (http://www.youtube.com/watch?v=X4v0oT-qduw)
Title: Open Outpost
Post by: Spikerocks101 on March 08, 2009, 10:51:08 PM
looking good, now, add some nukes... :P
Title: Open Outpost
Post by: Hidiot on March 09, 2009, 08:07:04 AM
You are well on the way of being thrown out with rocks and blight containers.
Title: Open Outpost
Post by: croxis on March 09, 2009, 10:28:32 AM
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.
Title: Open Outpost
Post by: Sirbomber on March 19, 2009, 03:05:20 PM
So, how's it going?

Make sure you remake OP1 the way it was meant to be, and not the way it turned out...
Title: Open Outpost
Post by: croxis on March 20, 2009, 05:47:29 PM
Slow right now. I'm prototyping the star selection screen.  Currently it reads from an external text file which will make adding new stars a snap.  All what is needed is the name, star class, distance, right assertion and declination and bam, a clickable star.  The gui is currently giving me headache.  After I get all that figured out it just leaves packing up for the journey and the landers and alpha 1 is out the door.
Title: Open Outpost
Post by: Sirbomber on March 20, 2009, 06:26:13 PM
Oooh, I like the sound of that.

Speaking of customization (sorta), how are you planning on dealing with planets?  I can think of a few ways to handle terrain:

1) Terrain is (more or less) random.
2) Each planet type shares a pre-set terrain (I think this is what OP1 does).
3) Every planet is unique.

Also, do you plan on using the three unused planet types from OP1 (Earth* and two others) or adding any new planet types of your own?

* The problem with adding an Earth-like world is that it would be like playing an entirely different game.  Tubes and the Underground section would serve no purpose (there's no need for a self-contained colony if the atmosphere is breathable and the planet is habitable), as would several of the structures.  Disasters would be different (though not drastically - you could probably get away with different names for the same things), and surface water would most definitely affect gameplay.

Anyways, it's probably too early in development to even consider most of this stuff.  Sorry for bothering you, but if you're serious about going through with this I wanted to talk about a few points I'd like to see addressed.
Title: Open Outpost
Post by: croxis on March 20, 2009, 10:56:21 PM
No it is a good think to talk about, at the very least I can put in some ground work.  But yah, to your earlyer post it would be silly to outright clone Outpost.  I'd really like to more about the origional vision they had, trying to get a copy of that infamous PC  Gamer review. I did find this though: http://www.ibiblio.org/GameBytes/issue18/flooks/outpost.html (http://www.ibiblio.org/GameBytes/issue18/flooks/outpost.html)  Based on that screenshot I really like that kind of idea for mining.

I'm a big fan of the civilization series, so I am taking customization to heart.  Like outpost 1 there are planet types, but the values will be ranges instead of absolute.  Type and age of the star and distance will also affect stuff.  So a building on a big planet will need more resources to build cuz of the structural support, and a planet close tot he sun those buildings will need more resources for the shielding, so on and so on.

Terrain is generated from a randomly generated heightmap, opens up the possibility for importing heightmaps.  Terrain type is interpreted from that. In the config file the user says what graphic to use for what kind of tile.  Planet types can be dropped in and I plan for the client to download any assets it doesn't have from the server in mp games.  

I plan on having most the types in the manual, and adding some like Titan.

I am not going to add earth type planets as it would be a very different game.  Here is my idea for winning the game.  Game is about making the human race survive, so each player(s) will get points for their population and health.  The game will end when a player's starship reaches Earth first (civ 2 style), or when a planet is terriformed, the person with the highest score wins.  Some planets will be impossible to terraform so you can only win by launching a spaceship.
Title: Open Outpost
Post by: Sirbomber on March 21, 2009, 07:21:20 AM
Quote
The game will end when a player's starship reaches Earth first (civ 2 style)
Earth is totally destroyed.  There's no point in going back there.  You just "launch" the new starship at the end of OP1, but they never tell you where it's going (to the best of my knowledge).
Title: Open Outpost
Post by: croxis on March 21, 2009, 06:26:38 PM
For earth to be destroyed would require a massive object, mars size or bigger, at high speeds.  What is much more likely, and reasonable, is a "smaller" asteroid causing a mass extinction event which would kill off the human race but the surface will still be habitable, especially after a few hundred years.
Title: Open Outpost
Post by: Sirbomber on March 21, 2009, 07:15:43 PM
Quote
...a mass extinction event which would kill off the human race but the surface will still be habitable, especially after a few hundred years.
No, that's what I meant by destroyed; while the planet is still there it's not really "Earth" anymore and there's no point in going back.
Title: Open Outpost
Post by: ducktape on March 31, 2009, 09:10:50 PM
Regarding the tubes... If you haven't gotten too solid of an implementation for them yet, I don't see why you WOULDN'T use them. View them as a path for people. For example, when trucking is implemented, how do things get from the truck unload point to somewhere else, like a storage tank? Surely you wouldn't carry things through an agridome, smelter, CHAP facility, and then get to your storage tank or warehouse. It'd disrupt the happenings inside the structure used in the route to the destination. (at least practically speaking) They seem to be more of a dedicated way to move people, goods, and materials, without disrupting colony operations too much.  
Title: Open Outpost
Post by: croxis on April 02, 2009, 03:13:37 PM
That is a very fair point. One of the long term goals is changing how tubes and structures connect by giving them bandwidth for power, life support, etc, with tubes offering the most.  This will require a bit of pathfinding for a lot of aspects which is a bit beyond my programming abilities at this point.
Title: Open Outpost
Post by: ducktape on April 02, 2009, 08:26:30 PM
I like the idea of there being 'bandwidth' so to speak for power. If you're going to write that, you could even go as far as to consider foot traffic in tubes since it'd use a similar system, just from different starting/ending points. Also opens up making monorails more useful to haul people, as no one is going to want to walk 100 tiles to some outskirt area or fledgling colony.

The power generation could see something similar to a communications tower be researched, but wirelessly transmit power. Of course, these should be expensive and not be able to directly supply a structure, only send power over a vast distance so you don't have to use as many tubes and block all that space that trucks or monorails could be using (or structures).

 
Title: Open Outpost
Post by: croxis on April 04, 2009, 04:02:22 PM
Update:

The initial game progression is in place.  Main menu to introducing yourself to the ai to selecting the star system, to packing bags, to picking the planet, and then the terrain.  

All that is left is putting in the landers and a save/load system. When implementing the landers I discovered problem with how I implemented the UI.  The quick fix would be passing the entire gamestate to the menu generator which is a bit excessive, and breaks the MVC model (which I've already violated more than once, but shhh).
Title: Open Outpost
Post by: Leviathan on April 05, 2009, 03:57:29 PM
Thanks for the update. Its sounding good. Great work :)
Title: Open Outpost
Post by: croxis on April 16, 2009, 11:47:18 PM
Seed lander and associated functions now in place:
(http://img404.imageshack.us/img404/8124/screenshotlander.png)
Title: Open Outpost
Post by: Hidiot on April 17, 2009, 01:40:56 AM
Getting somewhere.

Um.. Keep up the good work?
Title: Open Outpost
Post by: Sirbomber on April 17, 2009, 06:07:21 AM
I deem this BLARYEUGH (which is a good thing and is not to be confused BLARUGH, which is bad).
Title: Open Outpost
Post by: omagaalpha on April 17, 2009, 04:25:55 PM
Cool picture, show getting somewhere.
 
Title: Open Outpost
Post by: DeathSquire36 on April 17, 2009, 07:31:28 PM
I gotta say, I'm really looking forward to this.  I've always liked Outpost 1.5, but knew it was incomplete and could have been much better.  But I've always enjoyed the core gameplay and idea of it.

So I joined up here just to tell you to keep up the good work, and I'll definitely be getting this when it's complete!  Good job man.
Title: Open Outpost
Post by: croxis on April 20, 2009, 07:59:26 PM
This is a test windows 32 build of what may be alpha 1.  It works for me, but I also have a development environment set up so I don't know how well it will work on "normal" systems.

http://croxis.net/OpenOutpost/ (http://croxis.net/OpenOutpost/)
Title: Open Outpost
Post by: Sirbomber on April 20, 2009, 09:27:17 PM
When I click "New Game" it unleashes an infinite loop of doom upon me and spams zeroes to the console until I stop it.

Edit: It's also very big...  You might want to do something about the size (at the very least shove the installer into a RAR or something).
Title: Open Outpost
Post by: omagaalpha on April 21, 2009, 06:55:24 AM
On my Machine I notice when do new game it issues zeros of death too. Also notice that you don't logger(output information of run into file) instaled on this version maybe want implement so it easier for you figure out goes wrong on other machines?
Title: Open Outpost
Post by: croxis on April 21, 2009, 11:05:15 AM
Well bugger.  I made a new install of windows in a virtual machine (you would think I would of thought of this sooner).  The problem is in this bit of code

Code: [Select]
    def launchSPServer(self):
        #self.singlePlayer = True
        if os.name == 'posix':
            self.server = subprocess.Popen('python' +' ./Server.py', shell=True)
            #self.server = subprocess.Popen('panda' +' ./Server.py', shell=True)
            self.server = True
        else:
            self.server = subprocess.Popen('..\\python\\ppython.exe' +' Server.py')
            self.server = True
        import socket
        x = True
        serverSocket = socket.socket()
        serverSocket.settimeout(0.25)
        while x:
            try:
                #print 0
                serverSocket.connect(('127.0.0.1', 1999))
                x = False
                #print 1
            except socket.error:
                pass
        messenger.send('login')
        print 'Server launched'

which launches the server, checks that it is listening and ready to go (the while loop) before the client attempts to log in.  It works fine in linux. Under windows the server launches properly, but the port check constantly returns a socket error.
Title: Open Outpost
Post by: croxis on May 06, 2009, 08:11:33 PM
There are some bugs in the end user packing software. As soon as I get the fixes from upstream I'll have an alpha release for you guys!
Title: Open Outpost
Post by: Hidiot on May 07, 2009, 05:45:06 AM
Maybe, just maybe, this is another project worthy of its own forum and sub-forums?
Title: Open Outpost
Post by: croxis on May 08, 2009, 03:50:33 PM
Eh, I see no need as long as everything is self contained in this thread
Title: Open Outpost
Post by: croxis on May 14, 2009, 08:06:08 PM
Alpha prototype.  Feel free to post bugs in this thread or on the sites bug tracker (https://launchpad.net/openoutpost).

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 either C:\Windows\System32.  If it asks to overwrite, say no.

Downloads:
Windows (http://croxis.net/OpenOutpost/openoutpost-Alpha.0.exe)
Windows Patch (http://croxis.net/OpenOutpost/openoutpost%20alpha0%20patch.zip)
Ubuntu/Debian 64 (http://croxis.net/OpenOutpost/openoutpost_Alpha.0_amd64.deb)

*crosses fingers*
Title: Open Outpost
Post by: WooJoo on May 15, 2009, 02:51:26 AM
im on my windows machine and i cant seem to find the exe to run the game give me hint on that pls ^^
Title: Open Outpost
Post by: croxis on May 15, 2009, 10:41:46 AM
There isn't an exe.  Just use the start menu icon.

Ubuntu/Debian 64 bit package added
Title: Open Outpost
Post by: croxis on May 18, 2009, 03:13:52 PM
I posted a zip with the missing files for the window users.  Please see the first post for the link.
Title: Open Outpost
Post by: Leviathan on May 19, 2009, 06:31:52 AM
Thanks for the update and files :)
Title: Open Outpost
Post by: Psudomorph on May 29, 2009, 09:50:14 AM
Would you like troubleshooting questions to go somewhere specific, or should it all stay in this thread?

I'm having trouble getting this to run on windowsXP SP3. I installed the patch but it didn't help.
When I use the start menu shortcut the openoutpost window will appear for a split second then vanish. Trying to run from the command prompt  gives the following response (although I could swear I saw more text than this during the split second the window was up)
Code: [Select]
C:\openoutpost-Alpha.0\python>ppython.exe -E main.py
ppython.exe: can't open file 'main.py': [Errno 2] No such file or directory

When I try to execute main.py directly (I already have python on this computer) it gives the following error:
Code: [Select]
Traceback (most recent call last):
  File "C:\openoutpost-Alpha.0\game\main.py", line 4, in <module>
    import Outpost
  File "C:\openoutpost-Alpha.0\game\Outpost.py", line 6, in <module>
    from pandac.PandaModules import loadPrcFileData
ImportError: No module named pandac.PandaModules

Possible relevant info:
-I have python 2.6 installed on the computer already
-I may have once had panda3D installed here, but have since removed it.
Title: Open Outpost
Post by: croxis on May 29, 2009, 01:30:56 PM
This thread is fine.  The first issue is that main.py is under C:\openoutpost-Alpha.0\game\main.py

Secondly that the windows install will install its own version of python, in this case C:\openoutpost-Alpha.0\python, and will install all the needed libraries there, completely ignoring any existing python install.  The command you will want is:

C:\openoutpost-Alpha.0\game> C:\openoutpost-Alpha.0\python\ppython.exe -E main.py


Longer explanation for the curious.  Disney makes/uses panda for many of its games, most notably pirates and toon town.  Because their target audience probably use old handmedowns systems with windows ME or older the window builds are restricted to python 2.5.  I plan on making a build against python 2.6, and maybe make a patch to the installer which will look for existing installs to install the needed libraries to if present.
Title: Open Outpost
Post by: Psudomorph on May 31, 2009, 08:24:39 PM
Thanks, I think it might take a few weeks to wrap my head around why that worked, but anyway...
Here is the full error message that OO gives when executed:
Code: [Select]
DirectStart: Starting the game.
Known pipe types:
  wglGraphicsPipe
(all display modules loaded.)
:display:wgldisplay(error): SetPixelFormat(57) failed after window create
:display(error): Window wouldn't open; abandoning window.
:ShowBase(warning): Unable to open 'onscreen' window.
Traceback (most recent call last):
  File "main.py", line 4, in <module>
    import Outpost
  File "C:\openoutpost-Alpha.0\game\Outpost.py", line 24, in <module>
    import direct.directbase.DirectStart
  File "C:\openoutpost-Alpha.0\direct\directbase\DirectStart.py", line 4, in <mo
dule>
    ShowBase.ShowBase()
  File "C:\openoutpost-Alpha.0\direct\showbase\ShowBase.py", line 229, in __init
__
    self.openDefaultWindow(startDirect = False, props=props)
  File "C:\openoutpost-Alpha.0\direct\showbase\ShowBase.py", line 726, in openDe
faultWindow
    raise StandardError, 'Could not open window.'
StandardError: Could not open window.

Also: couldn't this stuff be written to an error log, so people can just copy/paste it instead of having to run from the command line in order to catch the error message? Seems like it would make bug reporting easier.

=====non-troubleshooting conversation=====

-I'm glad you are keeping the tubes in the game, there needs to be some constraint to keep colonies from just being blobs of buildings all right next to each other. If you want to eliminate some of the tedium of them though, maybe allow them to be built in lines.

-You said you were using a heightmap, how does it translate into a grid? Does it literally represent each square as a different height like Sid Meirs Alpha Centauri/Sim City 2000/3000, or will the game retain the OP1/OP2/Civ style of each square having a particular type of terrain? (please tell me it's not the former, I always hated that system)

-Jessai mentioned power transmitters to cut down on tubes. I don't think power transmitters would be all that useful though; if you are going to build two power transmitter stations, why not just build a power plant in the far-off colony and get the added disaster resistance? In any case tubes would still be required for their air/water/waste/etc.
I think the solution is that far off colonies should just have their own separate infrastructure, rather than trying to tube across an entire continent.

Also, on the subject of tubes getting in the way of things, do you think it would be difficult to make the three connector tiles pass over each other? You would need to make a custom "road sloping under tube" tile, but the others fit together very well already.
(http://img192.imageshack.us/img192/8389/intersections.th.png) (http://img192.imageshack.us/my.php?image=intersections.png)

-Finally, a nitpick; when you changed levels in the video it looked like you were going down a very very long way. I feel like each underground level should only be one, maybe two tiles deeper than the last (see pic). I don't have any real-life underground cities to compare with, but going down so deep seems unrealistic.
(http://img30.imageshack.us/img30/463/ugdistance.th.png) (http://img30.imageshack.us/my.php?image=ugdistance.png)
Title: Open Outpost
Post by: croxis on June 02, 2009, 02:25:15 PM
Log to file is currently in the trunk. When I get the gui library finished I'll post another test install for final bug fixing  before the real Alpha 1.  I looked up this specific issue and it is one of two things: Your color depth is not 24 or 32 bit, or something is wrong with your opengl drivers.  I put in a bug report to remind me to implement dx when running in windows.

I plan on just having a tube tile that will make a new connection when there is a new adjacent building.  It should clean up the look a bit.

Eventually the heightmap will translate into terrain roughness.  Ultimate desire though is to have a building system more akin to op2.  I would like to use actual height (sc2,3,4, etc) but that will require even more additional art and code work.

Long distance power transition wouldn't work.  Many planetary bodies don't have a magnetic field so long distance power transmition would be severely disrupted. Best bet to keep tubes would be either "bandwidth" benefits or making structure placement actually important (YIMBY/NIMBY, or adjacency bonuses).

As for crossing the different transport types, it should totally be easy, especially once we move to 3d assets.

The animation was just that, an animation.  It jsut demonstrated that I was doing something fancy.  I put each level 10 units down.  I can just as easy make it 2.
 
Title: Open Outpost
Post by: ducktape on June 14, 2009, 11:47:16 PM
The wireless transfer of power would be a bit far fetched I guess. The main idea I had was transporting power from remote areas with tough terrain (geothermal power or really rare minerals that you just have to have). But other way could just as easily be conceived to serve the same purpose.

I've tried installing using those links on Windows XP as well as Ubuntu, neither of which I can get working. The windows version just let's me hit new game, to where it goes to a screen with a white circle and I have no more options.

Ubuntu says I have the wrong architecture, which I don't have a 64-bit CPU. Is there any way around this, maybe a 32-bit version floating around, or am I just completely screwing this up?
Title: Open Outpost
Post by: croxis on June 15, 2009, 11:05:36 AM
I do think there should be a more easy way to draw power from remote locations without the tedium of placing tubes one tile at a time.  A click and drag method (power lines in sc4 for example) would be best.

I'm still working away on the new GUI code as well as getting the colony information client side as well.  I'll probably do one more prototype release once that is completed and make sure to get a 32 bit version as well, which I did not make a build for last time. So no, you didn't screw it up :P  I chose to use the 64bit version of ubuntu, so that is what I build for.  I have a 32 bit version in a virtual machine to make those builds.
Title: Open Outpost
Post by: xtra chedda on July 28, 2009, 03:45:07 PM
I just want you to know how excited I was to find this project. I was a big fan of Outpost when it first came out. I invested alot of time during my childhood into colonizing distant planets thanks to this game. I was just wondering if you have any news on the project. I installed everything and had the the same problem as Jessai.
Title: Open Outpost
Post by: croxis on July 31, 2009, 05:01:53 PM
I am indeed still working on it.  I'm on my third rewrite for the gui, and now wrestling on how to display information for the command center window.
Title: Open Outpost
Post by: Charles_Bronson on August 01, 2009, 09:43:15 PM
Im a big outpost fan. I always dreamed of a sequel of op1, but circustances made it impossible.

keep up the good work guys, you can do it.
Title: Open Outpost
Post by: Hidiot on August 02, 2009, 05:10:08 AM
The sequel of Outpost 1 is Outpost 2.
Title: Open Outpost
Post by: Charles_Bronson on August 09, 2009, 05:00:28 AM
outpost 2 is a game i had lots of fun with, but its not a spiritual sequel of Op1.

it is just another game, with a RTS feeling, not a Simcity/Civilization feel.
Title: Open Outpost
Post by: Hidiot on August 09, 2009, 07:50:08 AM
It is still, officially, the sequel.

The story even fits... somewhat.
Title: Open Outpost
Post by: Sirbomber on August 09, 2009, 12:08:40 PM
Quote
outpost 2 is a game i had lots of fun with, but its not a spiritual sequel of Op1.

it is just another game, with a RTS feeling, not a Simcity/Civilization feel.
A "spiritual sequel" of OP1?  What would that involve, even crappier gameplay and more bugs/incompleteness?

OP2 is not "just another RTS game" because you must also manage your colony, not just go on a killing rampage.
Title: Open Outpost
Post by: croxis on August 21, 2009, 12:30:38 PM
I just finished migration to the new netcode library (thank god).  I now have a regression where the colonists aren't having babies anymore.  Once that bugger is done I am going to put together some prototypes of the Alpha for testing, then get alpha 1 out the door.  Took me a few more months than expected :P
Title: Open Outpost
Post by: Jenner on August 25, 2009, 10:16:21 PM
First post here! I'm thrilled that Outpost 1, a game I really enjoyed growing up, is being given the attention it deserves. I think it's great that a remake/update is in the works!

This may have been addressed already, but when I try to run the program I get to a screen with a large white circle and the following error is reported in the status window:

raise IOError, message
exceptions.IOError: Could not load model file(s): ['models/gui/dialog_box_gui']
Failed to load espeak-data

I'm running Windows XP Pro and have installed the patch files into Windows\System32



 
Title: Open Outpost
Post by: croxis on August 26, 2009, 09:20:07 PM
Yah the old prototypes had various issues with them.  I've been very busy teaching band camp the past two weeks and haven't had the time to sit down to finish the code needed.  Hold your horses until I can get a new version out the door :)
Title: Open Outpost
Post by: Jenner on August 26, 2009, 10:11:26 PM
Quote
Yah the old prototypes had various issues with them.  I've been very busy teaching band camp the past two weeks and haven't had the time to sit down to finish the code needed.  Hold your horses until I can get a new version out the door :)
No problem. I eagerly await the next release.  :D  
Title: Open Outpost
Post by: pbhead on October 11, 2009, 01:40:06 PM
ima posting here for verbal encouraging support...

go croxis go! ra! ra! rwhat... rymes with croxis... umm..

you can make a better sim than maxis!

(err... well... since simcity societies ... really... really sucked... and would not be hard to top. )
Title: Open Outpost
Post by: Jenner on October 17, 2009, 03:13:41 PM
Quote
ima posting here for verbal encouraging support...

go croxis go! ra! ra! rwhat... rymes with croxis... umm..

you can make a better sim than maxis!

(err... well... since simcity societies ... really... really sucked... and would not be hard to top. )
I'll second the verbal encouragement.  :D  
Title: Open Outpost
Post by: Hellspawn on January 24, 2010, 03:49:44 PM
How are things going? I used to play Outpost 1 a long time ago. I did finish it once, on the easiest difficulty. If you can ever finish this game. It just goes on after the "ending" movie.

I really like the idea to play a fan remake, wich also includes the left out, or never developed stuff wich is also mentioned in the official Outpost guide I have around here somewhere.

So how far along is the project? Can I look up my old 1.5 Outpost cd-rom and start playing soon?

By the way, I know one copy of the original disk (cd-rom) for sale here in the Netherlands. Can I make someone happy with it?

*Now where did I leave that thick Outpost book??*
Title: Open Outpost
Post by: Sirbomber on January 24, 2010, 05:04:32 PM
Seeing as how we haven't heard anything for a long time, I'm calling the project dead.
Title: Open Outpost
Post by: AmIMeYet on January 25, 2010, 08:37:32 AM
Last activity on launchpad ~4 months ago.
Title: Open Outpost
Post by: Hellspawn on January 28, 2010, 04:23:34 PM
So another project probably down the drain. Too bad.  :(

Same thing happened with the Star Wars Knights of the Old Republic 2 restoration project from Team Gizka.

Guess I'll start playing the unmodded game sometime soon. Not interested in part 2. I'm not into the war theme from that one. Original was all about survival without weapons.
Title: Open Outpost
Post by: meatwad1666 on February 01, 2010, 10:56:40 PM
Quote
So another project probably down the drain. Too bad.  :(

Same thing happened with the Star Wars Knights of the Old Republic 2 restoration project from Team Gizka.

Guess I'll start playing the unmodded game sometime soon. Not interested in part 2. I'm not into the war theme from that one. Original was all about survival without weapons.
well i..... well yeah i guess so but iw still love the weps in OP2 i always love the rail gun
Title: Open Outpost
Post by: The_Blight on February 10, 2010, 09:52:24 AM
Hmm. I wonder if there aren't any other means of succesfully resurrecting (and sustaining) this project. As OPU has existed for a long time, perhaps it's better to accept an OP1 remake won't happen at a steady pace, and that there'll be times when the programmer resource pool dries up completely, only to have some new ones show up some months later...

Don't get me wrong, it's a daunting task to begin with, as the original is so buggy it's hard to get what's going on, not to mention programming techniques and hardware have changed considerably over time, and things that were okay back then could be a big no-no today, and vice versa.

Considering the rather volatile lifecycle of open-source projects, wouldn't it be better to opt for a 'high ceremony, low cycles' approach, making documentation the most important artifact ? Thus setting out the prerequisites at the start, making use of Use Cases, and from those generate a Class Diagram, and only after that's all in place start writing code?

Some of you may recognise the Waterfall model in this approach, while it's bloated and slow, it does offer possibilities to 'restart' with new people as its documentation level is much higher. And it doesn't require anyone to go through code to get what's going on.

Also, this would allow 'roll-backs' of certain parts of the project, e.g. if it should be decided that the engine needed to be updated/changed, or that certain modules are to be added/removed.

In short, I respect croxis' attempt very much, and noone is pointing fingers here, everyone has their own priorities, and noone can expect "recreating a game" to be the first on that list.

In short, if I would ever try to recreate it, it would be as vanilla as vanilla  could be, whatever should have been possible in the original, should be possible in its recreation. Mixes with OP2 or other RTS game element are a noble intent, but will almost surely never be implemented and could make the development process even more complicated.


As for the ideas of mixing several game elements into a new one: I really liked how OP1 placed 'Science' first and used 'Science' to generate progress. While I do love certain aspects of OP2, its combat system doesn't make very much sense and makes it look rather cheesy and cartoony IMO. OP1 had a more 'serious' approach, the smallest mistake on your end (and with a little help from the bugs) could cause you to lose it all.

Ofcourse a project is only viable if there are people willing to participate in it!
Title: Open Outpost
Post by: Simpsonboy77 on February 10, 2010, 11:25:44 PM
Interesting post The_Blight

Sure if everyone documented their projects it would be much easier to pick up. The problem is I have yet to meet a programmer who documents the program before/while coding. I'm even guilty of it, I normally finish part of a program then go back and comment it. In my opinion documenting is the most boring part.

Most of these projects are either 1 or a small group of people doing it. Chances are at the beginning they have the intention of completing it. So they go coding, and eventually real life hits, and they can't find the time. They probably don't have a class hierarchy or a description of each method in their program so so its tough to look at it and see what its doing. And they sure don't have time to document it, because they would rather spend their time actually making it.

With all due respect you can't really tell someone to drop their project and document it. They started whatever project because they wanted to. They are driven by their own motives, and documenting it isn't on the list.

I'll probably edit this a few times so don't quote it within the first 30 minutes.
Title: Open Outpost
Post by: CK9 on February 11, 2010, 12:25:43 AM
And that's why engineers could never be considered programmers :P

Whenever an engineer creates a program for a process, the following steps are followed (90% of the time, heh):

1) Identify parameters (What do we want?  What do we know?  What equations apply?  etc.)
2) Decide on what actions will always group together
3) Build functions based on 2
4) Identify function use (where in the code the function is called)
5) Put it all together and hope it works the first time (:P)

each step involves a fair ammount of notes specifically so that, if another engineer needs to modify or add something, it won't take much time to find anything.  Of course, we don't code very often, as there are many programs out there that let us do what we need to do (such as ProII, Superpro (two different companies oddly enough, lol), ect.)
Title: Open Outpost
Post by: The_Blight on February 11, 2010, 12:22:37 PM
Quote
Sure if everyone documented their projects it would be much easier to pick up. The problem is I have yet to meet a programmer who documents the program before/while coding. I'm even guilty of it, I normally finish part of a program then go back and comment it. In my opinion documenting is the most boring part.

Fine, but often 'boring' is part of the job. Ofcourse it's blatantly obvious what the code you wrote yourself means, documenting is about making the meaning and structure clear to people who haven't written that code.

Quote
Most of these projects are either 1 or a small group of people doing it. Chances are at the beginning they have the intention of completing it. So they go coding, and eventually real life hits, and they can't find the time. They probably don't have a class hierarchy or a description of each method in their program so so its tough to look at it and see what its doing. And they sure don't have time to document it, because they would rather spend their time actually making it.

In all honesty, that translates into: 'destined to fail, time after time'.

Quote
With all due respect you can't really tell someone to drop their project and document it. They started whatever project because they wanted to. They are driven by their own motives, and documenting it isn't on the list.

Nobody should drop anything. Documenting isn't a punishment. If tomorrow someone feels the need to redo Outpost in pink and glitters, by all means, he/she should do it. I was only saying that if one starts to see a pattern in the interest in a certain project, one could perhaps change course and use it to their advantage.

Some people do document, some even apply Software Engineering principles.
Once again, croxis did a great job, and I have nothing but respect for his efforts.
Title: Open Outpost
Post by: lordpalandus on February 25, 2010, 02:58:47 PM
So Outpost 1 Remake is dead then?

I always thought that Outpost 1 + Outpost 2 could make a great Outpost 3... in that, when you started Outpost 1, you had to choose several different things, like which planet you would go to and resources you have etc etc. I think that system could be applied to Outpost 3... if it was ever made.

Like wouldn't you have chosen a better planet than New Terra? I'm sure some moons would have been more hospitalible.
Title: Open Outpost
Post by: Kayedon on February 25, 2010, 03:49:39 PM
Quote
So Outpost 1 Remake is dead then?

I always thought that Outpost 1 + Outpost 2 could make a great Outpost 3... in that, when you started Outpost 1, you had to choose several different things, like which planet you would go to and resources you have etc etc. I think that system could be applied to Outpost 3... if it was ever made.

Like wouldn't you have chosen a better planet than New Terra? I'm sure some moons would have been more hospitalible.
The last part is debatable. As I no longer own any viable 32-bit systems I haven't ever played OP1. However, having the two relate into one awesome game would be a project I would love to adventure into.  
Title: Open Outpost
Post by: Sirbomber on February 25, 2010, 04:59:02 PM
Because nothing screams "exciting RTS" like having to take 15 minutes to find a hospitable planet in the system you want, then pack your cargo, deploy it all once you arrive at your destination, and start with literally nothing.
Title: Open Outpost
Post by: CK9 on February 25, 2010, 05:46:08 PM
not to mention that you have to deal with vehicles you can't see suddenly getting oblitered without explanation...
Title: Open Outpost
Post by: croxis on March 28, 2010, 09:24:32 PM
Well I would like to think I decently documented my code  :P

Sorry for the overtly quiet hiatus. I've been nabbed working on a city builder (http://sc4devotion.com/forums/index.php?board=365.0) project which I intentionally designed to be similar code wise to Open Outpost. I'm taking all the things I developed for CityMania (gui code, paged geomipterrain with splatting using some simple shaders, etc). The new gui fit in with very little changed to the code. However the new terrain system is going to need some work to integrate in as they are vastly different systems. The old terrain system I was using did not separate data from presentation.

While the bazarr branch has not been updated in 4 months, work has been done on OO indirectly through this other project. I project getting all the new code in by Wednesday.
Title: Open Outpost
Post by: croxis on April 01, 2010, 10:51:01 PM
Screenshot time!

(http://img706.imageshack.us/img706/1917/screenshot009x.th.png) (http://img706.imageshack.us/i/screenshot009x.png/)

I didn't even touch the building graphic code, how the heck did this happen!?! May have to pull out each graphic by hand, or think of some UV trickery.

Orthographic camera is currently off (will be back on later), terrain is using the new splatting system, and new gui code (not visible).
Title: Open Outpost
Post by: croxis on April 05, 2010, 05:00:19 PM
Prototype is back to its previous functionality. I am waiting for an issue to resolve in the upstream packing system and should hopefully get alpha 1 offically out the door in the next two days.
Title: Open Outpost
Post by: jcj94 on December 27, 2010, 09:09:36 PM
Quote
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 :P )
same.. i read the readme, not the download instructions
Title: Open Outpost
Post by: jcj94 on December 27, 2010, 09:15:21 PM
...... what would happen.. if we ALL, using OP1's backbone and OP2's tech-tree tried to create an OP3?... would it work.. would it look anything right.. or.. I don't know, im just randomly babbling here.

I'd love to see an outpost 3... and I believe IF we get almost everyone working in close tandem, we MIGHT be able to do it, or at least a better, more expansive OP2.. Maybe a *OP3 Colony Game pack*.. maybe a total rehaul.



The only problem.. i think there are going to be a LOT of legal issues...  <_<

Would there? :(  :op2: