User talk:Duke

Revision as of 21:04, 2 December 2012 by Mattn (talk | contribs) (2. Strategy)
  • In regard to the UGV TODO. I will attempt to sum up what I believe is necessary for UGVs to be included in the game. Some of this may already be implemented, and there may be things that are missing or need fleshing out.
    • Art: GUI support, in terms of dropship assignment, UGV equipment and display/handling on the battlescape (including the selection of boxes in mid-air).
    • Code: Pathfinding support for 2x2 units and flying units. This is at least partly done - what's the status?
    • Code: Support for differentiating between soldiers and regular UGVs. They occupy different spaces in the dropship and are not interchangeable in this regard. See
    • Code: Allow UGVs to fire properly, meaning that the point of origin should be placed at the UGV's weapon barrel.
    • Code: Miscellaneous UGV related changes to scoring, autoresolve, experience, summaries, etc.
    • Models: separation of turrets and frames.
    • Models: Animations, including turret rotation and barrel inclination, death, movement, etc.

--BTAxis 23:44, 19 June 2010 (UTC)

Pathfinding support for 2x2 ground units is in place, but untested and disabled. I'm very uncertain if the flying code will work.

I see 4 milestones:

  • skirmish minimum
    • automatic assignment of one UGV as the 8th soldier
    • some default equipment for the UGV
    • NO turning turret, NO correct origin for firing
  • skirmish expanded
    • assign it as the *9th* soldier
    • adjust muzzle height
    • add turret control
  • campaign
    • variable # of UGVs per mission
    • dropship assignment, UGV equipment
    • changes to scoring, autoresolve, experience, summaries, etc.
  • full support
    • 2x2 spawnpoints on all maps

We have a few maps with 2x2 spawnpoints, eg. I tried to automatically assign an UGV to the team, but failed. Then I was distracted...

(Duke 20:44, 20 June 2010 (UTC))

africa now has 2x2 entities, too - and the skirmish game mode is updated - you are now able to spawn ugvs. have fun with it ;) please also see css.displayHeavyEquipmentList - this is something that should be fixed, extended or removed.

--Mattn 13:26, 26 June 2010 (UTC)

The next ToDos:

  • Spawnpoints
    • Not all the maps have 2x2 spawnpoints. It will be needed to test pathfinding to have at least one point per map.
    • [done] The existing spawnpoints are not always configured correctly (like the one Mattn fixed for fighter_crash in r31866). Is there a nice way to check them before doing a rollout to all maps ? Edit: there aren't so many. I'll do that.
    • Is there a minimum for the number of spawnpoints for all maps ? A maximum ? If so, how do we transport that information to the equipment screen ?
      • farm heracles has only one 2x2 spawnpoint
      • farm raptor too
      • harbour map too
  • Skirmish setup
    • The number of soldiers is persistent, the number of UGVs is not.
    • The UI allows to set up 8 soldiers plus 2 ugvs, totalling 10
    • Entering battle with 7 soldiers and no ugv: 8th button is greyed, but hovering over it displays the 7th soldier. Edit: of the previously shown soldier (can be any).
  • battlescape
    • the ugv model is not displayed where pathfinding thinks it is. Should be in the middle of the 2x2 box.
    • the 2x2 cursor is centered around the position of the model (probably a consequence).
    • the ugvs carry normal weapons ?? ie. plasma/laser rifle ?
    • we'll also need a specialized inventory screen. Or what's the holster of a ugv ;)
    • IR goggles on an ugv ?
    • ugv can turn, but not (yet) move of course.
    • shooting a civilian causes return to menu
  • crouching
    • current UI allows ugvs to crouch/uncrouch, consuming TUs
    • What's the height of an ugv ? The model looks about the height of a crouched human. The height has a big impact on
      • LoS
      • LoF
      • pathfinding
    • An easy way out might be to consider ugvs as 'perma-crouched', taking the movement penalty for crouching.

--Duke 21:04, 25 August 2010 (UTC)


Some thoughts about priorities in a project. Imagine the following scenarios:

Scenario 1: The complete devteam has left the project. Some rookie devs took over. After a year or two you come back and find *everything* is broken. In which order will you start to fix things ?

Scenario 2: There is no UFO:AI project, but you want to create one. Where do you start ?

Not too surprising, the order is the same in both scenarios. Arguably you could also start with prio 2 (The Plan) in scenario 2 and write it down on paper.

Note that some very important aspects like 'internal communication', 'external communication', 'organization' and 'marketing' are not slotted in here because they depend on other factors (size of dev team, # of users) and can not be compared directly to the priorities listed below.

Also note that priorities are applied on a per person basis. That is, if the project has a 'prio n' problem and you are not the person to do anything about it, you can of course move on to a 'prio n+1' problem, unless the guy(s) working on the 'prio n' problem ask you to keep certain areas of the project constant (eg. feature freeze).

1. development tools

Compiler, debugger, profiler, IDE, repository, various editors and test infrastructure for all supported platforms.

Reason: without your tools you can't accomplish anything.

2. code structure

Design, file structure, coding & doc guidelines, technology & gameplay strategy

Reason: Without a good plan, your work will end in chaos. At least in much duplicate work.

3. checker tools

Compiler warnings, cppcheck, valgrind, helgrind, doxygen and automated tests (cunit).

Reason: many tools can sometimes give you hints to hidden bugs. So before starting to hunt a bug, you will want to make sure that none of the tools already 'knows about the bug'. This is best achieved if there are no warnings whatsoever from all the tools.

4. patches

Keep the patch tracker clean !

Reason: It saves us some work on bugs & features. And although applying a patch can be more work than fixing the bug yourself, it's worth it, because that's what 'prospect devs' usually start with. Ignoring the patches they send in for too long discourages them.

5. bugs & features

That's what it's all about. We want to add features to our application and make sure that it works. My personal reflex here is "kill ALL the bugs before adding the next feature". But that's definitely WRONG. Users tend to accept a certain amount of bugs if they get the desired features. And they don't accept if the dev team spends ages to fix some bugs that 95% of the users never encountered. So it's a rather delicate *balance* here, and I can give no rules for that balance.

I only know that

  • both bug reports and feature request should be *treated* somehow. That is, assigned to a dev that is qualified to at least accept or decline it.
  • bug reports with high priority values are really more important than new features
    • In some cases, though, bugs require specialist knowledge (renderer, pathfinding) or we simply don't know how to fix them. In these cases, feature addition shouldn't necessarily be held up while we wait for a fix. Also, developer motivation is a factor in a volunteer project. I fully support your push to get the team more focused on bug-fixing. But people need to enjoy their work some, too. --H-hour 03:46, 23 November 2012 (SAST)


1. development tools

We have no easy to use and install IDE for Windows. Don't know about the other supported platforms.

2. Strategy

We have no written-down overall strategy. Our current strategy seems to be "fix a little here, add a little there, release". With one exception: the gameplay strategy seems to be to move the endgame further into space step by step and add the features necessary for that.

you've seen our Roadmap? --Mattn 23:04, 2 December 2012 (SAST)

3. Checker tools

We have many of them, starting with the compiler warnings. But nobody seems to be willing to care much.

4. Patches

As of today (Dec 2nd, 2012) we have 17 open patches, some of them dating back 2.5 years.

5. Bugs & Features

We manage to fix nearly as many bug tickets as are reported. So the number of open bug tickets tends to increase slowly, but steadily. We should find a way to make it drop.