FreeOrion

Since v0.4 is a rather large chunk of design work in of itself, I've written up a roadmap just for v0.4, and put it here:

http://freeorion.org/index.php/0.4_Desi ... .4_Roadmap

Comments, suggested additions, etc. are encouraged, though please post here first, rather than making undiscussed nontrivial edits to the wiki page itself.

The first few main points on the list are roughly in order, so the top item(s) will likely be up for discussion next.

I believe Fleet supply should be considered in reference to Population Migration and Redistribution & Blockades. Not that all the details of Migration/Redistribution need to be worked out, but the basic rules governing moving invisible non-fleet stuff throughout the empire should IMO be very similar.

Also please note that "Supply/Range" comes at the end of "Ship Sizes and/or Roles", as well as in it's own topic. I'm not sure if you have something different in mind, or if this is one of those "conceptual dependancies" which make the discussion so tricky.


Also i think it would be more natural to discuss: "Engines" before "Ship Design System", since the "Engines" topic ties in with "Galaxy Map vs. Battle balance?" under "Ship Sizes and/or Roles". Also i think it would be helpful for "Ship System Design" if more of the ship's innards (i.e. engines) were basically known.

And there is a conspicuous absence of weapons/shields/PD/etc. in the Design Pad Roadmap. I realize the basics are already set down in the Design Pad, but surely the ideas need some development before going directly into designing the tech content.

In other words:

1 ) Ship Sizes and/or Roles
—* What sizes/roles?
—* What pros/cons/properties?
—* Galaxy Map vs. Battle balance?
—* Supply/Range, Travel Speed, Battle Effectiveness
2 ) Engines
—* Interstellar vs In-Battle distinctions?
—* Separate engines types for different situations?
—* Multiple options (different speed, stealth, fuel use?)
3 ) Arms and Armor
—* Weapon types
—* Defense types
—* Fighters
—* Etc.
4 ) Ship Design System
—* List, Grid, Slots?
—* Surface locations with visible parts?

_________________
—• Read this First before posting Game Design Ideas!
—• Design Philosophy
—•— My Ideas, Organized —•— Get an Avatar —•— Acronyms —•—

I just noticed that defensive structures like orbitals and defensive buildings that can be build on the planets are not on this roadmap. So here are some questions about those:

-Should there be different hulls for orbitals or should they use the same hulls as ships, so they would be basically ships without engines?

-Should the player be allowed to design the orbitals too or would they be just ready structures that the player chooses to build, like in MOO2?

-Should there also be buildings, which affect the space combat like missile bases and planetary shields?

-And if so, should these buildings be build able on every player controlled planet in a system, or should they be like other buildings and only be build on for example one planet in a system and support the battle from there?

