My comments regarding UFO: AI development

[misiek]

Hello,

First of all couple of important things:
1) I really admire your project and i'm very grateful for doing this. I know that it's hard to develop such project when you have work and real life (i recently started to develop a website in my free time).
2) I don't have experience in developing and managing open source projects, so my comments and ideas may be incorrect.
3) I don't want to criticize anyone or anything and i'm not demanding anything - i only want to help.
4) It's your project, so it's your decision how do you want to develop it.

Now my comments:
1) Releases
I think that release cycles are too long. You should develop it in smaller steps. Frequent releases can be good for publicity - people can see that this project is developing, more people can join in (especially artists, because there aren't many - i think). 2.2 was released over one year ago and you have made so many changes for 2.3 that you will probably won't be able to describe everything in release notes

I think that it's time to concentrate on releasing 2.3. In next couple of months you should concentrate on fixing bugs and disabling functionalities which aren't working properly (postpone it for later releases).

For reference look how frequent Battle for wesnoth releases are:
http://libregamewiki.org/Battle_for_Wesnoth_release_history

2) Project management and issue tracking
I don't know if you're happy with sf issue tracking system. If not, maybe you could try to switch for example to trac. I've noticed that it's used by many open source projects. It has nice roadmap functionality, in which you can assign issues to milestones (so it could replace your todo page on wiki).
For example:
http://developer.wz2100.net/roadmap

[Canuck77]

I'm not a dev, but I know there has been a lot of discussion back and forth with people feeling the 2.3 cycle was too long.

On the other hand, it seems as though there's a stretch goal of making the game completable (ie. you can win, which is really far from possible in 2.2) in this release, and that's why it has taken so long. Certainly, nobody has said that, but when I look at the TODOs and things of that nature, everything appears to be there. If they disable the things which aren't done, then 2.3 isn't able to be played until the end, either.

