project-navigation
Personal tools

Author Topic: Communication strategy  (Read 9779 times)

odie

  • Guest
Re: Communication strategy
« Reply #15 on: May 19, 2009, 11:20:28 am »
OK, agreed. Wesnoth is simpler. Maybe they also have more resources in terms of contributors (why?).

UFOAI has made the last release one year ago, though there are people working on it constantly. (Wesnoth released 1.7 today).

Fyi, 1.7 released today is DEVELOPMENT's Built. So, its not an official stable release. If u read the change logs, u will notice that they are already 8333 lines (including space in between) of changes. They are established in terms of frameworks and a modding kit. They also have a wide circle of ppl who speaks diff languages - resulting in a lot of updates.....

If u have not noticed, YET, UFOAI is still undergoing heavy framework-related programming, tweaking, and at this point, they are actually UPGRADING the frameworks, as compared to WESNOTH who has decided to retain their simple framework.

IF YOU have been playing wesnoth long enough (which i hope u did), u will notice that their AI is good, but gameplay is otherwise simple, with hardly much 'micromanagement' parse.....

UFOAI? On the otherhand, has IMMENSE controls to take care of - from 3D (which btw is WAAAAAY harder than 2D gif file programming) Geoscape, 3D rendering of battlescape, 3D graphics, 3D animations (notice the amount of 3Ds here.... each one can kill someone), AI, base control, soldiers' control, research trees, scripts, and i can go on and on and on........

If tat all is compiled with the changelog in just 1 line per change, we are already at 24460 (that is TWENTY THOUSANDS, FOUR HUNDRED AND SIXTY) changes already........ that is IF you still want to compare.




I offered my help to get my hands dirty and take the communication to the Wesnoth level, but they rather stick to "Battlescape fixes and updates, including actor movement smoothness, ability to move multiple actors simultaneously, weapon balancing work, TU calculation fixes, bsp light loading and reaction fire fixes." (obviously I am a bit displeased).

Well well, if u really are helping as much, take a peek at Mattn, BTAxis, Destructavator or some of the deepline programmers / soundsman / map crafters / AI scripters / graphics developers / translators......

Have u seen em whine? I dun thnk so......

Imho it's fair to compare UFOAI to other OSS games, they all work under the same conditions, be the app simpler or not. "Doing well" certainly applies to programming (and I really appreciate their work), but to communication/management?

Ahem. Well, have u come across any OSS (Open-source software for the uninformed.) game with this level of programming? Dun thnk many..... and if u can name a few which u thnk are above this level, let me know. I be O.o o.O O.O  why? Cos i am very faithful OSS gamer. For all u know, I might be surprised why they are.

Hmmmph.
IMHO said. (Thats "in my humble / haughty / hungry / hectic opinion" - take ur pick).

bonndan

  • Guest
Re: Communication strategy
« Reply #16 on: May 19, 2009, 11:45:10 am »
Fyi, 1.7 released today is DEVELOPMENT's Built. So, its not an official stable release. [...]

The point is that they release - keeping the goal in mind to deliver a game for end users. Your 24k changes without an intermediate release (if I understood you correctly) is probably not something good.

The work of a story contributor for instance will not be released to the public (and reviewed by the users) until the latest 3D XYZ routine in the new framework is working. No maintenance release or branch (to develop a version with the new framework) is present (or I missed it).

Yes, I whine.

Offline Borsti67

  • Squad Leader
  • ****
  • Posts: 164
    • View Profile
