Messages

541

Programming / Re: Battlescape development

« on: March 11, 2011, 03:54:18 pm »

Although most bugs in the git build are due to work in progress, anyway thanks for the bug reports.

I'm currently refactoring a few classes and relations. Because I now have some new insights that I didn't have earlier on. For everyone who is interested... read on.

Removing:
UnitSpriteRule - since this data is directly linked to graphics it makes no sense to have it configurable for now, it just complicates things.
MapModel - there is not really an added value to keep track of all individual models of map objects after all, voxel data will be looked up directly in the loftemps data.
Adding:
RuleArmor - holds armor value for different types of armor, including aliens' armor
RuleUnit - holds initial stats and other unit specific data for both xcom and aliens
RuleSoldier - RuleAlien
Unit - abstract class that is used as an interface to both Soldier and Alien
Alien - the counterpart of Soldier, but for aliens. It doesn't hold any data, but looks it up in the associated RuleUnit
Changing:
Soldier - implements Unit, although this changes nothing on the geoscape side.
BattleUnit - holds pointer to Unit.

The philosophy behind this construction is driven by the idea that an x-com soldier is a unique entity, existing both outside and on the battlescape. An alien is just a pointer to a ruleset.
The advantage of using the abstract Unit class, is to simplify the usage on the battlescape. For example you want to get a unit's name, you do: unit->getName(); and depending whether it's an Alien or a Soldier, it will call the appropriate function.

Note that BattleUnit is not a descendant of Unit, this is intentional. Otherwise if a Soldier enters a battlescape, the Soldier class should be "morphed" into a BattleSoldier class, this is tricky business and especially hard to maintain - if new attributes are added to the Soldier class. So for each Unit participating in battle a BattleUnit instance is created which holds it's corresponding Unit pointer.

As a rule the Alien class counts for all NPC units: so including civilians. The type of class does not define whether a unit's AI is hostile towards x-com. This is taken care of with a "faction" attribute : friendly, neutral or hostile.

542

Suggestions / Re: Scrolling

« on: March 08, 2011, 07:59:57 am »

It's doable. I'll put it on my list.

543

Suggestions / Re: 'Undo' option?

« on: March 08, 2011, 07:57:11 am »

FYI, right-click to cancel movement is already in OpenXCom. It doesn't affect gameplay -not in a bad sense anyway.
I don't feel like it has to be an option, because purists be warned: don't rightclick when your soldier is moving or it will cancel it's movement :p

But the two-click unit movement (one click for visualisation of the route, one to start walking) on the other hand should be an option.

544

Offtopic / Re: How x-com 3d should look like

« on: March 07, 2011, 11:40:06 pm »

I think it's not the way xcom3d should look like. First of all tiles are too big. Second of all - there's too heavy shadow outthere, and "action' gameplay aimed for single unit. So, no. This engine and gameplay doesn't seems to be having necessary tactics inside. It's more like alien shooter.

I agree with the tiles issue. Well it's more like a mouse-cursor issue, in a 3D game you should not be restricted to "tiles", you should have a 3D mouse cursor that you can point to every coordinate you want. In this demo for some reason the mouse cursor matches the texture of the floor plane.

This is how a 3D strategy mouse cursor looks like: https://www.youtube.com/watch?v=bNJeW9IMj_w
Damn I liked that game, with it's destructable environment and the graphics style.
In my opinion soldiers: heroes of ww2, that engine could even be good for an xcom3D?

545

Offtopic / Re: UFO 2012 for mobile

« on: March 02, 2011, 07:12:22 pm »

If it was on PC, I was interested, but now it doesn't get me excited at all... I just don't like strategy games on mobile devices; I need a big screen and a mouse. :p

546

Programming / Re: Battlescape development

« on: March 01, 2011, 11:49:12 pm »

More good news!

Latest build: projectiles now affect terrain !

To play with I have given the first 3 units of the skyranger a heavy cannon, one with armor piercing ammo, one with heavy explosive and one with incendiary ammo.
Have fun!
Note that the AP ammo does not check object armor versus power - it has like unlimited power.
Also note that damage versus units is not yet implemented.

Weapons of mass destruction:

547

Programming / Re: Battlescape development

« on: March 01, 2011, 03:23:25 pm »

Once you have all this nicely put into objects, you can make crazy combinations like:
After a civilian gets killed by an x-com soldier: set the "civilian group" into state "attack x-com".
And give civilians a melee attack with power 1 :p
"Hey wtf? Stop hitting me! We are on your side!"

548

Programming / Re: Battlescape development

« on: March 01, 2011, 02:23:39 pm »

I'm spending most of my free time on openxcom lately It's getting addictive.

Very simple AI can give pleasing results. Same as very complex AI can look stupid It's all about perception of the player.
You have two levels of AI: the group level and the unit level. And on these two levels you have a finite state machine.
The group levels on the geoscape seem to be zones on the world: "The North-Africa Group", and they are in state's we all know as "Harvest", "Abduction", "Terror" etc.
The unit levels on the geoscape are the UFO's. The are in state "exploring", "chasing", "fleeing", "going towards a base", "shot down".
The group level on the battlescape is just "aliens"... and sometimes "civilians". Depending on the mission the are in certain state: "attack civilians" or "explore" or "attack xcom" or "retreat".
The unit levels are the aliens, and have states "exploring", "chasing", "fleeing", "dead"....
The units each make decisions to stay in their current state or change state depending on all the input they get from "the world", some scripted stuff, some random stuff....
You could implement it like you did the game states. Each state it's own object.

