Battlescape development

[Daiky]

Some may know already that I have started battlescape development for openxcom. Independently from SupSuper's geoscape development atm, and not (yet) committing into SVN.
You can always ask me on IRC how this is progressing, but I'm not there all the time, so I decided to post my progress here for these curious people.

milestone 1 - done
I started with a design, threw the design far away and started coding.

milestone 2 - done
First new class I created is the BattlescapeState. This is where all the action takes place. It divides in 2 main parts, the "_map" part and the "_icons" part. Map, another new class, is an interactice surface which is the viewport to the battle map. Icons... well, the icons And then lots of interactive surfaces, one for each button. The abort button stops the battlescapestate. The battlescape state starts when pressing the ufopaedia button on the geoscape. (just for quickly testing the battlescape state of course)

milestone 3 - todo:
- review code of previous milestone
- create SavedBattleGame class (the pointer is held by SavedGame) which  holds a set of Tiles
- using XcomRuleset certain .MAP files are loaded into the set of tiles, (depending on terrain, mapsize, mission,...)
- proper terrain PCKs (tilesheets) are loaded
- the Map is drawn.
- post a screenshot in this thread

[Daiky]

- created new classes:
Tile
SavedBattleGame
BattleRuleset & XcomBattleRuleset
BattleResourcePack & XcomBattleResourcePack

keeping rulesets, resources and game data for battlescape seperate from geoscape stuff did not seem like a bad idea to me, correct me if I'm wrong.

[michal]

I'm not sure if Tile is good name, isn't it to generic? Are you using namespaces? If not, maybe it should be called BattleMapTile? And maybe Map should be called BattleMap?

Anyway, i think that better solution would be using namespaces and folders for splitting classes (i already suggested it to SupSuper).

[SupSuper]

IMHO, as long as there aren't any name conflicts, it should be fine. Appending Battle to every class name would get kinda silly, we can look into organization later.

Mind explaining why you're keeping Geoscape and Battlescape stuff separate though? I can see how the saved game data would differ, but the resource pack and ruleset are kinda generic and I wonder if you misinterpreted their purpose.

[Daiky]

I thought you don't need access to any of the battlescape resources (tilesheets) while in geoscape mode + it seemed logical to have them loaded intelligently at battlescape start anyway.
The XcomResourcePack loads everything in the constructor of the class;
so there's two options here, either I create a function in the XcomResourcePack to load battlescape tilesheets (and unload them at the end) or create a seperate resourcepack with tilesheets, sounds for battlescape and delete the resourcepack when battle ends.
I'm not sure bout the rulesets, it could keep the files at a reasonable length, because they may get big.

[michal]

The XcomResourcePack loads everything in the constructor of the class;
so there's two options here, either I create a function in the XcomResourcePack to load battlescape tilesheets (and unload them at the end) or create a seperate resourcepack with tilesheets, sounds for battlescape and delete the resourcepack when battle ends.

Or just load everything at game start and don't care about memory usage. But on the other side maybe it would be better to keep memory usage lower - for some devices with less memory.

[Daiky]

The XcomResourcePack loads everything in the constructor of the class;
so there's two options here, either I create a function in the XcomResourcePack to load battlescape tilesheets (and unload them at the end) or create a seperate resourcepack with tilesheets, sounds for battlescape and delete the resourcepack when battle ends.

Or just load everything at game start and don't care about memory usage. But on the other side maybe it would be better to keep memory usage lower - for some devices with less memory.

To know what we are talking about I just tested it with one single resourcepack loading at startup. Loading 48 extra battlescape PCK (which is terrain+units) files takes up about 12Mb of extra memory. And maybe 1 second of extra loading time my laptop.
So it is not a big deal after all.

[SupSuper]

Well the point of the ResourcePack class is just a convenient place to check and load up all the resources (anything loaded from an X-Com file is considered a "resource") on startup, so the actual states don't need to worry about them, and can just *expect* them to be there. So there's no need for dynamic loading or problems with missing stuff later down the line. Since the game is extremely lightweight (by today's standards), keeping everything loaded is not an issue. It also makes it easier to later on "externalize" this so people can use their own improved graphics, and there's no telling if the Geoscape won't need Battlescape resources later anyways (eg. pre-soldier equipping).

As for the Ruleset, despite the name, it's not intended to keep any "core X-Com logic" like what defines the AI or map generation or anything like that (for now at least). Instead it just contains all the raw game values and stats for crafts, facilities, items, etc (stuff you typically find buried in the X-Com EXE). The UFOpedia will probably need access to all of this. And again, this can be externalized later so people can make their own X-Com "game modes", ala XcomUtil's improved tanks and weapons. I'll explain this better by v0.2.

In short, I'm lazy.

[Daiky]

just want to tease you with a screenshot:

still needs some work before I can post a patch...

[michal]

Awesome Looks exactly like original Ufo.

[SupSuper]

Great job.

[Daiky]

milestone 3 - done:
- review code of previous milestone
- create SavedBattleGame class (the pointer is held by SavedGame) which  holds a set of Tiles
- using XcomRuleset certain .MAP files are loaded into the set of tiles, (depending on terrain, mapsize, mission,...)
- proper terrain PCKs (tilesheets) are loaded
- the Map is drawn.
- post a screenshot in this thread
- implement edge-of-screen scrolling

I created a svn patch file of the current battlescape code, if you like to have a play with/look at it.

milestone 4 - todo
- review code, bugfix milestone 3
- button: show/hide all map layers
- buttons: map level up/down
- draw battlescape "selector" cursor


edit: patch updated, compilation error fixed

[michal]

I've just compiled OpenXcom with this patch under linux, it's nice too see beginning of battlescape, good job

[bramcor]

Battlescape works flawlessly on Ubuntu x64!

Only problem was patching, which caused some hunk fails with vcproj file. Compiled with a few warnings in Tile and XcomRuleset, but they seemed to have no effect on running the game.

Chek out the fails and warnings at https://pastebin.com/iqPGcDKc

Screen edge scrolling is a bit choppy and difficult to control but I am sure that is a WIP

[Daiky]

milestone 4 - done
- scrolling fixed
- buttons: map level up/down
- draw battlescape "selector" cursor
- loading of 20x20 maps works
- animated tiles works

I have included a openxcom.exe build for windows that includes the battlescape when you press the Ufopaedia button, it starts a 50x50 jungle map.
Also included a screenshot.

And be prepared for the next big milestone....
milestone 5 - todo
- bugfixes
- base defense map generation
- adding an xcom craft on the map (exciting !!! - no soldiers yet... but they will come)
- minimap button/minimap screen