Pages: [1] 2 3 4
|
|
|
Author
|
Topic: UQM stars/races relocation mod? (Read 17958 times)
|
logarithm
Zebranky food
Offline
Gender:
Posts: 32
|
Hi
I was wondering if there's any mod for classic SC UQM which would change locations of stars, locations of different races, maybe even change galaxy size... As it's a bit spoilerish, when u remember all key locations.
If there's no such mod, then is it hard to make such? I might consider to dive into such effort, if it's not too complicated.
|
|
« Last Edit: November 01, 2015, 09:47:22 pm by logarithm »
|
Logged
|
|
|
|
logarithm
Zebranky food
Offline
Gender:
Posts: 32
|
Ok. Checked code and made a brief plot.
Seems like will need to do followings:
(1) Randomize coordinates for stars and quasispace portals ** src/uqm/plandata.c ** src/uqm/hyper.h
(2) Find where races territories are defined - corellate them with randomization in (1). ** src/uqm/gameev.c -- found some coordinates for some events => better extract them as constants ** src/uqm/ships/${RACE}/${RACE}.c -- territories of races are most probably defined in FLEET_STUFF sections
(3) Apparently some coordinates and system names are hardcoded in conversations => extract them as constants and corellate with randomization in (1)
*.h files: sc2/src/uqm/hyper.h (30 hits) Line 36: #define ARILOU_SPACE_X 438 Line 37: #define ARILOU_SPACE_Y 6372 Line 40: #define QUASI_SPACE_X 5000 Line 41: #define QUASI_SPACE_Y 5000 Line 51: {4091, 7748}, \ Line 52: {3184, 4906}, \ Line 53: {9211, 6104}, \ Line 54: {5673, 1207}, \ Line 55: {1910, 926}, \ Line 56: {8607, 151}, \ Line 57: { 50, 1647}, \ Line 58: {6117, 4131}, \ Line 59: {5658, 9712}, \ Line 60: {2302, 3988}, \ Line 61: { 112, 9409}, \ Line 62: {7752, 8906}, \ Line 63: { 368, 6332}, \ Line 64: {9735, 3153}, \ Line 65: {5850, 6213}, \ Line 70: #define SOL_X 1752 Line 71: #define SOL_Y 1450 *.c files: sc2/src/uqm/comm/slyland/slyland.c (3 hits) Line 383: // Probe's coordinate system is {-Y,X} relative to B Corvi Line 384: dx = LOGX_TO_UNIVERSE (GLOBAL_SIS (log_x)) - 333; Line 385: dy = 9812 - LOGY_TO_UNIVERSE (GLOBAL_SIS (log_y)); sc2/src/uqm/gameev.c (37 hits) Line 308: || (PkunkPtr->loc.x == 4970 Line 309: && PkunkPtr->loc.y == 400)) Line 311: else if (PkunkPtr->loc.x == 502 Line 312: && PkunkPtr->loc.y == 401 Line 334: x = 4970; Line 335: y = 400; Line 339: x = 502; Line 340: y = 401; Line 375: x = 4879; Line 376: y = 7201; Line 380: x = 2535; Line 381: y = 8358; Line 530: ux = 7208; Line 531: uy = 7000; Line 533: sx = 6479; Line 534: sy = 7541; Line 538: ux = 8534; Line 539: uy = 8797; Line 541: sx = 7468; Line 542: sy = 9246; Line 721: if (IlwrathPtr->loc.x == ((2500 + 2535) >> 1) Line 722: && IlwrathPtr->loc.y == ((8070 + 8358) >> 1)) Line 732: && (IlwrathPtr->dest_loc.x != 2500 Line 733: || IlwrathPtr->dest_loc.y != 8070)) Line 735: SetRaceDest (ILWRATH_SHIP, 2500, 8070, 90, Line 752: (2500 + 2535) >> 1, (8070 + 8358) >> 1, Line 769: (2500 + 2535) >> 1, (8070 + 8358) >> 1, Line 774: SetRaceDest (THRADDASH_SHIP, 2535, 8358, 10, Line 803: SetRaceDest (MYCON_SHIP, 6392, 2200, 30, (BYTE)~0); Line 808: else if (MyconPtr->loc.x != 6858 || MyconPtr->loc.y != 577) Line 852: RebelPtr->loc.x = 5150; Line 853: RebelPtr->loc.y = 0; sc2/src/uqm/planets/generate/genpet.c (2 hits) Line 223: EncounterPtr->loc_pt.x = 5288; Line 224: EncounterPtr->loc_pt.y = 4892; sc2/src/uqm/ships/arilou/arilou.c (1 hit) Line 63: 438, 6372, sc2/src/uqm/ships/blackurq/blackurq.c (3 hits) Line 84: 6000, 6250, sc2/src/uqm/ships/druuge/druuge.c (3 hits) Line 67: 9500, 2792, sc2/src/uqm/ships/human/human.c (2 hits) Line 73: 1752, 1450, sc2/src/uqm/ships/ilwrath/ilwrath.c (2 hits) Line 71: 48, 1700, sc2/src/uqm/ships/mycon/mycon.c (3 hits) Line 68: 6392, 2200, sc2/src/uqm/ships/orz/orz.c (6 hits) Line 80: 3608, 2637, sc2/src/uqm/ships/slylandr/slylandr.c (1 hit) Line 67: 333, 9812, sc2/src/uqm/ships/spathi/spathi.c (3 hits) Line 73: 2549, 3600, sc2/src/uqm/ships/supox/supox.c (2 hits) Line 68: 7468, 9246, sc2/src/uqm/ships/thradd/thradd.c (2 hits) Line 78: 2535, 8358, sc2/src/uqm/ships/umgah/umgah.c (2 hits) Line 67: 1798, 6000, sc2/src/uqm/ships/urquan/urquan.c (3 hits) Line 77: 5750, 6000, sc2/src/uqm/ships/utwig/utwig.c (2 hits) Line 73: 8534, 8797, sc2/src/uqm/ships/vux/vux.c (2 hits) Line 80: 4412, 1558, sc2/src/uqm/ships/yehat/yehat.c (1 hit) Line 68: 4970, 40, sc2/src/uqm/ships/zoqfot/zoqfot.c (2 hits) Line 75: 3761, 5333, sc2/src/uqm/plandata.c (alot of hits) ...
*.txt files (for dialogues): sc2/content/addons/3dovoice/arilou/arilou.txt Line 496: seek the Arilou in QuasiSpace. You can make the transit at 43.8 : 637.2 sc2/content/addons/3dovoice/melnorme/melnorme.txt Line 753: In case you are interested, the Zoq-Fot-Pik homeworld is at coordinates 400.0:543.7, planet I. sc2/content/addons/3dovoice/starbase/starbase.txt Line 718: at approximate TrueSpace coordinate 100:50. sc2/content/addons/3dovoice/utwig/utwig.txt Line 306: (at coordinates 850.3, 937.2) sc2/content/base/comm/ilwrath/ilwrath.txt Line 299: Look In The Heavens At Location 022.9, 366.6 sc2/content/base/comm/melnorme/melnorme.txt Line 769: In case you are interested, the Zoq-Fot-Pik homeworld is at coordinates 400.0:543.7, planet I. sc2/content/base/comm/mycon/mycon.txt Line 274: The source of Juffo-Wup is at 629.1, 220.8. Line 341: Juffo-Wup springs forth from 629.1, 220.8. sc2/content/base/comm/orz/orz.txt Line 89: The *Playground* is 372.1, 261.9 your *silly* numbers. Line 564: It is 371.3, 253.7 location. sc2/content/base/comm/spathi/spathi.txt Line 5: The coordinates of my homeworld, Spathiwa, are 241.6, 368.7 Line 120: Spathiwa is the 1st planet out from the star at HyperSpace (570.4, 979.5) sc2/content/base/comm/yehat/yehat.txt Line 185: But the strangest world we found was the first planet at the star at coordinates 639.5 : 231.2. sc2/content/base/comm/zoqfotpik/zoqfotpik.txt Line 32: Coordinates 400.0 : 543.7.
Count of stars: sc2/src/uqm/starmap.h, line 30: #define NUM_SOLAR_SYSTEMS 502 Stars and star-clusters names: sc2/content/basegamestrings.txt (check sc2/src/uqm/gamestr.h for metadata) Their reference in dialogues would require additional search.
|
|
« Last Edit: November 01, 2015, 12:32:30 pm by logarithm »
|
Logged
|
|
|
|
|
logarithm
Zebranky food
Offline
Gender:
Posts: 32
|
There are hardcoded assumptions made towards generated systems and planets (if those assumptions fail, game generation is faulty). Currently there are these hardcoded assumptions towards generated galaxy: (A) About stars coordinates (B) About quasispace portal coordinates (C) About names of stars and clusters (D) About gameplay-important stars - their numbers of planets, moons (E) About gameplay-important stars - anything else assumed? (F) About races coordinates (G) About races strength (H) About events when races move and/or attack other races (I) About distances between races (based on their relationships) (J) About distances between races and related artifacts/ships and other objects (K) It's quite important to figure out what else is assumed
Apparently, mod will target changing (A), (B), probably (C) and definitely (F). And will need to respect and be cautious with (D), (E), (H), (I), (J). Clarifications required for (E), (I), (J) and (K).
I assume (G) and (H) are strictly hardcoded in events. And thus, if Pkunks whole fleet decide to travel through Kohr-Ah territory, they won't fight and weaken each other. However, I will need to check distances and speeds at which whole-fleets travel. Although it's (most probably) only of a cosmetical priority...
Few possible approaches to deal with (D) and (E) vary in elegancy/dirtiness, simplicity/complexity. Have to choose from these: (1) Respect every assummed generated parameter/state. Put defensive constructs and workarounds near each assumption in code. (2) Generate whole galaxy using original seed and content. Then remove all nonimportant stars, relocate important stars, and regenerate all nonimportant stars randomly. (3) Extract random seed state for all important stars, and hardcode usage of such random seed state near assumptions. (4) Same as (3), but also use separate random generators for important and nonimportant stars. (5) Import data for important stars using dumps.
Option (1) is probably the most correct one - as I would better identify all risks. But this would also be most boring choice. Options (2), (3) and (4) look quite easy and safe for me. But they are vulgar. I like (5), but that looks also most complex for me, as it will require biggest changes in code, I think... I wonder if anyone tried to to make functions for importing stars from dumpfiles?
Another tasks which I'll need to solve (i) for (A) is evenness of random distribution of star-clusters and stars within them (ii) for (F) and (I) is evenness of random distribution of races (iii) after merging sets of important stars with nonimportant ones (also after enforcing respects of (I) and (J)) will need to take additionl cares for evenness of distribution of stars (iv) ensure that stars and quasi-space portals don't overlap (v) test if melnormes are fine with new coordinates of Rainbow Worlds
---------------------------------------- I hope experienced comunity members share their thoughts and knowledge (and probabably pieces of code) on things said. Especially on assumptions (E), (K) and on solution (5). If anyone is willing to participate - welcome! It would be great if someone defined (I) and (J) in complete details.
|
|
« Last Edit: November 01, 2015, 12:34:28 pm by logarithm »
|
Logged
|
|
|
|
kfdf
Zebranky food
Offline
Posts: 8
|
Some thoughts on the subject...
The game surely has some replayability potential in it, and not making everything fixed in place seems like the obvious way to realize it. But maybe you should start small, like, randomizing star colors and moving them just a tiny bit, so that their seed would change? This will keep all those hand crafted nice looking constellations while changing their planets. And coupled with some additional adjustments you can actually fix some important game imbalances.
For instance, you could reduce chances of finding life in subzero temperatures, which in turn would make buying Melnorme technologies much harder, which would greatly delay the moment your flagship becomes virtually unstoppable death dealer capable of taking on Ur-Quan battlegroups single-handedly, which would introduce you into ship management where you actually lose ships in combat and have to buy them...
And while I am at it, you could decrease the number of enemy ships that pop out in hyperspace and in normal space, but at the same time massively increase their speed. This will result in enemy ships catching up to you when you leave planet orbit and enter space, then deep space and then hyperspace. So you won't be able to explore planets in enemy space so light heartedly as you can do it today. I played the game some time ago and the only thing that I remembered at the beginning of the game was a bunch of mineral rich stars to the left of your starting position (or you can actually listen carefully to what Hayes says about star colors). And that was enough to break the early game in many ways. Why? These stars are in Ilwrath space, who are very dangerous enemies in combat, but aren't really a threat because they can be easily avoided. So instead of meticulously gathering minerals and building your fortune bit by bit, you just go there and grab some easy money. Making their speed in truespace and hyperspace independent of their combat speed would fix this problem.
As to moving around races, this sounds like a massively daunting task, there are too many invariants set in the dialogs and in the game lore that must be kept for this to make sense. You have to pick the spot for the battleground where the the two races fight for Sa-Matra, you have to decide which way is the center of the galaxy, where the Ur-Quan and Kohr-Ah fleets came from, where the Alliance of Free Stars was, and that roughly defines where most of the races and special places should fit. With all this, I don't think you can really have much variety here, the end result will always end up looking something like the current fixed map, only mirrored and/or rotated. And I'm afraid to think of what it will to take the rest of the code to reliably work with the generated map. You have to guarantee that a crash or a softlock won't happen because the generated map violated some implicit assumption made by the rest of the code about the map. And even if you manage to do all this, there will be very little actual gain from the gameplay perspective, there are not too many races and they are quite easy to find, and when you find a few of them you can visually pinpoint where the rest of them are.
But what IS hard to find and what greatly affects mid-to-late game are certain special objects. Right now it is really tempting to say when you are still relatively early into the game: "ok, this much fuel should be enough, off to Alpha Pavonis, and I'll drop by Beta Corvi while I am at it." And that's really game breaking, isn't it? The mid-to-late game is about looking for information on where you can find some stuff and if you can just go and grab it right away it ruins the game a bit. So you can go through these important objects, one by one, decide if it really make sense to move around this object, if yes figure out where the object can go (like VUX beast can go to any of the 8 stars in the constellation, the taalo shield must be somewhere around Orz space, the Crashed Dreadnought can appear anywhere on the map, it doesn't have to be somewhere near the Arilou space, those guys can go anywhere they want) then place it and adjust the relevant dialogs appropriately.
Overall, I think that you can improve the game, especially it's replay value, by doing one small thing at a time, first picking some low hanging fruits then moving to something more complex. I haven't really looked at the codebase, but something tells me that it's easier to write a remake (and in a higher level language, like c# or java) from scratch than introduce big changes into the game.
|
|
|
Logged
|
|
|
|
CelticMinstrel
Enlightened
Offline
Posts: 522
|
And while I am at it, you could decrease the number of enemy ships that pop out in hyperspace and in normal space, but at the same time massively increase their speed. This will result in enemy ships catching up to you when you leave planet orbit and enter space, then deep space and then hyperspace. [...snip...] Making their speed in truespace and hyperspace independent of their combat speed would fix this problem. Your flagship's truespace and combat speeds are related. To make this not true of your enemies would make it seem like they are cheating. I'm not quite sure about hyperspace speed; do enemy speeds vary at all in hyperspace? I'm pretty sure the flagship's speed does vary, though.
As to moving around races, this sounds like a massively daunting task, there are too many invariants set in the dialogs and in the game lore that must be kept for this to make sense. You have to pick the spot for the battleground where the the two races fight for Sa-Matra, you have to decide which way is the center of the galaxy, where the Ur-Quan and Kohr-Ah fleets came from, where the Alliance of Free Stars was, and that roughly defines where most of the races and special places should fit. With all this, I don't think you can really have much variety here, the end result will always end up looking something like the current fixed map, only mirrored and/or rotated. And I'm afraid to think of what it will to take the rest of the code to reliably work with the generated map. You have to guarantee that a crash or a softlock won't happen because the generated map violated some implicit assumption made by the rest of the code about the map. And even if you manage to do all this, there will be very little actual gain from the gameplay perspective, there are not too many races and they are quite easy to find, and when you find a few of them you can visually pinpoint where the rest of them are. Basically I would say you shouldn't move any race's sphere of influence. You could however change the homeworld or other important locations to be some other planet within the sphere of influence, at least for the new races that didn't appear in SC1.
the taalo shield must be somewhere around Orz space, It should be in the Vulpeculae constellation, probably, and it shouldn't be in the Androsynth system. Also, if I recall correctly, it's supposed to be a moon. That doesn't leave a lot of options.
the Crashed Dreadnought can appear anywhere on the map, it doesn't have to be somewhere near the Arilou space, those guys can go anywhere they want) The crashed dreadnought can't go literally anywhere. It must be placed somewhere out of the way, which means it shouldn't be in any sphere of influence (including the Ilwrath's original SoI that appears on the paper starmap which was included with the game). This also means it shouldn't be in Sirius or the Centauri constellation, as those are too close to Earth.
Moving important objects like that is probably a lot harder than you think. The dialog is currently hardcoded with numerous assumptions on the locations of important items, meaning that if they can move you would need some way of dynamically altering the dialogue to fit. It's not just a matter of changing numerical coordinates.
|
|
|
Logged
|
|
|
|
kfdf
Zebranky food
Offline
Posts: 8
|
Your flagship's truespace and combat speeds are related. To make this not true of your enemies would make it seem like they are cheating. I'm not quite sure about hyperspace speed; do enemy speeds vary at all in hyperspace? I'm pretty sure the flagship's speed does vary, though. Of course enemy speeds vary in hyperspace. Slylandro probes are barely slower than the Flagship with all thrusters, no one else comes close to that. And "cheating" is the usual way to balance out AI's stupidity, who doesn't "lead" the target, who enters planet's near space instead of waiting for the player in deep space, who can't catch up with the player in hyperspace while he is exploring a star system because all entities in hyperspace freeze during that time. The "proper" way would be to fix all those issues, but just boosting their speed seems to be the most simple option.
It should be in the Vulpeculae constellation, probably, and it shouldn't be in the Androsynth system. Also, if I recall correctly, it's supposed to be a moon. That doesn't leave a lot of options. The crashed dreadnought can't go literally anywhere. It must be placed somewhere out of the way, which means it shouldn't be in any sphere of influence (including the Ilwrath's original SoI that appears on the paper starmap which was included with the game). This also means it shouldn't be in Sirius or the Centauri constellation, as those are too close to Earth. Is all of that is said in some dialogs? I don't remember the "out of the way" part. Regardless, deciding where each item can go should be decided on a case by case basis and even there are only a few possible spots, that's enough to keep honest people honest.
|
|
|
Logged
|
|
|
|
kfdf
Zebranky food
Offline
Posts: 8
|
Moving important objects like that is probably a lot harder than you think. The dialog is currently hardcoded with numerous assumptions on the locations of important items, meaning that if they can move you would need some way of dynamically altering the dialogue to fit. It's not just a matter of changing numerical coordinates. I poked around the code a bit (good lord, I certainly can't into Git or plain C, all I can do is to monkey my way around with GoToDefinition and FindAllReferences) and for instance in NPCPhrase_cb function in commglue.c you get a pointer to chars constituting the phrase, index of the the phrase, and I'm sure that you can figure out which alien the phrase belongs to from CommData. The pointer is writable as done in DISABLE_PHRASE macro which simply writes terminating null at the start. All of that seems to be enough to at least overwrite the existing phrases. Doing it here is an ugly kludge and not being able to reallocate the phrase is a serious limitation, but it's a start, and I'm pretty sure this can be easily overcome with some dedication and time. Of course there is no real way to fix the voiceovers.
PS Just noticed, judging by the forums Star Control 2 seems to be deader than dead, but several dozens people seem to download it every day, and that's three years after the latest release. They could be downloading a much better game... this game needs you, logarithm.
|
|
« Last Edit: November 03, 2015, 09:12:30 am by kfdf »
|
Logged
|
|
|
|
logarithm
Zebranky food
Offline
Gender:
Posts: 32
|
I'm not yet sure, but if this function below (from solarsys.c) is all it takes to determine star planetary content, then i'll just fake the seed for important stars. In any case I'll keep original contents inside important stars.
DWORD GetRandomSeedForStar (const STAR_DESC *star) { return MAKE_DWORD (star->star_pt.x, star->star_pt.y); } I'll be working on this mod on weekends. So, not much progress on working days.
----------------------------------
Thanks for comments guys.
But maybe you should start small, like, randomizing star colors and moving them just a tiny bit, so that their seed would change? Yeah, I actually plan to do small steps, and stick to KIS principle. One of mistakes Nicholai did was putting alot of different unrelated stuff under one mod - which is antipattern, and a common mistake for unexperienced developers. Although I like the ideas you mentioned about poor balance, I'll leave it to another mod, - but this mod will be totally about relocation. I hope I'll do it (the better-balance-mod) later, and for this reason I ask you to open disscussion about it's probable content in different topic.
As to moving around races, this sounds like a massively daunting task, there are too many invariants set in the dialogs and in the game lore that must be kept for this to make sense. You have to pick the spot for the battleground where the the two races fight for Sa-Matra, you have to decide which way is the center of the galaxy, where the Ur-Quan and Kohr-Ah fleets came from, where the Alliance of Free Stars was, and that roughly defines where most of the races and special places should fit. With all this, I don't think you can really have much variety here, the end result will always end up looking something like the current fixed map, only mirrored and/or rotated. And I'm afraid to think of what it will to take the rest of the code to reliably work with the generated map. You have to guarantee that a crash or a softlock won't happen because the generated map violated some implicit assumption made by the rest of the code about the map. And even if you manage to do all this, there will be very little actual gain from the gameplay perspective, there are not too many races and they are quite easy to find, and when you find a few of them you can visually pinpoint where the rest of them are. Basically I would say you shouldn't move any race's sphere of influence. You could however change the homeworld or other important locations to be some other planet within the sphere of influence, at least for the new races that didn't appear in SC1. Actually, I plan to move them. I know this makes relocation quite complex algorithm, but that's the way I really wanted it from beginning. The algorithm which would respect clusters too. I want to start game in completely unexplored cosmos. And I think I'm a capable programmer for such task.
// postfix name index (like 'Normae') // prefix name index (like 'Alpha') | // alien presence | | // owner (unused) | | | // x, y star type colour | | | | {{2908, 269}, MAKE_STAR (DWARF_STAR, BLUE_BODY, -1), SHOFIXTI_DEFINED, 4, 82}, {{4923, 294}, MAKE_STAR (DWARF_STAR, YELLOW_BODY, -1), YEHAT_DEFINED, 3, 74}, {{ 522, 525}, MAKE_STAR (DWARF_STAR, YELLOW_BODY, -1), PKUNK_DEFINED, 3, 92}, {{6858, 577}, MAKE_STAR (DWARF_STAR, GREEN_BODY, -1), MYCON_TRAP_DEFINED, 0, 123}, {{1752, 1450}, MAKE_STAR (DWARF_STAR, YELLOW_BODY, -1), SOL_DEFINED, 0, 129}, {{4333, 1687}, MAKE_STAR (DWARF_STAR, ORANGE_BODY, -1), VUX_DEFINED, 2, 88}, {{3345, 1931}, MAKE_STAR (DWARF_STAR, YELLOW_BODY, -1), START_COLONY_DEFINED, 0, 98}, {{4221, 1986}, MAKE_STAR (DWARF_STAR, BLUE_BODY, -1), MAIDENS_DEFINED, 1, 100}, {{6479, 2062}, MAKE_STAR (DWARF_STAR, GREEN_BODY, -1), EGG_CASE1_DEFINED, 3, 71}, {{2104, 2083}, MAKE_STAR (DWARF_STAR, ORANGE_BODY, -1), ZOQ_SCOUT_DEFINED, 0, 118}, {{6291, 2208}, MAKE_STAR (DWARF_STAR, GREEN_BODY, -1), MYCON_DEFINED, 5, 71}, {{ 742, 2268}, MAKE_STAR (DWARF_STAR, ORANGE_BODY, -1), CHMMR_DEFINED, 0, 117}, {{6395, 2312}, MAKE_STAR (DWARF_STAR, GREEN_BODY, -1), SUN_DEVICE_DEFINED, 2, 12}, {{3713, 2537}, MAKE_STAR (DWARF_STAR, GREEN_BODY, -1), ORZ_DEFINED, 3, 86}, {{3587, 2566}, MAKE_STAR (DWARF_STAR, GREEN_BODY, -1), ANDROSYNTH_DEFINED, 7, 86}, {{3721, 2619}, MAKE_STAR (DWARF_STAR, GREEN_BODY, -1), TAALO_PROTECTOR_DEFINED, 4, 86}, {{6008, 2631}, MAKE_STAR (DWARF_STAR, YELLOW_BODY, -1), EGG_CASE0_DEFINED, 2, 14}, {{6354, 2729}, MAKE_STAR (DWARF_STAR, WHITE_BODY, -1), EGG_CASE2_DEFINED, 3, 12}, {{9469, 2806}, MAKE_STAR (DWARF_STAR, ORANGE_BODY, -1), DRUUGE_DEFINED, 6, 61}, {{ 229, 3666}, MAKE_STAR (DWARF_STAR, GREEN_BODY, -1), ILWRATH_DEFINED, 1, 76}, {{2416, 3687}, MAKE_STAR (GIANT_STAR, ORANGE_BODY, -1), SPATHI_DEFINED, 5, 109}, {{4125, 3770}, MAKE_STAR (DWARF_STAR, BLUE_BODY, -1), SYREEN_DEFINED, 0, 114}, {{5937, 3937}, MAKE_STAR (DWARF_STAR, ORANGE_BODY, -1), SHIP_VAULT_DEFINED, 5, 10}, {{4000, 5437}, MAKE_STAR (DWARF_STAR, GREEN_BODY, -1), ZOQFOT_DEFINED, 1, 18}, {{9645, 5791}, MAKE_STAR (DWARF_STAR, ORANGE_BODY, -1), BURVIXESE_DEFINED, 0, 130}, {{6200, 5935}, MAKE_STAR (DWARF_STAR, YELLOW_BODY, -1), SAMATRA_DEFINED, 4, 21}, {{1978, 5968}, MAKE_STAR (DWARF_STAR, GREEN_BODY, -1), TALKING_PET_DEFINED, 2, 54}, {{ 562, 8000}, MAKE_STAR (GIANT_STAR, GREEN_BODY, -1), URQUAN_WRECK_DEFINED, 1, 59}, {{2535, 8358}, MAKE_STAR (DWARF_STAR, YELLOW_BODY, -1), THRADD_DEFINED, 4, 53}, {{2776, 8673}, MAKE_STAR (DWARF_STAR, ORANGE_BODY, -1), AQUA_HELIX_DEFINED, 6, 53}, {{8630, 8693}, MAKE_STAR (DWARF_STAR, GREEN_BODY, -1), UTWIG_DEFINED, 2, 3}, {{7414, 9124}, MAKE_STAR (DWARF_STAR, GREEN_BODY, -1), SUPOX_DEFINED, 2, 47}, {{8500, 9372}, MAKE_STAR (DWARF_STAR, YELLOW_BODY, -1), BOMB_DEFINED, 6, 45}, {{5704, 9795}, MAKE_STAR (DWARF_STAR, YELLOW_BODY, -1), VUX_BEAST_DEFINED, 4, 49}, {{ 333, 9812}, MAKE_STAR (DWARF_STAR, GREEN_BODY, -1), SLYLANDRO_DEFINED, 2, 27}, 35 special stars, which is <10% of all. If we imagine it as a graph (where nodes are stars, and links - distance assumptions), then it would be a set of weakly connected sub-graphs. I bet it won't contain more than 50 assumptions. And since I'll have to extract all coordinates and star names (read below about this) out of dialogues - this will help me also to define most (but not all) of those assumptions. What I need is to define the rest of assumptions, - and your sentences about "taalo shield" and "Crashed Dreadnought" and similar stuff could actually help me doing that. Once I have such graph defined, I'll simply have to apply some graph layouting algorithm with randomization. Next draw cluster areas. And finally fill clusters (and non-clustered space) with 465 non-important stars.
Moving important objects like that is probably a lot harder than you think. The dialog is currently hardcoded with numerous assumptions on the locations of important items, meaning that if they can move you would need some way of dynamically altering the dialogue to fit. It's not just a matter of changing numerical coordinates.
Good point. I was thinking about that too. I still haven't decided how to deal with that, but most probably I'll make use of script, which finds all usages of star/cluster names in all dialogues. Not hard to do so. And I think I'll find 10-20 usages. I will already have to extract coordinates out of dialogues, so extracting star-names after that won't be hard. Once I extract star-names, I have a really nasty idea to change (randomize) names of important stars too....
You have to pick the spot for the battleground where the the two races fight for Sa-Matra, you have to decide which way is the center of the galaxy, where the Ur-Quan and Kohr-Ah fleets came from, where the Alliance of Free Stars was, and that roughly defines where most of the races and special places should fit. With all this, I don't think you can really have much variety here, the end result will always end up looking something like the current fixed map, only mirrored and/or rotated.
Why not breaking huge Ur-Quan and Kohr-Ah fleets into 3 smaller circles?.. This would give a better potential for randomization. Also, Sa-Matra don't have to be in the middle of galaxy I think (if that's the price for better randomization).
And I'm afraid to think of what it will to take the rest of the code to reliably work with the generated map. You have to guarantee that a crash or a softlock won't happen because the generated map violated some implicit assumption made by the rest of the code about the map.
Yeah, this is quite an important point. But so far I haven't identified any other assumptions apart from ones listed in the second post (considering, that I'll leave important stars contents original). I'll keep an eye on this, tho. If anyone spots any suspicious please call 911 tell it here.
|
|
« Last Edit: November 03, 2015, 10:39:40 pm by logarithm »
|
Logged
|
|
|
|
kfdf
Zebranky food
Offline
Posts: 8
|
Actually, I plan to move them. I know this makes relocation quite complex algorithm, but that's the way I really wanted it from beginning. Ok, in this case planet randomization will be just a minor side effect of what you are trying to achieve. Hopefully, your project won't get buried under its own ambitions.
I want to start game in completely unexplored cosmos. But that's against the lore! Remember there was Star Control 1! And there is Commander "Spoilers Galore" Hayes who can tell you much about it. So much, in fact, that this will nullify all your efforts of putting the player in unexplored space, who will be able to map most of the races even before he leaves the Solar system.
So, I think you'll have to simply ditch the Lore, cut out or adjust a lot of info from dialogs that restrict the possible layout of the map. You can even forego the idea that there are two regions separated by the coreward front where the old alliance fought the hierarchy, you can make it look like the modern wars without clear and definite front lines, so that anyone can go almost anywhere.
Why not breaking huge Ur-Quan and Kohr-Ah fleets into 3 smaller circles?. That's actually would be quite surprising. But something tells me that there are very strong assumptions in the code that every race has only one sphere of influence, so you'll have to introduce two pairs of dummy races in the game, synchronize their dialogs etc. etc. Not saying that's impossible, but certainly not very high on the priority list. Actually, the same can be said about layout algorithms, dialog patching, lore consistency and such. If your core idea is to randomize everything as much as you can, just go for it then and push it as far as you can. Try to rewrite item placement algorithms for special worlds, so that you could randomize them too, get rid of the hardcoded stuff (there seems to be lots and lots of it, why only 465 stars? I want 565..), make the game accept whatever nonsensical map you can throw at it and not blow up your computer. This surely doesn't sound like a small first step, but it will be an important proof of concept.
|
|
|
Logged
|
|
|
|
|
rootxploit
Zebranky food
Offline
Posts: 2
|
Your flagship's truespace and combat speeds are related Though I agree with this from a world-building perspective it is not difficult to change this in the game. It is kept in the RACE_HYPER_SPEED macro in races.h
something tells me that there are very strong assumptions in the code that every race has only one sphere of influence If you have any clue or idea of how such assumptions might look like, or where (in which logics) to look for them - please share. I'll put the check for such assumptions in early analysis TODO list. Each race is synonomous with a sphere of influence. The game will iterate through the race queue and load the RACE_DESC data structure for each race. In that data struct, for example, one is blackurq.c for the Kohr-ah it will definate a sphere of influence size. So to add another one you'd have to create a new race data struct inside a new file (e.g. blackurq2.c) change the sphere of influence and add it to the make file. I'd guess you'd also have to add it to the species_id data struct in races.h. If you do that and it segfaults you probably need to add entries to the rest of races.h.
I'm still getting a handle on the different places where races and ships are used myself. It is usually done via a mix of indexing and linked-list iteration in queues. I've made a spreadsheet to help me understand the relationships between each datastructure and that has helped somewhat.
|
|
|
Logged
|
|
|
|
CelticMinstrel
Enlightened
Offline
Posts: 522
|
Is all of that is said in some dialogs? I don't remember the "out of the way" part. Regardless, deciding where each item can go should be decided on a case by case basis and even there are only a few possible spots, that's enough to keep honest people honest.
The "out of the way" part is based on the assumption that a Dreadnought crashing within another race's sphere of influence is unlikely to go unnoticed. Since only the Arilou discovered it, it shouldn't be too close to other races where they would be likely to discover it first. This is never mentioned in dialogue as far as I recall.
Actually, I plan to move them. I know this makes relocation quite complex algorithm, but that's the way I really wanted it from beginning. The algorithm which would respect clusters too. I want to start game in completely unexplored cosmos. And I think I'm a capable programmer for such task.
The reason I suggested not moving the spheres of influence is because they're given on the paper starmap (for all the races). There are also assumptions in the story about relative positioning of the SoIs. For example, if the Ilwrath SoI is moved too far, it wouldn't make sense for them to have been assigned to watch Earth. The Zot-Foq-Pik need to be within the Ur-Quan SoI (at least partially), because in the story they have a unique insight into the conflict due to their proximity. The Utwig and Supox need to be near each other, because they're friends. The races from SC1 (except Arilou) all need to be arranged near each other, because they were drawn into the war in the first place because of their proximity. The VUX and Mycon need to be near each other due to the Syreen backstory - the Syreen world is a former Mycon planet, and they fled towards VUX space when the planet was captured. VUX and Yehat need to be near each other, because they have a history of hostilities (I think). Yehat and Shofixti need to be near each other, because the Yehat raised the Shofixti. Umgah and Spathi probably need to be near each other, since the Umgah seem to particularly enjoy pranking the Spathi, though this is a more flexible relationship than some of the others. Ilwrath need to be relatively close to Earth, as do the Spathi, because they were assigned to watch over it by the Ur-Quan. Pkunk needs to be somewhat close to Yehat, because the Pkunk are an offshoot. Pkunk also needs to overlap with the Ilwrath, because the Ilwrath are attacking them. The Druuge can't be moved much due to their interactions with the Utwig and the Arcturans (I think they had a race-name but can't remember it). If you can encode all these assumptions into your graph, then by all means, randomize the SoIs. Mirroring the galaxy on the coreward diagonal would probably be fine, though - ie, the Yehat, Vux, and Mycon go up near the left, with the Druuge right at the top left, and the Spathi, Umgah, and Thraddash arrayed along the bottom of the map. The Ilwrath, Pkunk, Utwig, and Supox wouldn't be affected much by this (though the Supox and Utwig would roughly swap positions).
Good point. I was thinking about that too. I still haven't decided how to deal with that, but most probably I'll make use of script, which finds all usages of star/cluster names in all dialogues. Not hard to do so. And I think I'll find 10-20 usages. I will already have to extract coordinates out of dialogues, so extracting star-names after that won't be hard. Once I extract star-names, I have a really nasty idea to change (randomize) names of important stars too.... There may be some more indirect references too. I'm not sure. The only way to be absolutely sure is to read through all the dialogue carefully. But maybe it's not worth it for just catching a few extra references.
Why not breaking huge Ur-Quan and Kohr-Ah fleets into 3 smaller circles?.. This would give a better potential for randomization. Also, Sa-Matra don't have to be in the middle of galaxy I think (if that's the price for better randomization). I suppose it could make sense for the Ur-Quan and Kohr-Ah to be split. The Sa-Matra does need to be in Ur-Quan and Kohr-Ah space, though. I think it wouldn't make much sense if it wasn't vaguely near the centre of the map, but the centre of the map is a large area.
|
|
|
Logged
|
|
|
|
logarithm
Zebranky food
Offline
Gender:
Posts: 32
|
rootxploit Thanks for thoughts on race fleet separation. I was seeng this in a similar way.
CelticMinstrel Great job on defining those distance assumptions. Althought assumptions for Druuges not clear. I don't remember many things from gameplay. And according to map, Yehat is quite far from Pkunk. Not sure if this is starting location or late location, - if i remember correctly, at some point their fleets got intersecting. According to code their (Yehat) fleet starting loc is 497.0, 4.0. But thanks anyway! In the end I want to have a specification for all those assumtions in a strict form, something like this:
... DIST ( {HOME_PKUNK, FLEET_CENTER_PKUNK }, NOT_APPLICABLE, MAX( 30.0) ); DIST ( {HOME_PKUNK, FLEET_EDGE_ILWRATH }, MIN( 20.0), MAX( 50.0) ); DIST ( {HOME_SOL FLEET_EDGE_PKUNK }, MIN( 50.0), MAX( 250.0) ); DIST ( {HOME_SOL, FLEET_EDGE_ILWRATH }, MIN( 10.0), MAX( 50.0) ); DIST ( {HOME_ILWRATH, FLEET_CENTER_ILWRATH}, NOT_APPLICABLE, MAX( 50.0) ); DIST ( {HOME_ILWRATH, FLEET_EDGE_PKUNK }, MIN( 10.0), NOT_APPLICABLE ); DIST ( {HOME_ORZ, ENERGY_TAALO }, MIN( 2.0), MAX( 30.0) ); ...
I can then keep them in separate file and load into game in relocation procedure. I'll start with the minimal specification - for the proof of graph layouting algorithm, and in the end we can use a full specification.
If anyone willing to start defining this specification - welcome! If anyone willing to participate, then I'll start publishing stuff into my GIT repo...
------------------------ So far I've managed to run a module, which randomizes all stars locations (keeping contents of important stars). Currently without complex logic of forming clusters, respecting distance assumptions and other stuff. It also writes all star relocations to dedicated log file - gonna need it later for testing.
Also managed to enable no-intro mode for faster debugging and learned to use debug key.
Next stage will be extraction of all hardcoded coordinates (and fleet sizes, and distances) to managable module. Bad news, is that it's gonna be hard to test them all. So probably I'll leave some of them them untested (risk should be quite low though). If anyone wants to help testing - welcome.
Meanwhile slowly approaching to the hardest challenge - graph layouting algorithm. Started reading some papers on that and tapping related communities.
|
|
« Last Edit: November 08, 2015, 08:03:23 am by logarithm »
|
Logged
|
|
|
|
|
Pages: [1] 2 3 4
|
|
|
|
|