Author Topic: Outpost Remake Thoughts  (Read 3816 times)

Offline Ameise

  • Newbie
  • *
  • Posts: 3
Outpost Remake Thoughts
« on: March 31, 2011, 09:23:11 PM »
Hello all, newcomer though I've been lurking for a very long time otherwise (I have fond memories of the series).

Before I start, I just wanted it to be known that I am a professional C++ programmer (with Java experience as well although I detest the language) and also have quite a bit of game development experience.

I've had thoughts for making a remake of OP1, but not necessarily with any or all of the original features/design implementations:

Technical Side:
C++ / OpenGL driven - this will be portable and fast. No dependence on the JVM (I don't understand why one would write in Java anyways, C# is a much nicer high level language and is supported by Mono).

Buildings would be replaced by 3d models (do not need to be complex).

Gameplay Side:
I am not entirely sure if it should be real-time or turn-based. There are merits and drawbacks to both. Turn-based can be really bad if not done well, and without clear goals or challenges per turn can be boring, while real-time can be overwhelming.

The entire resource system would be re-factored, while retaining the difficulty of the original. No mass deaths because of a shortage of 1 food, however.

I would eliminate the macro-grid, and make colonies fully expandable out. Instead of a decrementing iterator through buildings, however, I would use a distance based system - the farther away a building is from a supplying command center (after a threshold), the less efficient it becomes, by %. The lower the efficiency percentage, the more resources it requires. Supply command center in this would mean that if a command center is closer to a warehouse full of Oxygen, it would be supplying Oxygen, but another command center could supply Nitrogen.

Because of the above, the concept of a 'colony' could be distinct. It could be a sprawling mega-colony (with the obvious drawbacks of management and complexity), or many semi-independent colonies. I would have tubes also use resources (you must supply them with O2, N2, and Electricity, after all), as well as cost maintenance. For connecting distant objects such as mines or other colonies, I would implement monorails and roads. Roads being cheaper but less efficient (slower transit) yet having almost no maintenance cost, and monorails being far more efficient with higher max throughput, but costing more to maintain and requiring resources to run.

Robots would require time to move to construct. A Robodozer would not immediately end up 20km away. It would take the most efficient transit system possible (monorail, road, tube) to get there.

Require a proper connection system for labor - people must be able to get from a residential area to their 'employer', with a max distance. They should be able to use monorails and tubes, but not roads (unless terraformed).

The research system would be redone entirely. All research would be centralized, additional labs would add to throughput though you could divide up focus amongst different projects.

Nanotech would no longer make you all-powerful. I see it as giving stacking yet diminishing resource modifiers - perhaps specifying 'Auto' or a specific resource for it to focus on. Making one resource, however, should require others as something never comes from nothing.

Terraforming should actually have a use - hence making roads viable for people to use. Also, resources such as O2, N2, water, would become practically infinite, though some tiles would be replaced with 'water' tiles -- also making a new building possible: docks - creating a very efficient water transit system.

Possibly add a combat element other than a mass driver in regards to the rebel colony. Also, how is it that people defected from it to yours? Did they simply traverse the wastes? Defection shouldn't be possible until there is very close proximity.

Implement a more significant space system. Open to ideas.

Random events such as storms would actually have a significant impact, and noticeable. A comet strike would leave a large crater on the surface, and anything there would be destroyed. Early warning systems could alert you to the danger and likely strike locations. A space program may have a chance of deflecting it (but hopefully not splitting it into two :D )

I am open to more thoughts.

Offline Sirbomber

  • Hero Member
  • *****
  • Posts: 3172
Outpost Remake Thoughts
« Reply #1 on: March 31, 2011, 09:40:03 PM »
As long as it has the Mass Driver, and the associated unfortunate "accidents", I'm happy.
"As usual, colonist opinion is split between those who think the plague is a good idea, and those who are dying from it." - Outpost Evening Star

Outpost 2 Coding 101 Tutorials

Offline Ameise

  • Newbie
  • *
  • Posts: 3
Outpost Remake Thoughts
« Reply #2 on: April 11, 2011, 07:31:04 PM »
Sorry about not being on, waiting for some parts for my system to come in.

Offline jcj94

  • Sr. Member
  • ****
  • Posts: 407
    • http://techfusion-279.com
Outpost Remake Thoughts
« Reply #3 on: April 11, 2011, 07:40:51 PM »
If you make this remake well, I'll sure play it.  And another thing I noticed in op1... I never was able to get AI micromanagement to work properly.  Are you planning on keeping it or trashing it?  (I have never seen it in use, so I am unsure of its practicality)

Offline CK9

  • Administrator
  • Hero Member
  • *****
  • Posts: 6257
    • http://www.outpost2.net/~ck9
Outpost Remake Thoughts
« Reply #4 on: April 11, 2011, 09:47:19 PM »
If you keep it, improve it!  As it was, it is a waste of resources.
CK9 in outpost
Iamck in runescape (yes, I still play...sometimes...)
srentiln in minecraft (I like legos, and I like computer games...it was only a matter of time...) and youtube...
xdarkinsidex on deviantart

yup, I have too many screen names

Offline Varthlokkur

  • Newbie
  • *
  • Posts: 1
Outpost Remake Thoughts
« Reply #5 on: April 19, 2011, 03:24:25 AM »
I'm not a programmer, but I am a gamer.  Here's my wish-list.

UI stuff:  If possible, make the map fully 3d, with rotate and zoom.  If you ever played Warzone 2100, that's the sort of thing I'm looking for.

The components of the UI (minimap, menu, etc) need to be customizable - set through Preferences, and the game should obviously remember settings from one game to the next.

A random map generator would be nice. If I'm not mistaken, Outpost's maps are fixed.

How about including a map EDITOR so people could make their own "site" maps?

I believe this was mentioned, but I'll ask for it:  please make this cross-platform compatible.  There are not enough great games for Linux.

I vote for turn-based vs. real-time.  Yes it's harder to do well, but I think it makes for a better game.

More later as I think of it.


 

Offline evecolonycamander

  • Hero Member
  • *****
  • Posts: 605
Outpost Remake Thoughts
« Reply #6 on: April 19, 2011, 03:33:28 PM »
Quote
How about including a map EDITOR so people could make their own "site" maps?
indeed this would be a great option to add to ANY game. good luck getting someone to do it though.  
''The blight cant get us up here!''
-famous last words
--------------o0o--------------
Outpost 2: EoM project status: Re-planning

Offline jcj94

  • Sr. Member
  • ****
  • Posts: 407
    • http://techfusion-279.com
Outpost Remake Thoughts
« Reply #7 on: April 26, 2011, 01:11:16 PM »
Mappers traditionally come with good RTS games.. starting in 2000.

Starcraft 1 (SCMDraft v.s. StarEdit is not a battle I am willing to fight over)

WWIII Black Gold (has a lot of the UI stuff that people want, like the 3d,
      fully rotatable,zoom, and mimimap, along with the editor)

Civ3 and up. (Civ3's mapper is not an exceptional mapper, but one that suffices to    
     make overwhelmingly resourced maps, just to goof off in)

 The downside is, the mappers (Save WWIII Black Gold) are usually not that great to start with. (Probably because of time and budget constraints preventing them from making better or more powerful mappers.)  I prefer open source software mappers (SCM Draft) Over anything else.  Mostly because people who use the software can make changes to it.