Author Topic: Things We Would Do Differently  (Read 3515 times)

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Things We Would Do Differently
« on: December 06, 2006, 05:50:27 PM »
Now that we have the benefit of hindsight, and years of play, or editing/tweaking/hacking, what would we have done differently if we had coded OP2. Feel free to suggest ideas that weren't around, weren't feasible, or weren't big at the time OP2 was created.

You can try for the big grand picture, but really specific examples would be better. Let's see who has an eye for detail.



The network protocol! The client would never bind to an address, and addresses would never be stored inside packets. Only return addresses on the packets would be used. NAT would never have been an issues, and only the game hoster would need to worry about port forwarding.


There would be no hardcoded use of techIDs from the techtree files. All changes upon researching a tech would be done through tags/properties set in the tech file. Instead of making disaster warning depend on a hardcoded techID within the exe, the tech file would have a property along the lines of INCREASED_DISASTER_WARN  <disasterType>. Techs that allow units or structures to be built would have something like ALLOW_UNIT <unitName>. There would also be an increased number of tags so more properties could be edited. Maybe even take things to the extreme and define all unit properties within the tech file, thus removing the need for the vehicle.txt file.


Levels would be able to redefine all game rules more easily. As in being able to replace any of the .txt files, not just the tech tree.


Map files could be self contained. The basic unit setup could be defined within the map files eliminating the need for a DLL to do it. There would also be support for basic trigger handling stored in the map file in some sort of data structure (or scripting language, but probably just a simple data structure). The map file would also contain all the settings it needed for the different game types (LOS/SR/Midas/Etc.). This would eliminate the need for DLLs and thus make map files self contained. Allowing a DLL, particularly for advanced scipting would be nice, but DLLs wouldn't be required, and certainly no more than one DLL should be needed to handle advanced scripting for all game types on that map.


The tile group info would be moved from the map files to the tileset files, where it would make a lot more sense to store it. There would be an increased amount of meta data describing the tilesets. This would be especially true for the terrain transitions and would include change directionality and border offset. Cell type info would also be placed into the tile set files. There would be a simple one to one onto correspondence between tiles and cell types.


Compressed audio would be nice.


There would be increased meta data describing the animations and graphics in the art file. The data in the .prt and the .art file would be merged into one file.


The radio button selection would be fixed.


More functions useful for building an AI would be exported. An attempt at a basic AI that could be placed into any level would be made. This would be done in a DLL in such a way that allows for easy upgrades to the AI, or available AIs to choose from.


Checksums would depend on actual data, not the compressed format of data.


Game recording would be built in.


Convecs would not be able to move away when they start construction. Maybe allow multiple convecs to work on the same structure.


Certain map file format limits would be eased. If the cell types were stored in the tileset files in such a nice association as mentioned above, then those bits would no longer be needed in the map files and could be used for something else. This would make it easy to extend the number of tiles a map could use. (Current limit is 2048 tiles).


The lava possible bits in the map files would actually be used, rather than set in the DLLs like is currently done. Maybe add support for defining different flows, perhaps based on difficulty, or maybe just random.


Change the unit system so tile's don't need to reference units. This would make it easy to increase the max unit limit. Instead, use an alternate data structure to keep track of unit locations and quickly finding all the units in a given area. (Such as when drawing the units currently visible on screen).


Add some sort of unit death and/or capture event or callback. This would help AIs keep track of units, or make for an easy way of keeping track of the number of active buildings of a given type. This would be more efficient than rescanning all units every so often.
 

Offline Nightmare24148

  • Full Member
  • ***
  • Posts: 148
Things We Would Do Differently
« Reply #1 on: December 27, 2006, 05:45:02 PM »
Well...making Trading Center more useful:

*If you want, have a setting on your Trade Center transfer all your stuff if you leave to your selected player.

*Have structures transferable.

*Collaborationist Research Topics - i.e. if you're Eden, and you're allied with someone from say Plymouth, you get new research topics, and if its Eden allied with Eden, new research topics...and if you leave the alliance, you lose the topics, or at least the ability to use what they produced.

I had a ton of ideas but can't remember.
I look to see, in the mirror.

All I see, is that he is me.

Offline TH300

  • Hero Member
  • *****
  • Posts: 1404
    • http://op3game.net
Things We Would Do Differently
« Reply #2 on: December 27, 2006, 09:10:36 PM »
Quote
Cell type info would also be placed into the tile set files
I disagree. You save one bit, but you also loose flexibility.

besides...