You can either compile the dev builds yourself, or download the binaries from whichever platform's forum you like... I know that isn't the point (you're referring to PR), but...

[BTAxis]

On the other hand, it seems as though there's a stretch goal of making the game completable (ie. you can win, which is really far from possible in 2.2) in this release, and that's why it has taken so long.

Not really. The thing that has kept us from getting into a release track has been a lack of coders. There are some issues that are showstoppers, and there are only a few people who know anything about that part of the code, and they aren't exactly working around the clock.

[misiek]

Not really. The thing that has kept us from getting into a release track has been a lack of coders. There are some issues that are showstoppers, and there are only a few people who know anything about that part of the code, and they aren't exactly working around the clock.

That's bad situation I'm afraid that if you won't concentrate on fixing bugs (instead of implementing new features) it could lead to situation in which current showstopers will be fixed, but other will occur because while someone was fixing current showstopers someone else implemented half working new features. This way ufo:ai can be in constant development stage. Maybe some kind of solution is to announce feature freeze from now, until 2.3 is released.

[BTAxis]

That's the idea. The 2.3 branch will essentially be a feature freeze, with only bugfix commits. But we can't do that until pathfinding is working, or so I'm told.

[shevegen]

I hope that UFO:AI finds a good solid way to improve the game steadily.

2 years ago or something (maybe 3 years ago) I started to look at any projects that tried to simulate the old UFO feeling (you know... UFO XCOM and so on..).

I think I found 3 or 4 projects, and at least two of these died horribly, as far as I can judge.

I dont remember what it was... talon? or maybe Project Xenocide. They moved to XNA and .NET and basically made it a Windows game, after a sleeping hiatus for many many months. I stopped looking at how it developed after I realized that UFO:AI not only works on Linux, but it also had resolved so many more issues without the crap that blocked that other Project for months (there was quite some aggression about this on their forum)
So from my part, UFO:AI was miles ahead of every other project, plus it had a much more modern feel as well. (Today when I play the old UFO games, they still have a great gameplay, but the graphics often really just SUCK...)

The worst thing that can happen to any project is stalling, i.e. if no work is done to improve it visibly.

So I disagree about the comment with release cycles as such - as long as the project is still improving, even if it improves slowly, there is nothing wrong. Even Wesnoth does have problems here and there to release more rapidly.

[BTAxis]

I believe it's important to release something to the public every so often. It's important not only because it attracts the attention of potential new manpower, but also because an extended gap like the one we're experiencing now creates an awkward situation in regards to support. 2.2.1 is the latest stable build, but nobody knows how it works anymore, because it's been so long. That's not good.

[misiek]

So I disagree about the comment with release cycles as such - as long as the project is still improving, even if it improves slowly, there is nothing wrong. Even Wesnoth does have problems here and there to release more rapidly.

I would't say that UFO:AI improves slowly. It improves very fast - probably it would be problematic to find last day without at least one commit. My concern is that it is developed "behind the scene".

[Kaz]

That's the idea. The 2.3 branch will essentially be a feature freeze, with only bugfix commits. But we can't do that until pathfinding is working, or so I'm told.

A partial freeze, where all features are frozen except pathfinding could do it. Kind of like considering "fixed pathfinding" a feature itself.

Cheers!

[BTAxis]

Go and convince mattn and the other coders. I wouldn't mind.

[Borsti67]

I agree with misiek, there's LOTS of work done, but quite invisible to the world.
The monthly status report on the front page is a very good thing already, and I believe the developers don't have time time to update this more often.

There's a link to the CIA-SVN-Statistics, may be it is possible to show the number of SVN-changes for the last XX days similar to the translation status additionally? This would give a better impression to visitors without the need to write comments manually...?

[misiek]

I agree with misiek, there's LOTS of work done, but quite invisible to the world.
The monthly status report on the front page is a very good thing already, and I believe the developers don't have time time to update this more often.

There's a link to the CIA-SVN-Statistics, may be it is possible to show the number of SVN-changes for the last XX days similar to the translation status additionally? This would give a better impression to visitors without the need to write comments manually...?

I think that those monthly status are enough (it would be even better to post couple of screenshot for every montly update, especially when there are so many changes in UI).  I think that bigger problem is that people can still report bugs and request new features for 2.2.1 version.

[keybounce]

Not really. The thing that has kept us from getting into a release track has been a lack of coders. There are some issues that are showstoppers, and there are only a few people who know anything about that part of the code, and they aren't exactly working around the clock.

Perhaps this is a key issue: If someone new wanted to get into the game, trying to understand how the code works, how its structured, where does what, etc, it's not pleasant.

Simply put: Trying to understand map generation, loading, etc, while tracking down some problems that turned out to be byte order issues for the G4 were a pain, and I put in a hack in the map loader to detect a byte swap.

Trying to understand the map display? I wouldn't know where to start. As of last week the surfaces of buildings all looked crappy, and since 2.2.1 worked, I'm assuming that there's another byte order problem somewhere. (Or has the display system been completely redone since 2.2.1?)

The comments in the code? They don't solve the problem of a programmer who has no idea what they are looking at. Even if they are fine for reminding someone who knows the code what a given routine is doing, the ones I've seen are worthless for someone new to the program.

Maybe it's not possible to go back and get comments like that in in time for 2.3. But if that's the case, then adding comments and internal documentation at that level should be the first priority for 2.3.1.

If you are saying that your primary problem is a lack of coders that understand what the code does, then you need to make it easier for new coders to understand what the code does.

[odie]

I hope that UFO:AI finds a good solid way to improve the game steadily.

2 years ago or something (maybe 3 years ago) I started to look at any projects that tried to simulate the old UFO feeling (you know... UFO XCOM and so on..).

I think I found 3 or 4 projects, and at least two of these died horribly, as far as I can judge.

I dont remember what it was... talon? or maybe Project Xenocide. They moved to XNA and .NET and basically made it a Windows game, after a sleeping hiatus for many many months. I stopped looking at how it developed after I realized that UFO:AI not only works on Linux, but it also had resolved so many more issues without the crap that blocked that other Project for months (there was quite some aggression about this on their forum)
So from my part, UFO:AI was miles ahead of every other project, plus it had a much more modern feel as well. (Today when I play the old UFO games, they still have a great gameplay, but the graphics often really just SUCK...)

Eloz again! WOW! To think someone else other than me knows Xenocide! Yupz, indeed, if u folks know X-force, Xenocide, Lasersquad and many other 4x squads kinda games, u will probably find many of their active forumers here on UFOAI.

Why? Cos they are like me probably: Bored of non updates..... and probably disappointed by total projects abandonment......

The worst thing that can happen to any project is stalling, i.e. if no work is done to improve it visibly.

So I disagree about the comment with release cycles as such - as long as the project is still improving, even if it improves slowly, there is nothing wrong. Even Wesnoth does have problems here and there to release more rapidly.

Wooooo, a Wesnoth die-hard too, shevegen? Me too me too! I have followed em since alpha! :p *5^*

Agreed. Alot of good major open source projects (including games AND applications) has hiccups. Impt thing is the community revolving ard em supports them greatly, dun tear down the coders and managers of the projects! Plus, give tons of CONSTRUCTIVE feedbacks and even offer help or beta testing.

I rmbr even this game called, 'FreeDroidRPG', dunnoe how many of u heard of this diablo-like cutisie hack slash game tat is opensource and very LINUX styled. lol. I love it! Even tat - it has tons of hiccups, yet progress as this project has.

I agree with misiek, there's LOTS of work done, but quite invisible to the world.
The monthly status report on the front page is a very good thing already, and I believe the developers don't have time time to update this more often.

And just like all those projects i have quoted above, this project, UFOAI, HAS alot of work DONE! See my quotes? Yupz. And its not exactly invisible to the world. It is quite visible. Just download version 2.1, 2.2.1 and maybe one of destructavator / muton / my SVN builts, u will see.

So, project managers like geever, take heart! You folks are doing a GREATLY FANTABULOUSLY INCREDIBLE JOB!

Go and convince mattn and the other coders. I wouldn't mind.

*THEREFORE* - Poke poke mattn, geever and gang.....

"A partial freeze, where all features are frozen except pathfinding could do it. Kind of like considering "fixed pathfinding" a feature itself."

This might just be a good idea? Poke some more.

The comments in the code? They don't solve the problem of a programmer who has no idea what they are looking at. Even if they are fine for reminding someone who knows the code what a given routine is doing, the ones I've seen are worthless for someone new to the program.

Maybe it's not possible to go back and get comments like that in in time for 2.3. But if that's the case, then adding comments and internal documentation at that level should be the first priority for 2.3.1.

If you are saying that your primary problem is a lack of coders that understand what the code does, then you need to make it easier for new coders to understand what the code does.

Not very sure if u r a programmer or not in real life, or have done any programming - this might be very hard if this is not your source, and it is inherited since eons ago.

But i do agree, that all good programmers should comment their programming well (esp in C which is modular / sub-routines heavy). This helps others who look at their scripts understand better where went wrong.

However again, like a thread i saw somewhere before - i thnk since the projects been so extensively worked on, far far FAR beyond most amatuers, i believe its better to contribute in areas like beta testing, bugs finding, and probably help with pedias and even learn graphics enhancements.

Then again, there are many more talented programmers than me, so they might see this in a different light.

[misiek]

Yeah, it's not always easy to join project as a programmer, especially such complex as UFO: AI (i consider UFO:AI as most complex and feature rich open source game, am i wrong?).

And we have luck that UFO:AI has so devoted programmers. How long mattn is working on this? For 3-4 years? And did he has at least one break for about 1 month? I'm really impressed that someone has so much time and strength to develop game for free. And of course not only mattn, also other programmers are doing great job.

It's common in open source games that programmers have motivation at the beginning of the project. But with time they are burning or don't have time because of real life. There are many games with much potential, but there aren't finished (like many other ufo clones). It's good that this problem not applies to UFO:AI and i hope it never will.

------

As of problem with old 2.2.1 version. Maybe some solution would be to write some remark on download page, that it's old unsupported version and bugs and features shouldn't be reported for it. And put a link to topics with nightly builds?