One thing that I have read in some gamedev book, is that when a units changes state, it is interesting to show this as some kind of emotion to the player, and not just by it's behaviour. This really makes your units look intelligent. An example of this is, when a unit sees you and enters the "aggro-state", it screams. Or if it hears something, it turns it's head towards it... things like that.

549

Offtopic / Re: UFO 2012 for mobile

« on: March 01, 2011, 02:01:04 pm »

looks cool. But what's up with the lighting on that last screenshot?

550

Programming / Re: Battlescape development

« on: March 01, 2011, 11:03:55 am »

Hurray, I can striketrough some of my points.
- Got to finally implement the kneeling button.
- Adjust the bullet starting voxel depending on the stance.
- Line of fire collision detection !!!
- Determination of the target voxel.
- Applying firing accuracy.
- Different bullet sprites.
- Correct z-order of the bullet sprite.
- Bullet shadow.
- The impact damage.
- The impact visual effect.
- Sound effects.

Next thing to do is the impact damage, which is a rather essential part of shooting. You aint gonna kill alien bastards with blanks

551

Suggestions / Re: Battlescape Resolutions

« on: February 28, 2011, 01:49:32 am »

Hi,
In fact, increasing the resolution of the battlescape area is not *that* hard, but there is also the problem of the resolution of the GUI...

 The graphical user interface department is more SupSuper's area of expertise, but as I see it, the user interface components are not really ready for it. All GUI components, like buttons and textfields, are given an absolute, hardcoded position relative to the topleft of your screen. Made for resolution 320x200 only.

 If you would increase resolution just like that, you get all of your components somewhere in the topleft half of the screen.
To fix that these components should be positioned a bit more dynamically.
But that also only can work if the positions of buttons,etc are relative to a parent component that has some "alignment" setting.
For example, the battlescape interface has to be aligned in the bottom-center, leaving two gaps to the left and right of it. And the buttons/text/etc on it, should have relative positions from topleft of this interface-area instead of absolute positions from screen topleft.

I bet it's somewhere on SupSuper's unofficial todo-list, but certainly not very high priority
But yeah, it has been asked for before, so I guess openxcom will see this feature one day.

552

Programming / Re: Battlescape development

« on: February 28, 2011, 01:08:38 am »

Could you please give more info when you report a bug, like a screenshot in this case and system you are working on, and also report it in the bug report board? Thanks.

WinXP sp3
some screenshots: https://www.mediafire.com/?p7bx53qa59b3a81
usually day missions have this

Hi Yankes, I have located & fixed this bug. So if you take the latest build from the git builds page, you should not see this random black-tiles effect anymore.

553

Programming / Re: Battlescape development

« on: February 25, 2011, 02:19:43 pm »

In case people are trying the daily build, there currently is a bug in the colission detection or the loaded LOFTEMPS data...

edit-
For info:
I made the decision not to have the different LOFTEMP "slices" as different objects in the game engine, but to have a complete 16x16x24 voxel object as an object. So a voxel object (MapModel class) is created with 12 loftemp "slices" and then stored as a 3D model.
Each map object points to it's corresponding model. When loading a terrain a set of unique voxel models in that terrain is compiled. (I used a checksum/hash calculation on voxel data to easely compare voxel models)
As a result a terrain with 100 objects can have 20 models, because a model can be re-used for different objects.

The reason for this is not only because it's easier to work with complete models, but also that the loftemps slices method could -for some objects- be replaced with other, more detailed and complex, complete 16x16x24 models (or bigger). And then I'm especially thinking of units.
But for that a voxel model editor could come in handy

554

Programming / Re: Battlescape development

« on: February 23, 2011, 12:25:52 pm »

Yeah, the ufopaedia has lots of info. But if it is on the discussion page I think you should double-check every bit of it. Because I have found errors on it too.

For example, there is in the discussion on Line of sight: "Line of Sight takes into account the sighting unit's elevation. Line of Fire doesn't take into account the firing unit's elevation. The dune I was standing on, was blocking my line of fire. [No comment about the target's elevation.]"

This may not be tested very well, or it may be a bug only appearing on certain types of objects (dunes or mountains are sometimes a bit odd).

By the way this calculated "origin" point also used for sight calculation for EVERY unit.
All this info is in https://ufopaedia.org (at least on discussion pages).

on loftemps.dat : "A soldier's head is positioned slightly higher then the barrel of his gun. For this reason, it is possible for him to be able to see an alien (that is, he has a valid "line of sight"), but not shoot it (because he has a blocked "line of fire")."

555

Programming / Re: Battlescape development

« on: February 23, 2011, 10:22:51 am »

yeah, I had the particles seperated too much at some point, on purpose, don't recall why I did that, but I have to change that back.
btw Volutar, Do you have any idea which bullet trail belongs to which weapons. Also any idea on the correct starting voxel of the bullet? (I guess it depends on stuff like kneeling/direction of looking).

While the looks are there, I got still a lot of work ahead of me:
- Got to finally implement the kneeling button.
- Adjust the bullet starting voxel depending on the stance.
- Line of fire collision detection !!!
- Determination of the target voxel.
- Applying firing accuracy.
- Different bullet sprites.
- Correct z-order of the bullet sprite.
- Bullet shadow.
- The impact damage.
- The impact visual effect.
- Sound effects.