- avoid ugly bugs (can't build tubes on some tiles after something certain happened ; newly built vehicles appear behind cliffs)

Offline Nightmare24148

  • Full Member
  • ***
  • Posts: 148
Things We Would Do Differently
« Reply #3 on: December 28, 2006, 09:48:30 PM »
Honestly, self destruct capability for buildings woulda been REALLY useful...and not only that, but its in the novellas.
I look to see, in the mirror.

All I see, is that he is me.

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Things We Would Do Differently
« Reply #4 on: December 29, 2006, 01:40:16 AM »
Quote
QUOTE 
Cell type info would also be placed into the tile set files

I disagree. You save one bit, but you also loose flexibility.

besides...

- avoid ugly bugs (can't build tubes on some tiles after something certain happened ; newly built vehicles appear behind cliffs)

Hmm, I see. I do like flexibility, but then I'm going to have to disagree with your disagreement for the following reasons:
- It creates an unnatural separations between tile graphics and tile behavior requiring extra effort to keep the two in synch, which is usually the desired behavior.
- This feature is not very useful, and if it is used, it is often misused. It often makes a game look buggy rather than feature rich. If someone decides to add a secret passable ridge into their map, it looks more like a bug in their map than a feature. What's worse is when the editing tools make it easy to do this by accident, thus making it a true bug. Basically if you're "teaching" the user that ridges are impassible, than all ridges should really be impassible. You shouldn't be adding in odd behaviors counter to what the user expects of them.
- This flexibility could be achieved by adding more tiles, with the same graphics, but different movability attributes. The overall effect is the same, but there would seem to be less possible problems to worry about. Even if a tile graphic is not consistent in behavior, there is still a smaller set of behaviors that it can take on, provided you don't make too many duplicate tiles with different attributes. Plus, if you had to create new tiles, and possibly a new tileset to hold them, you'd be less likely to make mistakes by accident. Granted, it's a little more work to achieve the same effect, but I feel this is justified given the point above. It should be difficult to do this to discourage it's use.


So yeah, basically I'm saying there is a better way (in my mind) to achieve the same effect. You also don't have to use up 5 out of 32 bits of every tile to achieve that effect.


I like the self destructing buildings idea. I've wished I could do that a few times. It'd be nice to detonate an Adv. Lab when you're about to lose in an attempt to stall and disable their army. Maybe give you a little more fight before giving in. On the other hand, I worry about people going on the offensive with convecs loaded up with highly explosive buildings. If I could, I very well would charge with loads of Tokamaks, Adv. Labs, and Spaceports. As it stands now, the best you can do is starflare them yourself right when you start building them. It doesn't seem to be very cost effective however.
 
« Last Edit: December 29, 2006, 01:44:43 AM by Hooman »

Offline instigator

  • Jr. Member
  • **
  • Posts: 89
Things We Would Do Differently
« Reply #5 on: December 29, 2006, 06:40:15 PM »
Perhaps the self destruct sequence has a timer... or you have to "reasearch it" for the building. Perhaps it takes one scientist and a worker to outfit the building for destruction. Timer done? Building explodes. (no loss of population) This way convecs would not be moble bombs if they had structures in them. The destruction sequence has to be added from qualified technicians ;).

I would make the scouts much more usefull in the game. scout out an enemy smelter? it should return how much common ore the enemy has in stock. find enemy labs? it should return what is being researched or something that has been recently completed. something else i would change:

1. Scouts speed should be doubled (so that it can get in and out of bases quickly). To achevie this greater speed less materials will be used to construct scouts. Perhaps an introduction to 'lighter' rare metals research. The reason I say that the vehicle must be lighter in construction is not only to go faster, but to prevent rushes from a suicide attack of 20 scouts! I personally leveled a mining operation with such a strategy :whistle:. So if scouts have 2x the speed, then self destruct should cause minimal damage, if any.

2. If the idea of faster scouts isnt possible (i think it is) then i would add a "stealth" feature to scout instead. without crazy speed, the vech has to have a way of getting near a base undetected, even in broad daylight. Simply put, i want the scout to not show up on enemy mini-maps in the form of blips. I know this is possible because in total darkness an army of lynx (whose lights are off) can do a sneak attack on someone, undetected by the minimap. if this isnt possible then... cheat. make a square of "fog of war" hover over the scout, to indicate cloaking. Just the fact that it is in darkness, hides it from radar. That way one wouldnt have to write new code to get the scout "cloaked." It seems simpler to me to have a procedure that adds darkness when the scout activates its cloak, than it would be to program a whole new chunk of code. (lights off button of the scout changed to cloak perhaps)

Ok i'm done with that idea. I just realized that this thread is more into the design of op2... not what op2 does... oops

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Things We Would Do Differently
« Reply #6 on: December 30, 2006, 12:57:08 AM »
Quote
Ok i'm done with that idea. I just realized that this thread is more into the design of op2... not what op2 does... oops

Lol. Yeah, I was just thiking of commenting on that.

I think you're right though. Scouts do need to be a little more useful. Although, I thought they did tell about current research. Anyways, the thing that annoyed me most about scouts was you had to move them to get an update. I think it'd be nice to be able to click on an enemy building and see what's going on if you've got a scout nearby. It should also make giving displays for each building a little easier. Just use the default display, but don't offer any command options. Mind you, I don't mind getting a status report sent in. You know, your scout transmits the data just as it's being blown up. The stuff movies are made of!  :P Perhaps this can be done with a seperate display. Instead of your own colony status, or message log, you can have a display for the last know status of the other colony. Maybe just attach a time mark to each value so you know how current it is.

I was also thinking maybe there could be a non combat related use for scouts. Maybe combine them with the robo surveyors? They're both essentially just scout units. One scouts out resources, the other scouts for enemies. I don't see a huge difference here. It would give you something to do with the surveyors once you've surveyed all the resources on a map, or lauched a satellite (why do these scan mineral deposits deep underground anyways?) Although, it would still be nice to have a continual non combat use for them, so you can do a little more than send them in as sacrifices.

 

Offline Tellaris

  • Sr. Member
  • ****
  • Posts: 460
Things We Would Do Differently
« Reply #7 on: February 02, 2007, 11:02:12 PM »
ooo!   I love extracting bits and pieces from the OP2 Novella!!!

CH 12.
Emma stared at the big Council Chamber screen without believing what she was seeing.  In recent minutes, the clouds had moved in to almost completely cover Eden, hiding the battle from them.  But now those clouds were illuminated from below by a series of flashes, going off like a string of firecrackers in an old vid.
At first Emma thought she was seeing lightning, or weapons fire, but the flashes were too bright, too large, too regular, and she knew that it could only be the explosions from buildings self-destructing.
Emma half stood, reaching out for the screen as though she could somehow stop what was happening.  Van Dozier's destroying her own colony rather than lose it to the rebels.  Beneath a shroud of clouds, she watched Eden die.

Aaannnddd....

CH 6 (Fallout)
Then the column of Eden combat units appeared out of the dust.  There was a deafening bang, and the Scout lurched from a glancing blow.
The Scout swerved and slowed, using the Cargo Truck itself as a shield, but the enemy could simply fall back and hit them from behind.  They had seconds, no more.
The Scout swerved again, started heading directly toward an Eden Laser Lynx.  Its turret swung toward them and locked on.
Then Scout Two shot out of the blowing sand and crashed into the side of the Lynx, its cab crumpling flat against the armored unit.
Her eyes went wide.  "Wu!" The Scout's self-destruct mechanism fired, its volt banks shorting and discharging their energy in one explosive burst.  The Lynx was swallowed in a cloud of debris, and then they were past it, headed out on what seemed a random vector away from the truck.
Spell Checker!   The PoWeR tOoL
Click Here For Coolness
Self Proclaimed OPU Help desk.

Offline 7842303

  • Jr. Member
  • **
  • Posts: 81
Things We Would Do Differently
« Reply #8 on: October 14, 2007, 01:58:13 AM »
more units for multiplayer  
and a level were everyone only has one lynx, but 100000000000000000000000 bazzilion 1 hp tigers
onword to battle!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
unless your tired, of cource

Offline Marukasu

  • Full Member
  • ***
  • Posts: 110
Things We Would Do Differently
« Reply #9 on: November 16, 2007, 01:00:50 PM »
I realy do think that there should be a complete rework of weapon ranges, fire rates and weapon damages.
Because it really makes no sense that in such a thin atmosphere laser-microwaves would loose that much power that rapidly.
Im actualy currently working on balancing such modifications with op2's vol files.
« Last Edit: November 16, 2007, 01:01:48 PM by Marukasu »

Offline Hidiot

  • Hero Member
  • *****
  • Posts: 1018
Things We Would Do Differently
« Reply #10 on: November 16, 2007, 01:12:20 PM »
the VOL files contain texts with that info.
"Nothing from nowhere, I'm no one at all"

Offline Sirbomber

  • Hero Member
  • *****
  • Posts: 3238
Things We Would Do Differently
« Reply #11 on: November 16, 2007, 02:00:48 PM »
Quote
I realy do think that there should be a complete rework of weapon ranges, fire rates and weapon damages.
Because it really makes no sense that in such a thin atmosphere laser-microwaves would loose that much power that rapidly.
Im actualy currently working on balancing such modifications with op2's vol files.
Many people have tried that before, and nobody really liked their changes, so don't waste your time.

Edit: And it would be easier to just make your own techtree. That way you wouldn't need to mess around with mods and/or multiple copies of OP2.
« Last Edit: November 16, 2007, 02:01:30 PM by Sirbomber »
"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