FreeOrion

I love the game so far, but the following are the sticking points I've encountered:

(1) Lost in the tech tree: New-ish players have to click on each of the application/refinement techs one-by-one to see what seems useful. For techs that allow buildings, the tech tree says "allows you to build Monolith" but doesn't tell you what a Monolith *does*... to find that out, you need to leave the tech tree, go into production, and look at the stuff you can't yet build. That's not very intuitive or elegant.

BTW, It would be great if there was a web page that had an outside-the-game copy of the tech tree, where you could click on the tech that gives you Monolith, and it would tell you what a monolith does for you. Include a link to that page in the folder with the executable.

(2) Queued tech descriptions: If you queue up a bunch of technologies and subsequently forget what one of them does, you try to single-click on that tech to find out. That brings to where in the tech tree that tech is, so that you can click on it from there... unless you're in tree view and have on filters, in which case it does absolutely nothing. Why not just bring up the description when you click on it from the queue?

(3) Tech tree "list view": change the tech tree from tree view to list view. Try to select one of the yellow techs... you know, the ones that are now hiding behind the description field. Try to scroll up to get to those techs and realize you *can't*.
The top bounds for the list should end at the bottom of the description area.

(4) Descriptions of benefits: "Any object that contains an object that is the source object." "Any object that is a population center and belongs only to the source owner empire." What? Could these be phrased in such a way that they make sense to new-ish players? The first quote above is gibberish to me. The second seems to imply that it must be (a) built on a planet, and (b) that planet must belong to only one empire. Can buildings be built in space, or on some other empire's planet? If so, the new-ish sure doesn't know how, and could spend pointless hours trying to figure out how to do something that is impossible (or possible but not useful, etc).

(5) Documentation: I've seen some quick-start guides, I've seen some threads that have some basic instructions about this or that. However what I don't see is a user guide. Maybe I'm just missing it. Not surprisingly, concepts like stealth/detection completely elude me (no pun intended) within the game -- I have no idea how important it is, and I might spend a dozen games with trial and error just to figure it out if not directed otherwise.

Also it should be noted the guides I've viewed are a mishmash of talking about version 0.2, 0.3, or 0.4 of the game, and at least some concepts in those guides are completely incorrect/out-of-date. My ships don't get stranded in space (they get .1 jumps of fuel every turn), you start the game with the ability to make colony ships, etc.

Your complaints are valid.

The reason documentation and descriptions are often inadequate is that the things they describe are still Works in Progress. Some techs are just placeholders that don't do anything. Others involve features that we've just roughed in, but probably will change. With not enough man-hours to go around polishing up this stuff isn't usually top priority.


That's a good point. Your suggestion would be more useful. I'll add it to the feature requests.

Agreed. I've made that point before, that these floating little windows are a pain. At the moment i can't remember if i didn't convince anyone or it was put off until the time we give the research and production UIs an overhaul.

Those don't make any sense to me either. I think they are auto-generated.


This is an open source game, so if you feel strongly enough about these faults, you are welcome to work toward fixing them. You apparently can write lucidly.

* BigJoe5 i think has been involved most recently with tech effects and descriptions and could point you to what you need to know to work on them.

* If you want to create an up-to-date play guide feel ask questions about the specific features that aren't explained.

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

I agree that a lot of the techs/features are in progress, which makes it hard to keep instructions for the game up-to-date. That said, I'm willing to take up the challenge. I'm going to play some more FO games and start making observations as far as what I understand, what I somewhat understand, and what completely escapes me. We'll figure out how to progress from there.

Sounds good.

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

The encyclopedia showing of techs clicked on the queue is done in SVN.

In my builds, clicking on a tech on the queue when the tech tree filters are set not to show that tech already does still show that tech on the tree, by turning on the filters required to show that tech and then centring on it.

A few comments from a *very* new player (downloaded and played my first game yesterday).

As I understand it, this game is very much in an alpha state. We may enjoy the games that we play, but some of the responsibilities that we have as players are to report bugs as we find them, suggest improvements, or - if we have the skills - participate in the coding process.

I haven't written any code for 20 years, but somewhat more recently (maybe 10 years ago -LOL) I tested software. I was pretty good at finding bugs but my biggest problem was testing software for what it was supposed to do - because many times I didn't know or understand what it was supposed to do.

Documentation goes hand in hand with software development and the initial run through must be done either by the person spec'ing the code, or the person writing the code. In my time, I found a lot of coders who didn't want to "waste" their time documenting when they could be coding, but it bit us in the ass if they didn't.

Here are a few suggestions:

1) The design team should put together a manual in the wiki. (The existing manual page is NOT a manual, it is a hotkey cheat sheet). This manual should be outlined by people with technical writing skills, preferably people who have played a lot of 4X games.

The design team does not need to write the whole manual - they just need to create the skeleton which coders and players can flesh out. What is the concept for how the game is supposed to work? What features have been implemented? What features are being worked on? What placeholders have been installed for other features later? The bottom line for me as an IT manager or a software tester was, "if it is in the code, it has got to be in the documentation".