I also looked quickly through the buildings.txt and didn`t find any signs of these sorts of things, which leads me to believe that they weren’t designed during v.0.3. Is this the case or did I just somehow missed them?

The orbital-related questions assume that there will be orbitals and that they will be very similar to regular ships, which is a bit premature. The "should there be buildings?" question is more appropriate at this stage.

I've added some relevant points to the v0.4 Roadmap under "Non-ship Objects in Combat".


v0.3 was about planetary resources, infrastructure, economy and production, so the buildings so far have been mostly related to these areas. If buildings are also integrated into space combat, then we'll add some buildings for combat stuff. Also, the current crop of buildings isn't intended to be exhaustive, isn't carefully thought out or planned, and certainly isn't complete, even within the scope of v0.3 features.

I see a lot of threads relating to combat features such as fuel, supply, ship sizes, shield facings, travel speed... what i'm worrying about is how effective are these feature work together as part of FO as a 4X as a whole? it appears there are many redundancies in mechanism and complex if all the features are put into the game. i don't see much time is spent organizing different elements and how they are suppose to play or connect with each other. we do a great job generating ideas, but i think we should generate ideas on how to put these ideas together or else we might make the same mistake as moo3, being overly complex or force to dilute great ideas into less meaningful features in order to fit everything in.

I'm not strongly oppose to any of these feature, though I do have opinions about which features is better and, more importantly, adds to FO as a whole. I think it's better to concentrate on a small set of features and develop them well with rest of the game. There is nothing wrong with concentrating the combat aspect of FO on ship sizes, facing, weapons rps as a set or fuel, supply, travel speed, stealth as a different set. The former might make a game that put more emphasis on tactics aiming your strong weapon at your enemy's weak spots while the later concentrate more on logistics at a more macro level. Both can make a fine game, but they appear distinct flavor to me. but i think it's a major mistake if you have too many flavors all meshed together giving you a giant wad of garbage in the end. my main point is that we should take a step back and pick a set of features to concentrate on.

or maybe have the player pick one set to focus on per game. for example, one race might be oriented towards hit-n-run so their techs mainly have logistical set of techs and little armaments to choose from. you can extend the "theme" through out the game as one of several ways to play FO so the the race history, flavor, techs, combat, play strategy are sort of unified and each piece fits somewhere in the grand scheme of that particular game and not jumbled up from the way FO looking at right now to me. of course, i could be wrong since i only have so much time to contribute so i tend to miss a lot of things.

_________________

There isn't a separate thread to discuss this issue, but each individual feature thread does or should include discussion about how various features would work in the larger game context.


There are two distinct parts to the game, which correspond to these distinct flavours: the strategic galaxy map and the tactical battles. Fuel, supply and travel speed apply mainly to the map, whereas weapons balancing and facings apply mainly to battles. Ship size applies to both, as might stealth, though the latter is currently more fleshed out for in-battle.

nothing wrong with bottom-up design approach, then review how the features work together. or perhaps leaves some ideas for expansions or mods so we could crank FOv.4 out.

all those features appear like a huge wad to me. there only so much flavors you can stack on an ice cream cone before everything starts to fall apart. i wondering if anybody else mentally thought how the game would play if all those features to the level of detail described in the threads were implemented? it seems more like work than fun to me. i like simcity, homeworld, civ... but playing those game and making meaningful progress all at the same time in one hour sitting is crazy. i like depth, but it's too hard to be deep on everything.

_________________

You could run a popularity poll on it. Have the members of this forum rank the features in order of importance (to them). Then rank the technical difficulties of implementing those features, and add the two ranks. This should give you a combined score list.

Then just implement the features you (the creative team of programmers) decide are really worthwhile.

Example: Feature A scores an agregate 1.3 on the popularity poll with a technical difficulty of 10. Feature B scores an agregate 17.9, with a difficulty of 2. Feature C scores an 8.0 popularity and a difficulty of 3.

Upon review, Feature C is fairly popular and would be relatively easy to add, so you add it (combined score 11.0). Feature A is screamingly popular but very difficult to make work, so you decide to wait until you can code that feature properly and add it to v.4 RC7 (combined 11.3). Feature B isn't very popular despite is simplicity, so you decide to not add it (combined score 19.9).

After a little coding, you discover that you can slip in Feature B as part of Feature A without slowing down gameplay. What's better, you can do it in a way that makes Feature A work better. You then add in both A and B as part of v.5, but remove C due to its unbalancing effects on gameplay.

Shoot, it's your game, people. We are just here to cheer you on (and hopefully get a free copy when you release it).

I share skdiw's general concern. Especially recently it seems like every aspect of ship design is given options. I fear feature creep is pushing the end of v.4 away faster than we can move towards it.

With each option added to the game there is a diminishing return in "fun," with an increase in balancing and coding effort per feature. FO will not be better than MoO2 simply because it has more options.

If we compare our v.4 to MoO2, i can't think of anything that's simpler than MoO2. Most things in their popular or semi-official design pad form are more complex or have more options than the similar aspect of MoO2. But FO isn't a game where the primary focus is combat/ship design, and everything else merely supports combat. I think it's important to remember this when working on FO.

_________________
—• Read this First before posting Game Design Ideas!
—• Design Philosophy
—•— My Ideas, Organized —•— Get an Avatar —•— Acronyms —•—

I think the level of complexity in the current design pad stuff is being overstated. The actual contents in the pad can be summarized:

* Battles happen in discrete turns that play out individually in real time
* There should be things to do in battles besides killing ships
* There are 4 basic weapon types
* Ships hulls come in about 5 sizes
* Ship designs are parts in a grid of slots
* Some ships can't be seen from far away on the battle map (stealth)
* Ships can't travel indefinitely while away from friendly bases (fuel)
* Ships can't fight indefinitely while away from friendly bases (ammo)

Some of the details (slot size, hull shapes) have "may" in them. This means we might or might not actually use this in the game, not that it's optional so that both options will need to be implemented. The first implementation probably will omit some of these potential features unless they're deemed needed.

There is a lot of text there, but much of it is explanations and descriptions and reasons for various decisions or how things should work, and not actual additional design complexity. The distinction may be difficult to make when skimming the document.

Regarding the still-in-thread discussions, the latest option for engines is to make them part of the hull, so not a separate design option. Planet combat characteristics are to be described by two meters. The mechanics of how planets provide supplies are simplified to a single range limit and instant resupply.

If something is being proposed that's more complicated than it needs to be, please post about it in the appropriate thread for that topic. I doubt much of this stuff can be simplified much more without removing it completely, though...

...And removing them completely isn't really an option in most cases, because the overall game design needs them. It's been decided that we don't want an extremely simple game where more ships always win battles, all weapons are functionally identical, ships can move indefinitely as far away as they want, there's no way to play except by building lots of ships, etc.

I'm in the same frame of mind as skdiw and eleazar. I think that we are rapidly adding features to what I think should be the lesser of the two meta-games (being strategy and tactics) within FreeOrion. If one is really to command an empire, how can one be bothered with individual ship facings (may personal least favorite combat feature)?

Moreover, I think that each element of the tactical game should bear some significance to the strategic game, or it should be dropped. For instance, you need to do strategic planning, ship design, and production to come to a battle with a good mix of weapons, or ships sizes, or any number of other factors, but not ship facings. Facings are purely a detail of a single tactical combat, and so I think they have no place in a combat engine in a turn-based strategy game. I'm not picking on ship facings in particular, so much as using it as an example of the kind of feature (or misfeature) of combat we should avoid. The roadmap Geoff has posted on the wiki is comprehensive, but I think it needs a bit of trimming before it gets brought to this forum. Here's what I would cut even before the discussion stage:

Engines - Multiple options (I put this in the "too much detail" column)
Battle UI (belongs to graphics team anyway)
Battle map layout - Relative scale of objects on screen? (again, this is aesthetic)

That said, I think that most of the items in the roadmap are very much important in the strategic game. I submit that the best way to handle them is in the most strategically relevant to the least. This way, decisions about less-strategically-releveant elements of the design depend on the more strategically-relevant ones.

Specifically:

Shipyards
Battle map layout (especially the policies for when you can do strategic-level things like invade a planet or jump down a starlane when there are enemies present and/or you are in combat -- this will really affect how you play the high-level game)
Ship Sizes and Shapes
Non-ship Objects in Combat
Engines
When to fight? (frankly I didn't get this one -- what exactly did you mean here, Geoff?)

<snip>

Just to be clear, I agree with this too. I just wanted to make it clear that I share the same concerns as skdiw and eleazar, and want to be sure that the tactical game truly serves the strategic game, and not the other way around.

Looks like this thread is turning into an impromptu public review... Which is fine, I suppose.


Facings are presently in the design because Aquitaine wrote them in. I can't find any discussion where this is actually justified in a logically valid way, however. This leads me to suspect it was added because it's important in the Total War games, which was essentially his ideal for FreeOrion combat, as far as I know. Total Wars' strategic maps are more or less subordinate to the tactical battles though, which are the real point of playing the game. So this ideal isn't necessarily applicable to design decisions for FreeOrion.

So... unless the above is a straw man argument, I am (or rather, remain) receptive to deleting facing from the tactical game design.

As a plus, it would seem to be easily removed without any major consequences to other decisions.

Does anyone have any reasoned objections to this?


Engines are relevant directly to the strategic game, as much or more so than to the tactical game. Regardless, we've essentially had that discussion, and as noted above, I've semi-settled on an arguably simple system where engines aren't separate components, but instead engine-like ship characteristics are properties of the base hull itself.


This doesn't mean full implimentation details are to be discussed or a UI design to be finalized as part of game design. It just acknowledges that some high level aspects of the UI need to be decided in the game design context before graphics can do anything useful. Graphics might decide how specifically to show some information, but game design would need to tell graphics what info to show, and decide, with heavy graphics consulation, whether it's practical to show certain info. The current discussions about modelling ship parts or using icons over more generic hulls is a good example... It's not just about whether models or icons looks better, but whether the necessary info can be conveyed at all with icons or models.


The meaning of this is a bit unclear without the subpoints:
* Planets arranged in space?
* Star size w.r.t. other objects?
It's not just how big on screen things are, but the general layout of objects in the battle map. This includes issues such as the relative distance between objects and the sizes of those objects, how big the map is and how long it would take to travel across it, and the issues you (tzlaine) brought up, etc.



This sounds good in theory, but often the discussion will just degrade to every listing their own set of other decisions they'd need to be made first before the current one can be decided. So in pratice it's often necessary to make some lower-level decisions first...

Much of the current crop of threads should hopefully be closed soon though, which will both provide the background decisions necessary for and make room for the Shipyards and Battle Map Layout discussions.


If we have many players in the game, each with several fleets moving about and getting into multiple battles per turn, we probably don't want to always have players manually resolve all battles. There have been various suggestions about how to allow players to pick which battles to control, and how to limit the number of battles the player feels the need to control, etc. This is particularly important for multiplayer games where we don't want to have several players waiting with nothing to do for many minutes while one player plays through several combats back to back.

Ship facing is something that can be removed from the game design, unless there are compelling reasons to keep it, pending approval of the game designers.

I think we are on the right path and are doing well. What we need to do is think what we want programmed for V0.4, eg basic map (black plane), make ships appear, basic movement, auto resolve etc.

But the extra stuff we have done is good, cause we are looking ahead. If we plan everything out first, the when we program we can save time by not programming unnecesary features.


That's premature to say. There can be highlevel uses for such a feature, eg flanking or ship movement (costs to turn).


I disagree and have not seen consensus on engines as part of the hull. All components of a ship should be treated the same, as components to place in a ship. Why should engines be treated differently? If engines are linked to hulls, then you have 20xhulls * 20xengines = number of hulls. A superior way would be to have hullsx20 + enginesx20, only 40. You see what I mean, it's basics of a database design and a bit of object orientated phylosophy.


I see no reason why this was not a good idea. Though I do think that this was more the defense section of space combat, then terrain or map decisions.