FreeOrion

Hi dee Ho!

I posted some time ago on wesnoth forums, asking if anyone knows a freeware game project which would need volunteer for doing some coding. Someone with nick "The Silent One" told me about freeorion. That's why I am here.

I browsed some of the wiki pages, and I was impressed. I liked what I saw It all felt quite well organized - from requirements to specifications and implementation. I would not have been surprized if I saw inspection plan for different interfaces

Okay, then some words about why I am here.
I have always wanted to participate in freeware game project. Unfortunately I have huge holes in crucial techy skill sections, and my time is quite limited (I am a father of two young kids, and have a fulltime job...). That is why it is difficult for me to find a suitable project. I do not want to delay things.

Well, what I can do then? I have done coding work for approx 3,5 years now. (Although I do not have proper education for that, I was and actually still am, studying for physics masters at Uni in Finland). First 2 years was not so professional C++ coding for a cosmic ray research project I was involved. Then I got tired of constant uncertainity about the project's funding, and switched to WCDMA BTS developement which is done in C. That I have been doing for 1,5 years now.

So I can say I do allright C, and I have distant memories about C++

Well, then the huge gaps in my skills I mentioned... I have never needed to write any graphical apps. I have been working close to HW. Nor have I done sounds. Both of those are fairly important in games if I am right :p I have never done windows programming either, at UNI I had linuxes, and in my current work.. well, we have something I am not allowed to talk about :/ So I am not too good with OS specific things. However I could be able to do something with the game engine, or bug hunting. But the limitation is my busyish schedule.

So what do you think, do you have a suitable task for a guy like me? I am keen to see how things are done in application level (since - as I told - I have been working on system level for my 'professional career'), besides I have always wanted to be mentioned in endscreen or readme of a game

Oh, and a general note: Thumbs Up for this project! I LOVED old MOO1.

Ps. Try valgrind for linux memory checking. At least I have found it excellent, especially what comes to detecting invalid reads/writes and memory leaks. Just compile the linux version with flag -ggdb which adds gdb debuginfo (assuming you use gcc/g++ - I admitt I haven't even checked the code yet), and it should give you quite accurate information about the problems it finds.

_________________
CWF Freeware
Programmer's Diary
C - features in Finnish

Almost everybody is busy, but volunteers get to work at their own pace, and contribute as much or as little as they want. The important thing is finding something to do that you're really motivated to work on, even if it takes a bit of actual work to accomplish.

Graphics, sound and much of the OS-specific stuff in FO is mostly handled by libraries such as OpenGL, OpenAL and various Boost components. If you want to work on any interface stuff, learning a bit of OpenGL will probably be necessary, although you can copy and pasted and tweak your way to quite a bit... (Or I can, at least).

FO's code uses a lot of templates, and makes use of the C++ standard library and Boost stuff that ranges from minor extentions to the STL to whole libraries to do things like exposing functionality to Python for the AI. The Boost libraries take a while to figure out, but are very useful, and the STL stuff is basic C++... It takes a while to get used to, but is incredibly useful. I knew nothing about Boost Python last year before I got the current (basic) AI interface up and running.

If you've got a basic understanding of C++, then there's plenty of game logic and interface code you could work on that needs to be done. Have a look at the Programming Work page on the wiki, or see if you can track down and fix a bug listed on sourceforge.

If you need help figuring out the codebase, which you likely will as there's quite a lot of it, feel free to pm or post questions.

Thanks! I will check the bug list when I'll get some of my own time.
I once decided to learn usage of openGL via glut, but the idea of leaving the controll for the engine and just using callbacks was a bit too strange for me. (I understand how it works, but I never really learned to design anything usefull with it. I started writing a pong game though, but then I got some new responcebilities at work, and forgot the pong project).

Oh, and I have always somehow disliked scripting, I have naturally done some compulsory bash scripts while on linux, and something with php, but that's about it. Never used python, or boost library. I guess I can learn it though, if I just find the time to study... I guess my first step will be to find the code, compile it on linux, and see what valgrind says

_________________
CWF Freeware
Programmer's Diary
C - features in Finnish

Welcome, Maz! You actually reacted to my post... cool
...
A while ago Eleazar submitted a feature request that nebulae could be rotated/flipped randomly (and should not overlap?) at the beginning of a game. Maybe that would be a good start? - You would immediately see the results of your work, and get to know the code a little.

While you are at it, please scale them up to about 250% - 500%. Those tiny color blobs look weird. Looking at old screenshots, nebulae have been much bigger in previous releases.

Thanks for warm welcome mates. I however believe I'll start by g and compiling src, trying the game (so I'll know what you talk about) and then see what - so many times mentioned (sorry, this sounds like an adverticement) - memory checking tool finds. I belive I saw some kind of mention about crashes and memory leaks in bug tracker... then I can see what this nebul* is although rotation and resizing sounds like graphics task for me

Anyways, thanks for the warm welcome, I do hope I'll find the time to really do something!

_________________
CWF Freeware
Programmer's Diary
C - features in Finnish

I know this is not going to be a shock, but I wanted to inform you anyways

I cannot really help you out, even though I like the project. FO simply has too many too bleeding edge libraries as requirements for me to keep up-to-date. I know I never really did anything but gave a few suggestions, but I feel it is fair to tell I cannot participate. But I do have one more comment, which is not going to please you. I know I am not in position to tell you how to do your job, but I will still tell my opinion - treat it just as an opinion.