It isn't necessary to talk about possible future features unless a player will be confused by something that they experience in the game; i.e. "this building does nothing yet, it is a placeholder"

2) The manual should include a basic "strategy guide" chapter. What should a player focus on when first starting a game? How can the player maximise growth? production? expansion? What defensive preparations need to be made?

This "strategy guide" is more than just an intro for new players, it is a play test guide. If I do this, does that really happen? What if I do something else instead? That seems really cumbersome, what if we changed the way Process X was implented so that it worked this way instead?

The "strategy guide" will go through many iterations during alpha. It is the visible embodiment of the mechanics of the game. Every time the code changes, strategy will change in some way - The Butterfly effect. And given that there are two modes of play - single player vs. AI and multiplayer - there needs to be two sections in the strategy guide.

3) Every item that can be built and every "tech" that can be researched should have a comment section that clearly states what impact that item has on the game. "This allows the player to create XYZ"; "This gives the player a +n bonus to ABC"; "This is a placeholder for a feature to be added later".

Some items and techs have comments like these, many don't. The comments should be uniform (all at the top, all at the bottom, all in yellow text, etc). They may be modified or completely removed when the software goes beta, but they are critical to testing and development. "I spent 80 turns researching Tech PDQ - did it have an effect? Did it have the effect that the design team intended?"

I like what I've seen so far and I hope that I will be able to contribute to the development in some way. Once I've finished my first game, of course.

Have a look at the 0.4 Quick Play Guide. Some of the information might be outdated already though.

Most techs don't do anything at this point, they are just there to structure the tech tree. As I understand it, this will be reworked a lot and initial work has been done in this direction. The underlying technology, that allows techs(or buildings) to do certain things is fully functional. However content creation has not been a major priority, because before this can be done, clear strategies and paths through the tree need to be established.

I started with the Quick Play Guide, then started playing a game, then searched for the "manual", then read through the Design Pad (VERY informative - would have loved to have seen the design pads for code already implemented - I'll look for them). Information like the content of the "effects" page is, um, "informative" (smile), but is more useful to a coder than a player or a tester - especially with regards to the FO K.I.S.S philosophy.

I was an adequate coder at best, and when I was coding, object oriented programming languages hadn't even been invented yet. So I won't presume to tell anyone how to code. I have some experience with project management, and this project seems well organized. As I said in previous post, though, many times I've been involved with projects where developers said, "I'll document later" not realizing that coding is more effective with feedback, and the quality of the feedback is directly related to the amount and quality of the documentation. At least in my experience.

But I've never managed an online development project like this one, so the conditions could be different.

In any case, I really like a lot of what I've seen so far, and I look forward to seeing updates of the software as the project develops.

Have a look here.


I think the target audience are people interested in creating game content(techs, buildings). This can be done without any coding, just by relatively simple scripting. I guess the point I wanted to make is, that while most techs are placeholders at this point, the game itself is extremely flexible and allows for some very interesting content, which is just not taken advantage of yet. This is IMO the most overlooked part by new contributors. You don't need to be a coder or artist to contribute and get something into the game.

Anyway, your input is appreciated.

Hi, new player here (installed it yesterday). So far i like it very much. Encoutered only some minor problems so far:

1. Advanced Asteroid Mines refinement (upgrade) doesn't seem to work (value remains at +4 mines bonus instead of +8).

2. How come i can't colonize swamps and tundras early in the game but only later on? Did i miss something?
(radiated,toxic,inferno and barren can't get colonized throughout the game. I guess it's intented that way).

3. Terraforming. How does it work?

One suggestion:

I often found myself looking up again at some tech i'd mastered. Why not show the completed techs when disabling "All" and enabling "Completed" in the Research menu?


*Edit*
2. Ok, found it. Habitation Domes.

I don't think I follow what you're suggesting here. Do you want to see, or to not see, techs that have been researched? What happens now? Unless something's going wrong, if a tech is researched, it should be visible when you've got completed techs enabled and the appropriate tech category enabled in the tech tree controls. One source of confusion might be the "All" button, which toggles on or off all tech categories, but doesn't affect the completed/available/unavailable display options.

Hi Geoff the Medio,

I meant being able to view only the completed techs (filtering out the uncompleted).

btw, don't really understand what the "researchable", "unresearchable" is all about.

It's still not clear what you're saying. Are you suggesting that there be a way to show only completed techs? You already can do this, by setting the tech tree controls to show only completed techs.


Researchable techs have all their prerequisites researched, and can thus receive research funding if they are put on the queue at a high enough position. Unresearchable techs have unresearched prerequisites, and can't be research funded until all their prereqs are researched.

Yes thats what i meant. But how? doesn't seem to work.



Ok thanks.

Turn on completed and turn off researchable and unresearchable.