[battlescape] long term map and tile specs.

[Volutar]

1. Are we going to stick to original map/mcd specs?
2. Are we going to stick to original data pack?
3. For how long?
4. When will we need new map and tile specs?

Next questions will be topical after first 4 will be answered.

5. Are we going to support exotic devices with low 3d capabilities, low memory and cpu? (like dingoo or iphones or android devices).
6. Do we need solid 3d models or pre-rendered/drawn 2d sprites with voxel object is ok? (this is very important question).
7. Do we need new map format, which will be able to handle tiles interconnection for construction collapse capability (sort of tiled physics) and probably something more?

[pmprog]

In regards to point 5, I was planning on supporting a Pandora build of OpenXCOM. However, what I plan and what I actually do seem to be two massively different things at the minute  I still haven't had chance to do more on the unit rendering or even make a Pandora build

[Volutar]

Since topic of "loftemps" closed I will answer here.

We have all of OpenXcom to worry about, but you guys are totally free to try out anything! Pursue all your ideas! Find out what works and what doesn't! Go nuts! Develop your own versions of OpenXcom that satisfy you if need be! New file formats! 3D engines! Whatever!

Please don't get me wrong, but for getting new data structures(file formats)/3dengines/scripting/whatever, it will be lot easier to re-write new opexcom. From scratch. But only after making some sort of design document or vision doc which will describe every game aspect and perspective (to arrange every moddable aspect and game data structure hierarchy).

Just look at OpenTTD, the standard official version just supports all the standard TTD features (with improvements), but there's a forum full of patches of everyone's crazy ideas in practice without any word from the developers. The community is happy, the developers are happy, everyone's happy.

I've looked there. And didn't found anything of 3d engine or something "not cosmetic". Every patch fits into original game structure and paradigm. Probably because they've thought over beforehand, or people just dropping any ideas which would require alot of code reworked. Or maybe their project doesn't have anywhere to advance.

Regarding new file formats, I think Daishiva was interested in them too, even willing to develop tools for them, so you might have some extra support there.

Hey, I was saying not about new "file formats", but about new map/tile data structures, unit structures and interaction formulas (in order to make game more extendable and moddable). I suppose I'll take a sit somewhere around Daishiva and wait until this will be required (after 1.0 I guess, but probably it will be too late for this).

[LCSand]

1. No. The old format should be supported but a new better replacement should be an option.
2. For a long time the old data will be the remain the core around wich new stuff is built. But at some point I expect it will become absolete.
3. At least until 1.0, depends.
4. Need? I dont know. Want? As soon as someone comes up with a good one and adds support for it in openxcom.
5. Yes and it is definetly possible to do so too and all those devices you mentioned have high enough specs.
6. 3D modles could be made and used to generate the 2D and Voxeldata, but that would not be mandatory. So solid 3D is not NEEDED for the game.
7. Maybe, I dont know, depends how you want to implement it. But if that feature should be added a new format should make things simpler and if you want to add any new properties to a tile it would be mandatory.

[Daiky]

Volutar, I closed the loftemps topic because you keep going offtopic (I got complaints from forummembers), and supsupers post was not a question, so nobody needed to answer. And now you are even going offtopic on your own post... Why don't you just write some code instead of constantly complaining how bad openxcom is?
I currently can't code, I just can read the forums on the iPad, so it's kinda frustrating. When I'm back, I'll start coding again. Getting a few bugs out and towards 1.0 and not starting battlescape code from scratch, just because you want.

[Volutar]

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?

[moriarty]

Volutar, I think you are right in some aspects. Of course it would be nice to have perfectly adaptable code from the beginning, allowing us to do easy modding and everything.

Right now, I think we need a different priority, though. Looking back on all those x-com remakes that died, I think many of them died from trying too much at the same time. The current goal (getting a replacement for the original game, without the bugs, using the original game files as a resource) is probably the only sane one. It is achievable, and once we have that, more people can and will be drawn to the project, allowing for modifications to the code to implement fancy new stuff.

It's pretty frustrating for now to accept that some things will need heavy re-writing later, but I think that's just the way it is.

If you have things that can be easily changed so that the main goal (as stated above) will still be reached without excessive work, by all means, contribute them! But beware the dangers of wanting too much. I wouldn't want openxcom to end here.

[Volutar]

moriarty, I perfectly aware of sin of getting too deep into intention of covering "everything". And I didn't propose something "excessive". Let's take my pathfinder proposal (in here). This topic actually is connected with it. How door opening should work? For free or cost some TUs? What about issues when getting door opened manually and getting through closed door with autoopen takes different TUs? See, pathing code of original game contains a load of different bugs. Some of original MCDs have bugs inside - mountain hell, negative elevation of avenger roof, zero passing TUs for some of tiles, limitation of outer ufo walls, hull holes bug (when you see aliens inside, or even can shoot them if you lucky). My proposal of fixing them was ignored. Like, you cannot change MCDs, since it's "original data". These bugs partly connected with data structure, and cannot be fixed "by code". So the question is simple - for how long are we going to use old buggy obsolete data structures?

[michal]

So the question is simple - for how long are we going to use old buggy obsolete data structures?

At least until 1.0 is ready. And probably much longer - until someone will be able (and willing) to code it.

Volutar, i understand that you want to have formats without bugs, limits, and extendable. It would be great to have them.

But you need to understand, that you can't force open source developers to code in way you would like to. SupSuper and Daiky are doing it for free and in free time. They can code what they like and how they like. It's how open source works.

If you're unhappy with that, feel free to gather other coders who thinks like you, and create OpenXcom fork - call it OpenXcom++ or what you like. In that project you could experiment with new formats, new renderers (switch from sdl to opengl) etc.

[Volutar]

I already stated that I'm ready to write tools for new tile/map format. Converters from old format are also possible. The thing is - I hate to get into openxcom code, since I found it pretty confusing or even obfuscated. Actually for me it will be easier to start new project, than getting into openxcom "engine" paradigm.

Getting into new "solid" (without holes with proper LOFT) battlescape will require of redoing pretty much of what Daiky have done. I clearly understand him in his unwilling of even discuss about that. Who ever will be happy with getting part of his work into trash? When the goal is replicating of original xcom, you don't think of what will be next. Replicating original gameplay with original data intact (because getting into something new is too difficult) is pretty much a final point.

[michal]

Getting into new "solid" (without holes with proper LOFT) battlescape will require of redoing pretty much of what Daiky have done.

So, you think that SupSuper and Daiky should start rewritting / refactoring everything? For sake of moddability?

[Volutar]

michal, it doesn't actually SupSuper's concern. More Daiky's. I don't expect this, but this should be resolved. Either project stops at 1.0 with poor modding support, or will be reoriented into more progressive direction (which will require for some effort).

[moriarty]

well, I'm not a programmer at all, but I think that you/we should stick to the goal of getting a functional version first.


if the only concern is getting "solid" walls without gaps where the LOF template files are done in a very sloppy way, then I suggest first "modding" the LOF template files instead of re-inventing a whole new system - about copyright issues: what we have to avoid is re-distributing original works. if we can find a way to allow additional LOF template data to be read (and "replace" original data, where applicable), that would be perfect.

[Volutar]

moriarty, there's no such modifications which can cover those bugs. It will require whole tiles and map rebuilding. Actually it's long-term task. If you want to stick to current goal (and that's it), you have to stick with all these bugs too. Without options.

[Yankes]

Volutar, holes in LoFT can be fixed, it will need change that you cant go when tracking to (x+1,y+1) from (x,y), only to (x+1, y) or (x, y+1), this will fill all bugged places.