Topics

1

Offtopic / Goodbye

« on: October 08, 2015, 05:06:46 pm »

Just few last words before leaving.

When I found this project, it was late 2010, and it was version 0.1 on SourceForge. Daiky joined a bit earlier and made his battlescape, and started his walking tests, enjoing "ultimate A* pathfinder" (which was kinda bad, frankly speaking, because unit shouldn't be able to route through black "unknown" areas). There were no projectile sprites, and Daiky didn't even know how does it work in vanilla.
UFO: The Two Sides at this point have been using point-sprites instead of projectiles, and it looked really lame. I remember I thought OXC really should be using original looking projectile sprites.

At this point I was on my "active" phase of reversing vanilla exe, figuring lots of the game mechanics, and searching for the good use for what I found.

For OpenXcom there was no any reliable information source on the inners of the vanilla. The only source was ufopeadia.org. Which happen to has really lots of "blind spots" and even misinformation. I start filling these blind spots and correcting
the misinformation, but it was just some bits of info - there was much much more which I didn't put into ufopeadia, just because I stop seeing any reason for that. I thought it would be much more profitable to put this information into actual project, so I started providing OpenXcom with information on vanilla mechanics.
First thing, of course, was projectile sprites, and of course, taken from reversed vanilla.

The "clarification" on title(and "about") pages stated that "The code is completely written from scratch, no reverse-engineering" . It was true at that moment of time, but. Later this statement was removed. Because without reliable real reversed source the project most probably would end up with ugly "something" that just only resembles the look of vanilla game (as it was in the beginning). It would end up like lots of other "clones" which barely touches the fame of the vanilla. And I thought, that it would be really shame. And other developers may not agree (so excuse me), but I *actually* took a role of the "accurate vanilla" game designer of OXC. Because https://ufopaedia.org was (and is) really poor "map and compass" on many of vanilla aspects.

During this long run I supplied some of OXC contributors with vanilla info.

- SupSuper. Started everything, made ALL of UI things, and the engine "skeleton". Always avoided maths and ingame mechanics programming, like, globe, or battlescape. UI - is just what he's good at. I didn't really provide him with anything important, can recall "nice" great circle flying formula for geoscape and later - dos/adlib music player, which was added just couple of months pre 1.0 release. And what's the good - he continue making fix-commits (mainly gathering community PRs, and some other current fixes).
  Ah yes, he "integrated" radar range circles I made. Cheers, chief.

- Daiky. Started battlescape stage. With the idea "will go my own way" he didn't manage to go too far. I gave him projectile sprites, pathfinding/MCD info, and tried to turn him into more vanilla direction. I think in current codebase there are only few bits of his code left. Mostly it has been rewritten number of times.

- hmaon. The guy who added classic intro sequence video, nice scaler/shaders, and later - some AI logic. I provided him with SFX channel info for intro and some AI concepts from vanilla.

- Karvanit. Added alien missions/flight mechanics, that SupSuper mistakenly called Geoscape "AI". No wonder because there was almost 0 info about that in https://ufopaedia.org, and people could have illusion that it actually has AI. No. It's just scripted without any signs of "dynamic difficulty" that Julian Gollop mention.

- l2uriel. With my help and information provided he has implemented dogfights with nice and vanilla looking blob animation and dogfight mechanics itself.

- Warboy. Without him and my help I really doubt the project would hit 1.0 by now or in any close future. I gave him tons on vanilla information, starting from unit sprite drawing, and bunch of fixes of battlescape mechanics (but still PR+committed by Warboy - I never got to use git). He made this project this far as we see it. Map scripting was entirely my idea and concept, and Warboy implemented it quite well (without these "scripting" concepts TFTD support wouldn't happen, because it was initially hardcoded). I actually gave him reversed vanilla sources of XCOM1 and TFTD, and spent hours on explaining of numerous of the vanilla mechanic elements, and function logics. Mission scripting tho is entirely his child, so cudos are entirely his.

All in all it was pretty productive cooperation of Warboy's coding enthusiasm and github access, and my reversing/logic skills, patience and persistence, and of course, the learned vanilla reversed source which I was making and improving from 2010 up to 2014 (including TFTD). But due to his uni stuff, or some elements of laziness, or maybe it's something personal, or both, he rejected number of my offerings (including actual code snippets). I can't get to work with git/PRs, I don't want to get into the situation when my potential huge PRs gonna be "rejected", and obviously I didn't want to start my own project fork like Yankes, with all the "autobuild" and stuff support. (Sidenote: Yankes, you're really stubborn sonovabitch, you're doing freaking great job fighting for your own game engine vision, which I couldn't afford).
So I stop giving Warboy code snippets and fixes, and stop doing anything for OXC at all. Assume that as like I got tired of hitting the wall trying to lobby any progress.

What directly was done by me:
- Radar lines (floating point line draw functions are also used for craft trajectories).
- Adlib music player (working for both xcom1 and tftd).
- First-person look aka "F10" (useful for finding holes and "missing" reason) and full voxel dump with "F11" (for debug only). Started because of "Jade's skyranger hole".
- Terrain damage mechanics and spreading of explosion (considering advanced bigwalls).
- Vanilla-like throw trajectory limitation (for standing and sitting, for the ceil blockage).
- Holeless LOF (covering diagonal jumps found in lots of vanilla crafts and buildings).
- Spacial correct projectile shadow (considering slopes and stuff under).
- Geoscape "astronomically correct" Earth tilt and shade gradients.
- MCD Editor - started as simple MCD viewer after I got into Win7x64, and found that Koralt's version (I used to) doesn't work anymore.
- WORLD.DAT editor - not really worth mentioning, but still.
- Smoother/slower bubble trails are also under my responsibility. With vanilla speed it was too fast and you just can't enjoy the look.
Indirectly:
- Projectile "sprites", implemented by Daiky.
- Great circle formula for globe trajectories, implemented by SupSuper.
- Alien mission/trajectories/loadouts, implemented by Karvanit.
- Detailed information on bubble trails, palette, and other stuff from TFTD, implemented by Warboy.
- "Advanced" pathfinding through bigwall proof of concept, later implemented by Warboy.
- Map scripting concept (with proof of viability for both xcom1 and tftd and potentially any other mod), later entirely implemented by Warboy.
- Accurate information on map generation, trajectories, races/ranks/loadouts for TFTD, implemented by Warboy.
- Accurate information on special terror mission spawning for TFTD (which doesn't have anything in common with UFO:EU), also, Warboy.
And lots of other tiny things I don't even remember.

And just gonna list few things that I was working on, some of them were WIP, but some were actually finished but nevertheless they were rejected.

- Smooth globe. - rejected
I've tried couple of different approaches and found the best one. But still, it hasn't been approved. So I guess you'll never see it. A video of it.
- FPS independent window popup animation. - rejected
Really quick and smooth in any CPU/GPU configs. It was just ignored. So if you're unlucky - you know why animation is slow: it's FPS dependent.
- List highlight line misposition bug fix - rejected
- Optimized "over globe polygon" function - rejected
It meant to allow of automatic dogfight window opening after "can't intercept over the land" popup.
- New version of GLOBE.DAT editor.
Was already finished, can load/save trajectories, areas, cities (from yaml ruleset), and visually edit all of them. Just cancelled.
- MCD Editor updates.
The version 1.17i gonna be the final, despite any bugs or anything else.
- Natural targeting.
You know the thing. It's just something that was simply aborted. So get your 50% "obstacle hit" chance even with 110% accuracy aimed shot.

And more of other quality of life things, that were planned (some were even drafted), but actually never gonna happen (like "particle engine" easing flamethrower animation implementation, like multiple projectiles for shotguns, fire/throw preview, and more from here).

I'm really glad that project got to this point, so lots of people could enjoy playing good old XCOM and TFTD. I'm glad that lots of people are making mods of their dreams, using the OXC concept of externalized game assets, and even some of my tools. And I'm glad that some of developers earned lots of cudos and moments of fame.
But personally I feel being exchausted, feel being used, and feel that I didn't really gain anything. I just feel I spent part of my life for almost nothing, which I could spend on something better, like doing my own stuff, and hitting no walls.

So... Goodbye, OpenXcom community.

2

Programming / Aiming algorithm

« on: March 02, 2015, 07:59:40 pm »

I know it's internal thing, but I still want to share my thoughts about aiming algorithms used in OpenXcom.

As I remember, initially (when Daiky started Battlescape) OXC was using simplest method of choosing the voxel to hit. It was either the middle of unit, or 3/4 of the height (to target the chest/head). Just two points. Yeah, that simple.

Then I changed that, made something vanilla alike, but with more precise height scanning (in vanilla it's 4 different height levels, and I made it scan each 2nd voxel). For each height level, starting with the middle, it tries 5 different inner voxels - central, and 4 at each side (depending on unit width, at the north, west, south, and east side).

After that I thought that I might scan unit more "optimized" way, using trigonometry, and turning target "plane" facing towards the shooter. So I had to check only 3 voxels instead of 5, for each level (plus top and bottom).
And it's how it works right now, pretty optimized, imposter-like shooter-aligned plane.

But in fact, it heavily suffers from the "obstacle" factor. In short - it always choses the available target voxel closer to the center of the unit. Even if it's next to wall or fence. So it often happens, that shown chances (which might be even 110%) doesn't reflect the reality, just because there are chances to deviate 1 pixel aside, and it will hit obstacle.



Target at the right will be hit with much more chances than target at the left, inspite of exactly the same distance. Because of obstacle issue. Random deviation is shown with highlighted ellipse. Without any obstacles it would be 100% chances to hit. But in fact, it will be 80% for the target at the right, and just around 30% for the target at the left.
It often happens when target is above and you're shooting and hitting the roof tile (which is obviously almost impossible, because you see only 1 voxel of the roof, being at the ground level), or targets at the corners. Sounds familiar?

I want to change that. I'm experimenting with aiming algorithm which gonna target the most visible part, not just the center.

Here are 3 different scenarios, blue is an obstacle or "miss", number is an aiming weight value. The more the number, the more chances this target voxel has when aiming.
First two are from the example above, and the third is "target behind the fence" (which is also often the case).



With these changes made, you hardly would be able to hide over the corner or behind the gear. Neither aliens. So battles will become slightly more brutal, and quicker. But hey, isn't this "dumb miss" the thing you always wanted to get rid of, and was often pissed off about?

3

Suggestions / Quality of UI life

« on: January 05, 2015, 12:15:55 pm »

OpenXcom is famous for its QoL thing, which is essentally one of main goals of this project.
Visual scrollbars, mouse wheel scrolling lists, mouse wheel swithing battlescape levels, hotkeys, etc.

I have a list of another QoL UI adjustments and suggestions. And want to fill/remove/discuss it (it was taken from inner todo list).

=======================
1. "Manufacture categories" is not used by the most of players, but it steals list space and makes almost ZERO use, statistically speaking. So it should be disabled by default, but for those few who need it - leave it in the "advanced options" (off by default).

2. Make proper use of Shift/Ctrl as modifier keys, instead of "process as ordinary key". Tab/Shift-Tab is conventional way of switching between things, and we have tab/shift, which looks like it simply raw and unfinished thing. And previous unit should be as Shift-Tab, not just Shift. And inventory copy/paste should be not just C/V, but Ctrl+C/Ctrl+V, because it's CONVENTIONAL.

3. Implement proper drag'n'drop style for items and drop down menus (LMB down, moving to entry, and LMB up to switch). I don't think it worth discussion because it's conventional modern UI style. Item drag'n'drop tho is tricky, because classic xcom style also should be working "by default". It's better to make it autodetectable (by mouse moving beyond some threshold to "untie" and switch into d'n'd mode).

4.(easy) Make RMB for selling/transferring/buying screens work not as max/min but increasing/decreasing by 100. When you have 1000 alloys, it's pretty unhandy to scroll it to sell 500. Mouse wheel as increasing-decreasing values is not good advise, because it screws solid concept "scroll is always scroll", can cause accidental value changes, thus multiplies mess. It's bad to mix different things into single control. It's not how UI should work. As alternative - make Ctrl/Shift modifier key to work as scaler, i.e. change values by 10 instead of 1.

5.(easy) Add total expenditures into base info screen, showing expenditures of all project, not just selected base (there are plenty of space to add it without messing).

6.(easy) Make inventory screen "copy/paste" layout buttons static. Why? 1. Because there are no dynamic buttons in the Xcom UI. Making exception leading to mess. 2. There's no need to show either it filled or not, since it "saves" layout only during single equipment session, and there's no need to mix "paste" with "clear". Mixing things into single control is a bad UI design, as I said earlier, and it's not "my" vision, it's conventional QoL thing.

7. Need to add fast forward for walk animation. "RMB" as "fast forward" for firing was spontaneous choice, without consideration of the walk (RMB works as abort walk). Suggestion: Make "Space" button fast forwarding any animation - either firing (projectile, grenade throw), or walking (make walkers speedup their journey). RMB as cancel of long action - abort walking (as it was), and stop burst fire. Burst fire cancellation should work with the less impact on the gameplay, it shouldn't restore any TUs (it still will be spent), and perhaps, all bullets still gonna be spent. Cancelled bullets aren't gonna make any damage. The point of burst fire cancellation is to lessen "damaging" effect of fire misclick. Changing RMB behaviour for the fire is bad, but changing RMB for the walk is even worse, and leaving them not matching is bad too.

8. Make hint for each dropdown entry, not just single hint for the whole dropdown list. Because, obviously that 2 lines for 7 entries is not enough. Will need of translation work.

9. Mod descriptions (for EN-us by default and for each language optionally). Damage formula, as gameplay element, should be transferred from the advanced options to mods (because tftd has tftd formula and ufoeu has ufoeu, as default).

10. Make it possible to change unit positions during pre-battle equipment and show actual unit locations (small thumb-like top view) in the craft, considering tanks. Perhaps make tanks relocatable. For the base "craft eqipment" screen, and perhaps, for the pre-battle inventory too.

11. Fix the mess with fire/walk confirmation thing. Currently Path preview is tied to walk confirmation, and fire confirmation doesn't have any kind of preview. Need to split these options to "Confirmation"  and "Preview". Preview without confirmation should work in "hover" mode, with, like, 200ms delay if mouse is still or something (not to overload CPU when moving cursor around). Preview of fire can be done with using "projectile" rendering technique just with "dot sprites" spreaded through the trajectory, including throw parabola. Confirmation is needed thing for touch devices (walk preview, walk confirmation, fire preview fire confirmation).

12.(easy) Grenade indicator should blink not only in inventory screen, but in the battlescape panel as well (in hands).

13. Make it possible to drag item, and while holding it at the cursor, switch unit, and put at the other unit's slot, without using of ground. Also switch items if "dropped" one over another. Conventional inventory works like that. During actual battle these manipulation tweaks ain't gonna be working tho, it's only for pre-battle equipment, like copy/paste thing.

14. Add support of modular fonts (to make it possible to add extra alphabets without replacing "classic", and add exotic thai, japanese, korean and chinese "fonts" + make UI elements "rulesetted" (bigger line heights, etc).

15. Dynamic hint texts. Hint over the left/right hand slots of the panel should show item name and loaded ammo type/bullets left (instead of irrelevant Captain Obvious stuff like "Use Left Hand Item"/"Use Right Hand Item"). Also show grenade charging state/turns and Medikit P/S/H numbers. Kneel/unkneel hint of the respective button should show current state. Same for move up/down. It should show current level. Perhaps same for camera up/down. End turn button should show current turn number. Main purpose - is to make hints more indicative and useful.

16.(easy) During pre-battle equipment "unload" should work even if hand slots are occupied, and in this case spread ammo/weapon to the ground slots. When hovering over the weapon - it should show ammo type/bullets left within the hint (as with previous #15).

17.(easy) Ufopaedia available from the tactic screen (to see weapon/ammo/item properties). Perhaps replace "MultiLevel view" with ufopaedia button.

18.(easy) When moving items between slots in the combat mode (not pre-battle), it should show NUMBER (TU cost) at the corner of the cell you're trying to drop to (when hovering), with "dim", not contrast color.

19.(easy) In pre-battle screen (perhaps just at the base), when clicking into paper doll image (square area in the chest), it should allow to change armour. Also when moving mouse over the paperdoll, it should show armour type as HINT.

20.(unnecessary due to #15) Unhardcode selected unit arrow and animation, make it rendered from the spritesheet of 16 sprites (8 animated frames for standing and 8 for kneeling), similar to "pathfinder" sheets. And make "kneeled" arrow look slightly differently (either color or shape).

=======================

Any thoughts?
P.S. This thread is not about how to make game more moddable, or friendly to modders. It's entirely about user interface.
And it's not about "what should be done till next milestone". It's just list of things that should be achieved during project development. Some of them are easy-achievable, some are of pretty long-run.

UI rules:
- Not to make visual mess (not to overload interface with small elements), irrelevant chars or colored signs - they are simply not intuitive to decypher.
- Not to overload mouse/key actions with additional meaning for different screens, because that intuitively confuses and seeds wrong habit.
Gameplay rules:
- Any UI changes should be done in the a manner, minimizing implications on gameplay.

4

Offtopic / forum css

« on: December 01, 2014, 11:42:48 am »

Hey!

What happened to forum? Links in the quotes are barely visible.



Instead of changing nice grey color it would be better to add underline or at least CHECK in different circumstantes before applying.