|
Author
|
|
Topic: CUSTOMISATION: Co-Managed by Hugo Rune and kd5bjo |  |
|
Gordon the Whale
b.02-15-99
|
 |
posted July 16, 1999 18:57
   | 
 |
 |  |
I agree that a single "ocean" square should be avoided, and that flags should be used to decide where a unit can go. However, I would also like to not be limited as tho the number of terrain squares on a given map, or at least I would like to have this number increased. As I recall, there are currently 11 terrain types (did I forget something? Ocean, Plains, Grassland, Mountain, Hill, Arctic, Tundra, Jungle, Swamp, Forest, Desert)... This is not even a particular number of bits. Probably the map file is saving these numbers as bytes anyways... So there could be up to 256 withoput making the map files any bigger. This is more than anyone would ever use, I think, but it would be nice to have more than 11. Rather than changing the number in the actual game, I'd rather see customizers have the ability to actually add terain, rather than just changing it. In fact, I can say the same of most aspects, like Darkeagle... Especially available civilizations (discussed in depth in the relevant thread) units, wonders, advances, and city improvements. Instead of referring to these by indices, they should each have in their definitions a name that can be used to reference them. This would work ESPECIALLY well if there were, as Octopus suggested, an #include or similar command used to load libraries. Each library could consist of some units, civs, terrain squares, improvements, wonders, advances, scenario triggers(although these might go somewhere else), or even AI's (hint, hint) and could be used in tandem with other libraries, without running into problems with there being too many units in the game. Then, all that would be necessary in the main file would be lists of the actual units from each library, with All being an option, as in Use(Library(libraryname).Units(All)) or whatever. If there are two modes of scenario editing, this is of course, the more difficult, although I do have to say that if you're going to edit a game, you shoud probably be willing to just suck it up and mess with code... They should include a full reference to the code in a text file, and code the original rules, etc. into the executable, so you can always fix your errors. Then, if somebody wants to write a more user friendly freeware editor, they can, or Firaxis can do it later at their leisure. I see no reason they should have to add more than a map editor, maybe with a built in text editor for the files, at the original release.Now, back to my original point, which was about terrain squares and movement. A practically unlimited number of terrain squares would make it impossible to add flags on the unit for each type of terrain, especially if the unit and terrain definitions were in different libraries. Also, this would make a nightmare for giving units terrain specific abilities (camels require no support when on desert squares, for instance) so I would put the flags in the terrain. Give each of the basic terrains a flag, 1-11, and then give each new terrain the same flag as one of the base terrains. For instance, if I wanted to make a new terrain, salt flat, i could give it the same flag as desert, to say that it is desert-like. Including a few user specific terrain types, would be nice, too, maybe enough to bring the total number up to 16. It would make coordinating different libraries difficult, but there's always a price to be paid for freedom... I think there are a lot of customizers out there who would be willing to go through the hassle, and if you don't want to, there's no reason you can't just edit the 11 basic terrains, same as before. Ditto for units, etc. |
Gordon the Whale
b.02-15-99
|
|
posted July 17, 1999 23:07
|
|
| |
As I was reading over that last post, I realized that it would all have to work differently if they used layered terrain, like in SMAC, where instead of using a set number of terrains, they gave each square a set amount of rockiness, elevation, and raininess. I like that idea, so long as its improved (but that discussion belongs in the map and terrain thread). In any case, if they DO use a layered terrain system, it needs to be editable! This is one of the things that made SMAC so hard to customize. One way to accomplish this would be to actually use transparent layers, so you could specify the graphic for each parameter. (draw the base, then draw a transparent layer that shows rockiness level 1, 2, 3, etc, then draw a layer for vegetation 1, 2, 3, etc, then draw other things...) Basically the same as we did in CivX for improvements, except these are natural improvements. Another solution (or rather, something else working in conjunction) would be to have overriding terrains, like the forests or monoliths in SMAC, that are a terrain in and of themself, regardless of the layer beneath them. With the ability to customize the layers (if I want 13 different rockiness layers, give them to me and let me define their bonuses) and to make additional, overriding squares, we'd be in business.Another thing we need to think about is borders between map squares. (again, maybe this goes in the maps thread, or the graphics thread) While i think lots of different squares for each terrain, depending on what terrain it borders, would be a great thing for the look of the map, it would make things very hard for customizers... What do you think? |
Hugo Rune
b.02-15-99
|
|
posted July 18, 1999 06:06
|
|
| |
Hugo the Poster, not the TM: SMAC did have transparent layers. The Major problem with Terrain Customisation in SMAC was that, to keep the in-game palette down to 256 colours and still allow for some shading of tiles, FIRAXIS opted for a ridiculous 32-colour "Displacement" palette which meant that (1) You could only use green, brown and blue, (2) If you used a dark colour for the sea or for hills it meant that shadows/deep water would inevitably turn White (basically limiting the colour schemes of your map, take a look at my I Club Mod Pack if you don't beleve me) and finally (3) that Beaches were beaches even if you changed the colour scheme. It was really annoying, especially the way the sea was handled (There was no way to make it into walls or void properly, like you could with Civ).Oh, and the rivers weren't editable. how can you make a good football scenario if you can't make them into white lines  ? ------------------
Don't mourn for me -- Organize!
Joe Hill's last words before his execution, Nov. 19, 1915 Our lives shall not be sweated from the birth until life closes;
Hearts Starve as well as bodies, give us bread but give us roses!
James Oppenheim, "Bread and Roses" |
Hugo Rune
b.02-15-99
|
|
posted July 18, 1999 09:24
|
|
| |
Scenarios that you could almost, but not quite, make in SMAC/Civ2:1. Dungeon Keeper (or any similar underground scenario): There is no concievable way in the current system to make some units be able to dig tunnels while not letting other units pass through solid rock. With the new "terrain affinity" property of terrains and the "unit terrain flagging" property of units, it would be possible to make a unit that can go in the terrain surrounding dug-out space and change it into tunnel, while others could not move there and no-one could move through solid rock. 2. Civ Football: Believe me, I tried. The "ball" would have to be an alien artifact or other "captureable" unit, that could be carried by transport units (the "players"). However, an advanced macro language would be needed to instruct the AI how to score goals and keep the tally. It would be a really great scenario, and fun to play. Oh, and rivers should be placeable. The current SMAC system is a pain for drawing white lines. Any other scenario possibilities that you'd like to enable? ------------------
Don't mourn for me -- Organize!
Joe Hill's last words before his execution, Nov. 19, 1915 Our lives shall not be sweated from the birth until life closes;
Hearts Starve as well as bodies, give us bread but give us roses!
James Oppenheim, "Bread and Roses" |
Hugo Rune
b.02-15-99
|
|
posted July 20, 1999 16:10
|
|
| |
I'm off to a month-long vacation in hungary, without internet acess. kd, Would you please do the summarising while I'm gone?------------------
Don't mourn for me -- Organize!
Joe Hill's last words before his execution, Nov. 19, 1915 Our lives shall not be sweated from the birth until life closes;
Hearts Starve as well as bodies, give us bread but give us roses!
James Oppenheim, "Bread and Roses" |
n.c.
b.02-15-99
|
|
posted July 21, 1999 08:08
|
|
| |
Customisation must be made very simple. Permit me to explain why.I had always been afraid to go into the Rules.txt file, but once I got sick of the game I figured I'd give it a shot. At first it worked great, but then I realized that was just a plot to raise my hopes. Soon the game would abort just as the initial screen opened almost no matter what I did. It would work at one point but then when I closed and re-opened it would fail, despite making not changes in between. I did make a large number of changes, but none were very radical (two food from oceans, eliminate some units and Wonders). Unless given lots of assurances from the game materials I will not try this at all with Civ III. even if I get sick of it. It was just too frustrating. |
Michal
b.02-15-99
|
|
posted July 23, 1999 01:34
|
|
| |
> Customisation must be made very simple.
> Permit me to explain why.Asking for permission to disagree, Lieutenant, Sir!
Somewhere earlier in that thread it was mentioned that using Java/C/C++ as a scripting language would not be a good idea as it is "too difficult" - exactly, it's meant to be difficult, it was not meant to be learned in one day and by all. Most players have absolutely no desire to create new scenarios or to tinker with existing ones, they are happy as long as somebody else does them and as long as they are relatively bug free.
Difficult customisation has a very, very positive side – it weeds out all prospective "customisers" who don't have enough programming skills leaving only those who actually know what they are doing. I've seen enough scenarios with some brilliant ideas and absolutely terrible execution of those ideas.
If it was up to me I would actually ask Stroustrup to create a new language, one that would make C++ look like Logo  . Michal [This message has been edited by Michal (edited 07-23-1999).] |
n.c.
b.02-15-99
|
|
posted July 23, 1999 08:21
|
|
| |
Michal: Obviously I've misunderstood the point of computer games. I thought they were for fun. Under that mistaken assumption I thought that I would change the items that made Civ II less fun for ME. When I tried these basic changes, the program wouldn't work, meaning either that I am an idiot or the Rules.txt system needs improving (or some of both).With your insight I now know that the point of customisation is to make sure that you get only bug-free scenarios written by computer experts. |
Michal
b.02-15-99
|
|
posted July 23, 1999 17:32
|
|
| |
No, I don't think that you "misunderstood the point of computer games". I simply think that if one likes a game enough to customise it and to "play" with the rules one should be willing to make some extra effort to learn how to do it... There aint such thing as a free lunch.. |
Gordon the Whale
b.02-15-99
|
|
posted July 26, 1999 12:37
|
|
| |
I think Michal is right. The scenario editor should, above all, be powerful. It would be wonderful is CivIII were an engine that came bundled with a superbly made game to run on it, but that people were free to make their own games to run on the CivIII engine, and that these games would not run into problems because the engine was too specific to the bundled game. This does include a very valid point of n.c.'s: It's gotta work no matter what number you put in. But at the same time, that doesn't necessarily mean it needs to be SIMPLE. Just reliable. The fact is, that customizing a game is not SIMPLE. Nor should it be simplified at the expense of flexability. The scripting language should be described in a text file included on the CD with the rest of the game, with a disclaimer that Firaxis/Microprose/Hasbro are not responsible for how much fun you have with it. And they're not. The customizability of Civilization is wonderful, and it allows a LOT more gameplay, more than any other single player game and most multiplayer games. But I don't think the developers need to water it down for the masses. Make it hard; The hardcore designers will design, post their scenarios on the web, and everyone wins, including the developers. |
kd5bjo
b.02-15-99
|
|
posted July 26, 1999 17:44
|
|
| |
kd5bjo the poster, NOT the TM: quote:
How would this be as a "catch-all" solution?Firaxis has a C++/Java-like scripting language that can be used to do the more detailed customisation (such as scenarios) and has something similar to rules.txt to define new units, techs, etc. and have the option to associate a script with everything. ex: Hovercraft, nil, 2, 8.,0, 0a,1d, 2h,2f, 7,1, 4, MP, 000000000000000, hcraft.scr In hcraft.scr you would have functions like:
built(city citybuilt)
disbanded(city disbandcity, loc disbandlocation)
moved(loc locfrom, loc locto)
attacked(unit attackingunit, loc attackingfrom, defendingfrom)
killed(unit killedby, loc whereklled)
enemymoved(loc locfrom, loc locto, loc curpos) along with many others.
quote:
P.S. I agree that the scripting engine needs to be as powerful as FIRAXIS can make it.
|
eNo
b.02-15-99
|
|
posted July 27, 1999 14:36
|
|
| |
I finally got around to reading the thread and summary.I'm not particularly opposed to the idea of increased customisation and more utilities but won't this create a lot of work for Firaxis? Error-checking, a new script language, tech-tree generator... Couple of my own suggestions: 1. Customize Civilization-Colour relationship.
2. Make the scenario/map editor a seperate program.
3. Instead of overwriting the default files, make a special directory that contains the modified files and tell the computer to load those files intead of the originals. |
Gordon the Whale
b.02-15-99
|
|
posted July 27, 1999 15:03
|
|
| |
kd5bjo: That would probably be the best way to make everybody happy (except the in-game editor people... Maybe one of those could be sold later as an add-on, as in Civ2)eNo: 3 EXCELLENT suggestions, which I'm sure we all have close to heart. |
eNo
b.02-15-99
|
|
posted July 31, 1999 00:44
|
|
| |
Gordan: Thanks.4. Choose what a city builds by default or what the produce when the thing has finished. In CivII it didn't change at all; in SMAC it changed to Stockpile Enegery. |
kd5bjo
b.02-15-99
|
|
posted August 07, 1999 19:56
|
|
| |
quote:
moving thread up
|
Q Cubed
b.02-15-99
|
|
posted August 16, 1999 12:00
|
|
| |
<------bump!up this goes.
======
I wouldn't mind a powerful scripting language and scenario editor, but my gripe with it is that if one demands for it too much and too powerful, there won't be much of a game to play...since it's all customizable. And if you change one thing one time, you won't be able to find it again...or, change many things, but want to get rid of one, you won't be able to tell... So, to get rid of most of my fears, whyn't have multiple save states for the rules? But maybe i'm just a raving lunatic here . ------------------
Q Cubed
Renaissance Q • Q-of-all-trades
Thread Discussion Facilitator for Wonders "Logic must dictate my stance." |
Hewhocaves
b.02-15-99
|
|
posted August 17, 1999 11:19
|
|
| |
Is it possible to have the map editor so that you can place the resource seeds manually. I'd love to have (for example) certian places that have seven or eight coal within a specific city radius. |
Hugo Rune
b.02-15-99
|
|
posted August 18, 1999 13:12
|
|
| |
I'm Back!As a poster: I completely agree with kd5bjo for the approach to be used for customisation, although some of the language could "creep" into the rules file too, for defining wonders and city improvements, for example. (In kd5bjo's language, buildcityimprovement 5 or something. As I see it, Civ().City().Buildingflag(5) = 1. But that's just my variation of the same thing.) Here's a concept I'd like to add: Cathegories of units. SMAC went a while with this, introducing "Projectile" and "beam" weapons that were variously affected by each other. In reality, this had little impact on gameplay, as well as being completely uncustomisable. My suggestion is as follows: Each unit can have one of 6 customised weapon types and one of 6 customisable armor types (the same system can be used to define "fast" units, or whatever) ie. each unit has two additional values, between one and six, the first one defining "armor class" and the second defining "weapon class". In another section, the names of the various classes can be defined, #ARMORCLASSES
1, Ancient
2, Classical
3, Mediaeval
4, Renaissance
5, Early Modern
6, Modern or something to this effect. Next, a grid in which the classes are "pitted" against each other is added, in which each value represents the multiple of 12.5 percent that a certain weapon type (going down the rows) gets as a bonus when attacking a certain armor type (going across the columns): 0, 0, 0, 0, 0, 0,
8, 0, 2, -2, 0, 0,
8, 0, 0, 0, 2, -2,
0, 0, 0, -6, 0, 0,
0, 0, N, 0, 0, 0,
N, 0, 0, 0, 0, 0, In which N represents "can't attack". This (a) takes care of the problem of pikemen getting a bonus when defending against tanks, and similar problems, and (b) allows for greater flexibility in fantasy and sf scenario design (eg. fire armour gets a bonus against water attacks, or something). |
mindlace
b.02-15-99
|
|
posted August 20, 1999 19:36
|
|
| |
graphic file format
Don't use pcx, use PNG!
Why? PNG is animatable, supports 24 bit color, has non-lossy compression, has alpha blending over any background, is non proprietary, and just generally cool. |
Hugo Rune
b.02-15-99
|
|
posted August 22, 1999 12:53
|
|
| |
From the web page:One GIF feature that PNG does not try to reproduce is multiple-image support, especially animations; PNG was and is intended to be a single-image format only. However, it's sister format MNG does. But that's still under development. Sadly. |
Hugo Rune
b.02-15-99
|
|
posted August 30, 1999 15:35
|
|
| |
What other file formats would you like to see? |
Hugo Rune
b.02-15-99
|
|
posted September 12, 1999 16:55
|
|
| |
Hey, I found this nice snippet in a GameSpot Preview of Warcraft III:"The scenario builder, which Blizzard has been refining since the days of Warcraft II, will now give users even more freedom and power to create worlds. Called the "advanced world builder" by Pardo, it will allow you to create new units, heroes, spells, and even scan in your own art. According to Pardo, every file format in the game will be nonproprietary. In addition, Blizzard will give users a full scripting language to use, similar to Java, although the trigger system seen in the Starcraft campaign editor will still be supported." Firaxis, take note... Anyone else think this sounds ideal? And that is in an advanced, fully three-dimentional affair with skinning, skeleton animations, completely rendered terrain, etc. Yet they're aiming for the same ease-of-use as StarCraft had. Imagine how well it could be done on Civ3 which at its most will be Isometric 3d! Should firaxis spend the vasts amounts of time needed to achieve something similar? |
eNo
b.02-15-99
|
|
posted October 13, 1999 20:43
|
|
| |
BUMP. | |
Apolyton Civilization Site Forums-archives