Re: Communication strategy
« Reply #17 on: May 19, 2009, 06:56:06 pm »
A little problem that I noticed is that there's not a clear line or even better a unique medium of communication.
Some of the devs read the forums, some are mainly in IRC, others could have even other likings (may be reading the trackers).
IRC may be nice for direct contact (even if I personally don't like it much) but it's like a chat hard to read and especially absolutely inefficient in case you want to know if sth has been discussed etc. Searching the logs is just a mess!
The forum on the other hand is a good source for information because it's more (kind of) structured and searchable, but requires more reading and "discipline"; perhaps a little difficult for s/o not native English speaking and/or used to chat without punctuation...

I'm not sure how to combine this?

Offline Duke

  • Administrator
  • PHALANX veteran
  • *****
  • Posts: 1037
    • View Profile
Re: Communication strategy
« Reply #18 on: May 20, 2009, 12:03:36 am »
Are you, as an end user, really looking for "monthly updates"? Do you really want to read the summarised SVN commits?
Yes and no.
If I were an end user, I'd like to see:
- beta(sometimes alpha) releases every 1-4 weeks
- a list of the bugs fixed in that release plus even small new features that are significant to the user
I wouldn't want to be bothered with their lives nor with the technical stuff they do for me.

Offline BTAxis

  • Administrator
  • PHALANX Commander
  • *******
  • Posts: 2607
    • View Profile
Re: Communication strategy
« Reply #19 on: May 29, 2009, 02:53:56 pm »
The website was recently added to the SVN repository. I believe this means that anyone with a will to seriously overhaul how it works is now at liberty to do so.

bonndan

  • Guest
Re: Communication strategy
« Reply #20 on: May 29, 2009, 03:18:42 pm »
The website was recently added to the SVN repository. I believe this means that anyone with a will to seriously overhaul how it works is now at liberty to do so.

Thanks for your efforts.

I had a quick look at it- it is exactly what I expected. If you stick to this, you will be lost.

If you dont want to mess around with a full-blown CMS with database, I suggest you have a look at http://www.pivotlog.net/ (I used this some years ago). Just sftp the files to SourceForge or Ninex, edit the config file and you are ready to go.

I cannot do this myself because of lacking privileges, but I can offer to port the current stylesheet to pivot as well as most of the info in SVN. The same applies to WordPress or other CMS.


Regards

Daniel


Offline criusmac

  • Squad Leader
  • ****
  • Posts: 168
    • View Profile
Re: Communication strategy
« Reply #21 on: June 02, 2009, 10:14:11 pm »
Criusmac had more determination (time?) than I did to actually get involved, but reading his post it seemed like he was fighting obstacles to try and help.  I think you are losing a lot of potential help. 

Woo hoo! I got mentioned! Err, really fast that. I'm not sure I'm involved even yet. I'll consider myself involved if I successfully manage to create a patch. What I did though was see an obvious, but somewhat complicated problem that needed to be fixed, get some additional info from the person who wrote the accepted proposal (of visibility), and then hunted around the source for other code that did what I wanted to do. A few copy/paste later, and I've at least started, though it sure isn't pretty. I still suspect this is beyond my abilities, but I suspect the worst that can happen is I fail, and nothing gets done. At least the ideas posted seem better than they originally were, in my opinion anyway, which means time wasn't really wasted.

- Pretty much everything a player will see is focused on 2.2.1 which is over a year old.  Its pretty obvious once you hit the forums that 2.2.1 is barely a memory in anyone's mind, but if you don't look at the forums you will hit up an incomplete manual and fiddle around with 2.2.1 and thats it.
If a dev release works decently well maybe make a note of it on the wiki with some comments on where it will break so people can try a dev version without trying to figure out which ones could potentially be playable.
My attempts to generate a patch are a bit different than the requested method of grab the latest dev version, and apply the changes directly to it. I decided to do my work on the stable version directly. I decided this since my changes (visibility) do not exist, in part or whole (as far as I know) in the latest dev version. It's a bit riskier since the code is a good year old, but I don't have to worry about any of the latest bugs that may have cropped up, or been fixed. I don't have to download dev versions and test my code against them (yet). Since I know where in the branch I got my files from (2.2.1), a merge patch is possible which means it should be easy to merge my code into the latest development version when I'm done (free tools exist to do this). Once that's done, I can see if my code still works. So, for me, having a stable release is all I need since if something goes wrong, it's probably a bug introduced via my code, and will be easier to locate and fix. There's a lot of assumptions I'm making here and there, but for the most part, any assumptions I make don't actually change anything. For example, if it turns out I can't merge my changes into the latest development release, I'll just download the dev release later, and manually merge my finished changes in. Still a lot simpler than developing on the dev release itself. Maybe this would work for you as well?

- The technical area of the wiki looks like my personal wiki.  Stuff is all over, linked to all over.  Its completely unclear what is current and what isn't and most of it has a large amount of assumed knowledge associated with (its not wikified).  This works fine for my personal wiki, the directory is password protected and no one other than myself should ever see it.  It probably works fine for most of the developers here, but it is a heck of a hurdle for someone trying to learn.

I gave up with trying to learn anything general about what people want done. I picked a task that I felt was needed in the game, and I'm concentrating on it alone. I saw the wiki, but I don't think I did anything with it. The proposals page (http://ufoai.ninex.info/wiki/index.php/Proposals) is a great place to find something you want to do, and I'm really lucky what I wanted to do happens to have an entry.

- I don't know about a CMS, I mean the monthy updates are great but what else are you going to put there?  The daily SVN logs?  Forums are fickle, information gets lost and few new people read anything but the stickies (if that) unless they are searching out something specific.  I would try and make the wiki the focal point, make the main page updated with current notes and have at least all the pages that link from the main page be well designed and up to date.  There doesn't seem to be a whole lot of activity on there though.

The forums are absolutely horrible to search through here. Things I saw by randomly reading I can't find again even with a few keywords to help. The wiki does seem like a good focal point, but it should be accessible from the forum page somehow via a link. It would have saved me a lot of time if I had known it was so connected to the forum's ideas. As for updating things, it might be possible, but I can't imagine a quick and easy way.

Anyways I am trying to be constructive I hope no one gets offended; I am probably not saying anything that is new or that anyone doesn't already know, but thought it might help.  I am software engineer and am just finishing up two months of documentation work and just about want to kill myself (which is why I was hoping to jump in and start coding something neat), I know the pain of trying to write junk to explain complex things to people who know nothing.  If I can motivate myself maybe I will try and start doing a 2.3 user manual on the wiki or trying to figure out what needs to be update and how it might better be organized, it would be a good project for learning to code and figure out how things work and what needs to be done...

I personally don't see how a 2.3 user manual will help until 2.3 is a stable release. This user manual you suggest is for people new to the game, right? If this is true, then they should be playing the 2.2.1 stable release anyway. Playing a dev release is, well, ugh? (ugh = bug ridden, crash prone, unbalanced, and who knows what else). What drew me to this project is the eye candy, game play, complexity, and probably a few other things, like todos. I like complex things, as can probably be seen in my own terrifying posts. It is tough to pick a starting point, but mine I saw from within the game itself (and it bugged me), so it was easier for me. Whether or not I can do it, only time and luck will tell. My suggestion is similar to others here though. Download Code::Blocks and use it since that's all people seem to use here. Once you have successfully compiled the code, you can start changing it, and hopefully it'll be improved when it's done. Doesn't have to be big, doesn't have to be complex, I'm sure anything you do will help out, as long as it works properly. I like to keep a d20 (20 sided die) around to help me make decisions like this.