[battlescape] long term map and tile specs.

[moriarty]

that appears to be a valid idea.

I personally appreciate the simpleness of the LOF templates. The only things I would like would be a simple but effective editor to modify them or create new ones.

and then perhaps the possibility for the game to actually take them and rotate them in 90° steps, so that stairs and other non-symmetrical objects could be supplemented with equally rotated versions, eventually leading to a  huge increase in battlescape variability by actually allowing rotation of each object in 90° steps.

(from there it would be a truly tiny step to actually allowing rotation of the battlescape "camera" in 90° steps, but that's a looooong-term-goal... )

[Volutar]

Yankes, you mean changing bresenham8 to bresenham4? That could fix holes, but also may lead to some side-effects. And won't fix bugs with TUs and inability to stand near northern outer wall.

moriarty, I think you can forget of "effective" editor for _old_ MCDs and voxels. MCDedit (written in vbs) is the only tool for this. And I doubt in perspectives of getting xcom1 maps rotating, just beacuse it has assymetrical nature (central tile + north wall + west wall, but no south and east walls).

[michal]

Either project stops at 1.0 with poor modding support, or will be reoriented into more progressive direction (which will require for some effort).

I doubt it will stop, i think that after 1.0 someone (Daiky or someone else) will start adding new formats, etc. In my opinion it's better to start simple and refactor later. That way we will get working solution. Look at Project Xenocide - they restarted couple of times, with different languages, technologies, etc - and they never achieved level of OpenXcom.

Once again i think you should start designing everything and then look for some ppl to start new project. As (IMHO) you have different vision than OpenXcom team - yours is more general x-com engine with new formats. Your vision is more like Ufo: TTS had - there were different formats - for example you had to launch extractor which extracted graphics to new format.

I think it's better than writing many times that OpenXcom code is poorly written, slow, etc

[Volutar]

Really I don't want to start new project. I'd wish openxcom eventually become it.
Jagged Alliance, XComs have similar battle mechanic. It's quite possible to assemble common things, think over things that could be advanced, and create new game design (I mean tactical part of course). But this new "engine" will be able to cover everything from ja to xcom. And of couse it will be possible to "simulate" xcom1 look and feel. It's not really necessary to directly stand in xcom1 shoes with all its limitations, bugs and effects. And frankly, it quite a bad idea.

I'd like to share some thoughts about what game aspects should be considered and assembled into "new xcom" or "xcom after 1.0" if you wish:
- Map structure (random map assembling, AI pathing, tile linkage)
- Tile structure (voxel objects, visual - four angles, animation, and bunch of different properties; probably different visual for different health)
- Tile physics (inter-tile link breaking; tile+tile interaction; predictable effect of structure damage and collapsing)
- Damage mechanics (storing of current health or number of "healths" for each map tile, different damage types - thermal, explosive, penetrative, cutting, and mix; for example you make almost no damage to hay pile with a knife)
- Unit-tile movement/still mechanics (different postures, moving through obstacles, crawling, climbing, strafing, different TUs cost for different tile movement through and standing on penalties or bonuses, possibility to make some damage to the floor tile by simple standing or moving on it, depending on weight)
- Unit mechanics (body parts, organs, perceiving capabilities, psychological state, different health aspects; affecting on tiles, and on weapon/using/moving/aiming/etc).

That's the list, sort of "plan" to consider of, to change, and finaly to convert into more solid form of object structures, hierarchy, and interaction methods, which someday would be easily coded.

[pmprog]

Really I don't want to start new project. I'd wish openxcom eventually become it.

Could I offer an option then?

Design your new file spec, and implement a loader in Ruleset/MapDataSet and Ruleset/MapData. As long as you don't remove or rename any existing fields, you should be able to add as much as you want without breaking compatibility with the original game files. Also add a field that declares the type of data loaded (ie, to indicate the new fields have data).

Then, at some point, the battlescape can check the loaded source field, and if the new features have been filled (loaded via your new spec), the behaviour can be modifiered to support the new data, and will still retain the ability to work with the old data.

You're going to have to get your hands dirty though...

[Volutar]

pmprog,
It's not about files or formats, it's about internal data and object structures. There's no way of getting "something intermediate". The only thing possible is making "alternative" object hierarchy, properties and methods. Which is almost equal to making battlescape from scratch.

[pmprog]

It's not about files or formats, it's about internal data and object structures. There's no way of getting "something intermediate". The only thing possible is making "alternative" object hierarchy, properties and methods. Which is almost equal to making battlescape from scratch.

Sorry if I've missed something, but what don't you think could be accomplished with the existing engine/classes?

[Volutar]

Sorry if I've missed something, but what don't you think could be accomplished with the existing engine/classes?

List of what can be accomplished with existing engine/classes is lot and lot shorter. And even this "common" part would need full refactoring.

[pmprog]

List of what can be accomplished with existing engine/classes is lot and lot shorter. And even this "common" part would need full refactoring.

What "common" part?

Can you give me just one example of something that couldn't be done with the current class structure?

It might sound like I'm being a bit of an arse, but I seriously don't know what you think isn't possible

[Volutar]

random map assembling rules (not just mixed 16 blocks of 10x10); ai pathing working for any kind of unit, not only ranked 1x1 or 2x2; tile ties (metatiles); any voxel model, not limited with loftepms and 16x16x12 sizes; turnable tiles and no outer-wall tiles occupying some of adjacent tiles; No more "walls" or "objects" - only tiles, which are placed or stacked into one cell; cumulative damage for tiles; different visual and voxel object for different tile health level; unit/tile/object weight -> metatile breaking and collapsing; stackable tiles (tiles over tiles - after collapsing); FOV and walking paths calculated using voxel representation; different damage types (including damage from collapse and fire); unit stat penalties/bonuses caused by tiles unit standing on and interacting with; diversified unit stats and body health, causing bonuses or penalties.

[kkmic]

Looks like this discussion is spiraling out of control....

Why don't we get a working X-Com clone (the current goal of OpenXcom) and then work on how to improve it?

I said this before, I WANT a modern X-Com: full HD graphics, no bugs, more maps/environments, maybe voice acting.... but really, is this the time to argue on what direction this project should go at this very moment?

Besides, for me SupSuper is the project's BDFL. And he proved time and time again that he is worth listening to.

[pmprog]

random map assembling rules (not just mixed 16 blocks of 10x10);

That's feasible. The Battlescape ends up with an array of tiles. Creating a new "generator" class that does a full random map is entirely possible.

ai pathing working for any kind of unit, not only ranked 1x1 or 2x2;

I imagine that wouldn't be too difficult to mod the 2x2 to [n]x[n]. It'll follow the same rules, just have to check for wider spaces, but as that process is already required for 2x2, should be relatively easy. No?

tile ties (metatiles);

Not quite sure what you mean by this. It sounds like you just want to add additional information into /src/SaveGame/Tile

any voxel model, not limited with loftepms and 16x16x12 sizes;

But if it's larger than this size, surely it'll be a [n]x[n] tile object, in which case you get [n]x{16x16x12} LOFTemp to work with.

turnable tiles

I guess that depends in what essence you mean by "turnable". From a LOFTemp/voxel size, it's easy to do once the data is loaded. Visually, with sprites, it's harder, however, things like ufo walls already have all four angles, just pick the next image to draw.

and no outer-wall tiles occupying some of adjacent tiles;

Granted, I don't think I ever totally understood the whole north and west wall issue, but as you *can* have walls that you can stand on both sides of, it's technically possible.

No more "walls" or "objects" - only tiles, which are placed or stacked into one cell;

Sorry, I didn't understand this one

cumulative damage for tiles;

Again, isn't that pretty much adding a "Damage Sustained" field to /src/SaveGame/Tile? Then when a weapon hits it, this gets increase. When it raises higher than the threshold, it gets "broken" etc.

different visual and voxel object for different tile health level;

Forgive me if I'm wrong, but it already supports this? According to the UFOpaedia, UFO floors for one have a damaged and a destroyed state.

unit/tile/object weight -> metatile breaking and collapsing;

Do you mean like shooting all the walls out and watching the roof fall? If so, that could be quite easily accomplished by scanning each floor tile above ground floor where there is no "supporting" wall within [n] tile radius. These can assume to be unsupported/damaged and dropped down to the floor below. It might be a bit harder to add the animations, but don't see why it wouldn't be possible

stackable tiles (tiles over tiles - after collapsing);

Okay, this is a fair comment. However, why would you? If your upper floor fell down into the lower floor, you could assume whatever was on the lower floor previously got smashed to pieces.

FOV and walking paths calculated using voxel representation;

You already have the LOFTemp data - which if I remember correctly is a voxel based system for the world when doing the shooting calcs etc.

different damage types (including damage from collapse and fire);

Well, there's already Armour piecing, High Explosive, Stun, and Incendiary. Combining the "Damage Sustained" (previously mentioned), and the collapsing floor (also previously mentioned), you could keep adding damage to floors on fire etc.

unit stat penalties/bonuses caused by tiles unit standing on and interacting with;

Again, you could add a field to the Tiles class called "Unit Stat Modifier" which list which stats get modified and by how much. I'm not sure if UFO:EU did this already, but TFTD certain did (did you ever walk through the coral? TUs get wasted, not dissimilar)

diversified unit stats and body health, causing bonuses or penalties.

Why not? Whenever you use the medikit, you can see where fatal wounds are, so the engine already knows where units get shot. Expand this functionality to keep track of non-fatal wounds, and apply to walking (for legs), stamina (body/legs), strength (body/arms), and accuracy (for arms/head)

I'm not saying you could implement all of these super easy or quickly; but from what I've looked at the code, I certainly don't see anything that's not implementable, and don't require massive amounts of time to rewrite.

[Volutar]

pmprog, are you trying to say, that it's quite possible to fit elephant in the fly? Okay, you may start doing this. But personally I prefer to get into something more solid and integral, than mixing up old and new within some sort of tactical patchwork.

[SupSuper]

Ok this is really getting out of hand, so I wanted to make a point.

Before start coding you should be having a plan, some vision of what you want to get. And you shouldn't invent something new when almost everything is done - that would be frustrating.
Because changing even smaller parts, or adding something may lead to reconsidering many things. I'm saying about planning things before implementing them.

Do you, Daiky, want to face situation when you'll need to redo many things? I bet you don't, me either. Though, I can presume you probably don't really care about where this project will go after you get battlescape part working "similar to original". Hell, probably nowhere.

This topic is about essential questions, and with _real_ answers (not wishes) we can say what this project will look like. Or what we need to aim to.

I'm not going to some "offtopic". The topic is about "long term data structures". Not current data structures (borrowed from https://ufopaedia.org and original game), which can hardly be extended, but structures which will be topical after 1.0.

For instance, even getting 2x sprites and resolution will require for new formats, and for rewriting alot of code, just because with current "shading" sprite engine it will be pretty unplayable at 640x480.

Why am I seeing some sort of a dead end after 1.0?

I don't know why you're seeing a dead end. I don't see a dead end. There's always so much to do, so many possibilities, so many experiments, so much that can be done. In a way I'm kinda looking forward to it. There'll finally be time to actually take a good look at the code, improve it, refactor it, optimize it, extend it, clean it up, etc. There's so many things that can be tried. UfoExtender features, XcomUtil features, keyboard shortcuts, externalized resourcesets, datasets, dynamic world, more options, more ports, support for more graphic formats, support for TFTD, 24bit support, OpenGL support, TTF support, high-resolution, scalers, pre-equipping, equipment layouts, unit placement in craft, more detailed vehicles, externalized UI, dynamic resource loading, etc, etc.

You say to do any of that the code needs to be "rewritten". So? Nobody writes perfection from the start, even if you plan all day. Code can always be improved, rewritten, refactored, enhanced, optimized, cleaned up. It's always evolving. You might come up with one solution one day and a much better one the next. This doesn't make the previous solution wasted effort, it served its purposed, it helped on the path to a better solution. This is not "throwing code away", if you are afraid of change you will never improve, any programmer worth their salt understands this, there's always room for improvement. Code isn't static, it's flexible, it's always open for change. You say OpenXcom is slow, buggy, ugly, etc. This is all stuff that can be fixed. With enough patience, planning, care and time anything can be done.

You think the only way out is to start over fresh. That's a common reasoning but it's dangerous. You're assuming all the previous code is pointless, good for nothing, all the effort and time was for nothing, and just by starting over you'll do a better job. That's not a guarantee. Improvement is incremental, it's not a sudden occurrence. Here's a very good article on the subject.

If you still don't believe so, then I give you a simple challenge: prove us wrong.

[Volutar]

SupSuper, firstly, I don't think the only way is to start over fresh. This will be the only way when you face to some changes need to be done, and effort of implementing these changes will be the same as if you write part of project from scratch.
I dislike getting some other's code vanished. No problem with mine. So why I'm avoid to take into openxcom code - if I'll start, I'm affraid to found myself rewriting very much of code. Not "improving" or "adding some lines" but actually - getting functions replaced with totally others.
I aware current graphic engine (which is not actualy an engine) with hardcoded 320x200 SDL is mainly a temporary solution. But it cannot be "fixed". It can be only totally erased, and replaced with another graphics engine (and by doing this you'll have to rewrite quite alot of code). I don't see any ways of improving current SDL solution. That's part of my point.
But another, main point is about inability to improve current game structure because of sticking to "ORIGINAL" game data and hierarchy. I don't see how it can be "improved" to fit what personally I see as better xcom which would be nice successor of gollop's xcom. pmprog seems to see how it can be done with current structure, but not me.
Currently I'm writing some sort of vision doc of tactical part, which shows not actually a "gamer look" but game designer look, considering pretty much of limitations and low-level stuff. After that I'll start getting into lower-level descrition and data structures. And only after that it will be possible to say for sure - what have to be rewriten from scratch, and what can be improved with leaving core of code. But as usual, I'd prefer to write my "testing app" without touching openxcom code.