In my opinion you have too much dependencies for average user to fill. And for average coder who cannot spend much of time on computer can resolve. If you could use a bit older libraries, and use them a bit less, then you were more likely to find developers, testers and target audience.

That's it, I'll keep an eye on your project, and respect the work you do, but I cannot find the time to really help you guys :/ I feel like letting you down - sorry guys (and gals?)

_________________
CWF Freeware
Programmer's Diary
C - features in Finnish

When you say "keep" up-to-date, do you mean "get" up-to-date? The libraries used don't change that frequently, so once one gets a working build set up, it shouldn't require much / any effort to keep it that way. Most of the dependency versions haven't changed in over a year... what is so "bleeding edge" that it's a problem?

People occasionally mention that getting FO to build is difficult, and that there are too many dependencies, but could you be more specific? Which dependencies are problems? Which do you think shouldn't be required? Looking over the list, the only thing I can see that could easily be removed is graphviz, if we had a replacement bit of code to do tech tree layout. The rest seems pretty fundamental... font rendering, image file formats, audio file formats, Python, Boost, SDL, etc. log4cpp is LGPL, so could perhaps be stuck in the FO repository.

I'd like to do something about this, but it's not clear what would be possible and helpful.

Boost was perhaps the biggest problem for me. I had to upgrade my whole OS to newer one to find new enough version. i wonder how many distros did offer that version an year ago? Anyways, I do not mean to attack you. And I do not really have competence to tell you which libs could be got rid off. I do not know any of those too well. I just noticed myself, that meeting the dependencies was troublesome. Especially the boost, but also ones which could not be found from fedora repos. (or dries, rpmforge, livna,...)

It might help a bit if you could replace the rarer packages with some more usual ones. I do not know if you can though

_________________
CWF Freeware
Programmer's Diary
C - features in Finnish

There's no way we can do without boost... and not even without fairly up-to-date versions of it.

Other than that though, you're still not being specific. Which specific libraries did you have trouble with (names, please)? That they weren't in the fedora repositories doesn't tell me anything (it might if I used linux or fedora in particular, but I don't).

I also don't want you to tell me which libraries you think could be (easily) removed from the code, but rather which libraries you had trouble getting and setting up. Which packages do you consider to be rare? It might be possible to replace some of them, but I don't want to bother thinking about it if they aren't ones that people will have trouble getting anyway.

I had some problems with locating (at least):

Log4cpp
DevIL
FMOD

If I remember correctly. But since it has been a while since I compiled FO, I do not remember all of problems accurately enough. Sorry

EDIT:
But required boost version was the hardest part.

_________________
CWF Freeware
Programmer's Diary
C - features in Finnish

We don't use FMOD anymore; it's been replaced with OpenAL

log4cpp could potentially be replaced, as it's not really doing a whole lot besides writing to the console and a text file, as far as I know. Unless there are some subtle issues with logging that I'm not aware of, which is quite possible, it shouldn't be too difficult.

I'm surprised you had trouble with DevIL... It's not a particularly obscure library (as in, I can find high profile projects that use it), and the version I've got (1.6.5) is something like five years old. If your repository doesn't have that yet, then that seems like it's really a problem with the repository...

Is there a reason you couldn't download and build the latest boost release?

I could have downloaded latest boost source, yes. But I was afraid of consequences. There's many apps using boost, and I did not know about the most recent boost's backwards compatibility. (It may well be something else had broken). And I did not want to have two of em in my machine, I only have bad experiences about such situations. (It could have worked well, but I am no expert with 3.rd party libs. I have been working my whole career under/in/just abowe kernel with almost ANSI C. except my work in a research group where I wrote a measurement program with C++, but only lib I used was ncurses )

I was also expecting newest boost to depend on some more recent pkg, which could have required some other pkg... I guess you know the issue.

And DevIL was not THAT hard, once I found the sources they compiled just fine.

And I do not want to tell you that you must do something. But it is true that your compiling forum is quite active... Actually I wonder how many linux users have managed to compile FO easily - without asking for help first.

mmm... what kind of requirements do you have for the logging feature? (What does log4cpp offer that you need?)

_________________
CWF Freeware
Programmer's Diary
C - features in Finnish

What distribution were you using, Maz? I could get all the libraries I needed out of Debian-Stable's repositories early last year, and that is definitely not using bleeding edge stuff, so if you were having trouble, I suspect your OS must have been an old distribution, or lacking volunteers to maintain the repository.



Well, it's anecdotal, but I didn't have any real trouble, save for a build bug where scons configure wouldn't ignore my lack of ogre properly, but that doesn't have anything to do with the large number of external dependencies (which there are a lot of, but there's no real point inventing the wheel). The wiki tells what libraries are required, and installation of libraries (even by source) isn't that difficult. If you're not using a distro with a repository, getting all the source code will take a while, but it's not that difficult. If you do have access to a repository (an up to date one ), then it becomes trivially easy to install the dependencies.

That said, if it was someone who'd never compiled a program before, then it is prohibitively difficult, but thanks to kroddn's fine work, they can just download the statically linked one.

log4cpp has been removed as a FreeOrion dependency. This was done by putting the log4cpp code into the FreeOrion SVN repository and building the needed code into the FreeOrion binaries.