And don't let yourself put off by my incoherent ramblings ... it's just that I'm into computer games for quite some time now, and have done so much (fruitless) beta-testing for games most people don't even know about any more today, not to put things bluntly how I see them, no matter if it may hurt some feelings or not, simply because I don't care any more to invest the time to choose the most "compatible", nicest words so not to damage someones ego ...
D/Led the latest Win version and gave it a try .. didn't have the patience to check the bug database if all my quibbles have already been reported, so just let me write them down (the savegame bug is known, I heard - I was always able to continue from the autosave, btw):
2-windowed windowed mode?!
I get a "FreeOrion Windowed" one, displaying nothing, and "FreeOrion v0.4.2 ..." where the game is ... is this intentional?
Research window size
I'm running in windowed mode only, so I didn't bother to set the fullscreen resolution. Promptly, the research window gets stuck with that resolution (1024x768), even with the main window set to 1900x1000 (see screen01.png).
Setting the fullscreen resolution to 1920x1060 rectified this, so obviously the code is pulling the wrong resolution values in windowed mode ...
Inconsistent GUI
Some pop-up windows have "X" for closing them, some have not (see screen02.png)
All should have them!
"Objects" window lists ... objects. And what are "non-objects", gameplay wise: "Deep (empty) Space" and "Unexplored Regions". (see screen02.png, again); While one can argue that "Deep space" might hold a fleet, and therefore must be represented, "Unexplored Region" is unexplored, and therefore never will show anything, right?
... what brings me straight to .. :
MAP - generator?!
Maps are always the same, e.g. "elliptic, 100 systems, human player" always has you start on the same spot on the same map?!
This can't be intentional!?!
"Elliptical" has a much smaller distance between systems than "cluster" and "irregular" (hope I got the names right, didn't note them down, but you'll know which I mean, right?)
Do those empty "Deep Space" systems really make sense? I always found them skewing the "global" planet distribution on the map ... have one or two of those in your part of the map, and you're missing 2-10 planets already before you even have ended turn 1.
Make the setup pull the numbers for those "few, normal, many" settings from whereever they're stored, and display them. Who wants to try out 10 or more maps just to find the settings that suits him (and the game mechanics, btw.)
Inconsistent aliens
Someone should read up the Wiki entry on "Tundra", and read the species description, really ... :
Code: Select all
Species
name = "SP_SSLITH"
[[TUNDRA_NARROW_EP]]
type = Barren environment = Poor
type = Tundra environment = Good
type = Desert environment = Poor
type = Terran environment = Hostile
type = Ocean environment = Hostile
Flat, aquatic, pliable creatures.
... ability originally evolved for the purpose of sliding into the shells of Vreen (a creature that recedes into its shell when it detects danger). Their flexibility allows them to move astonishingly fast in the oceans, ...
Tech tree - to few tradeoffs, to many no-brainers
IMHO, one should have to decide which hull type, or maybe 2, one wants to deploy; especially organic hulls should require quite some investment, unless maybe the species has some build-in requisite. Otherwise, it's just a no-brainer to get cheap organic hulls for throwaway ships, robo hulls for medium attack ships and asteroid dreadnoughts ... .
Likewise ... where's the point of not going for the plasma gun? The first one gives great firepower already, and frees plenty of space for other modules, with little tradeoff?
COMBAT
Now, this is the biggest letdown, really.
Not because it's essentially not there, but because IMNSHO it could be already there, if you had stuck to your own design Design Philosophy, really:
1) software topology
(and pls. bear with me if I don't use the correct terms here, I'm not a native english speaker, and my programming courses where back then when no-one needed more than 640kB and 1 main process ... )
I haven't checked the design docs, or the code, so please correct me if I'm wrong, but it seems to me you're using a client-server topology where the clients "talk" to the server via TCP/IP, by "loading down" turn files and "uploading" order files?
I really hope you made the AI clients not behave differently from player clients, so basically the AIs are doing their turns while the player is; this would make it very easy to take advantage of hyperthreading/multicore-CPUs, and give the AIs much more CPU time then they get in any game I know of ... .
Anyhow, where does "real-time player-directed 2.5D combat" fit into this picture?
Actually, it doesn't, and it will at best give you all those "out-of-sync" headaches the Civ series is renowned for.
2) game design
Does the game really need 2.5D space combat? Surely fancy 3D graphics will attract the crowd of casual gamers ... but are those really you target audience? Are you looking for making money from selling boxes from the shelf for a month, which no-one speaks about any more next month, because the next box is out, or do you want to make a working game the people play for maybe even years? (there are still people playing Nethack, you know ) And then there are those lenghty, but totally superflous discussions how long the combat phase should/could be, so players don't get bored while waiting for the other players combats to finish.
So have a look at "Stars!", or "Dominions 2", if you don't know them already, for examples how "end-turn combat" systems can work - and they work well!
3) feasibility
If you can't do it, simply - don't!Q: When will the 2.5D interactive space combat be ready?
A: Sorry, we don't know. While there is a tech demo, it is a long way from being an actual part of the game. Due to the more limited availability of coder(s) with the proper skills, it has been progressing much more slowly than other parts of the game.
Judging from the rest of the game, you should have little trouble doing some top-down or isometric "chessboard" combat, where pieces move and shoot automatically according to their specs and player-given behaviour rules, maybe. Heck, you could even forego a graphical solution first, and just present the player with a textual combat report like "Ship XY moves nearer to target Ship YZ and fires at it for XX damage", shown in a seperate pop-up from the SitRep.
Btw., you could always later reuse the existing "demo" as a "combat report viewer", so there's no need to throw the code away
And, again, don't get me wrong, IMO you've done marvellous work already, I'm just a little concerned that you might not get it finished the way you've planned it ... and I really don't want to be stuck with MoO2 in DOSbox foreever
yours
S.