iPhone port started!

[KylePoole]

Hello all Battle for Wesnoth fans! I am happy to announce that after discussing with Dave, I have started an iPhone and iPod Touch port! Due to the complexities of porting a large PC game to a mobile device, my time estimate is two months until completion.

As for my qualifications, I have been developing mobile games for more than 10 years. You might remember me from classic Palm games like "Kyle's Quest" and "Galactic Realms". More recently, I was the lead developer for the hit iPhone game "Reign of Swords" which is a turn-based strategy RPG much like BfW.

For starters, I would like to see a show of hands who has an iPhone or iPod Touch and dreams of playing BfW on the go. Then we can discuss what form the mobile version will take. Also, you might have noticed that BfW is a relatively large game... What do you think the maximum size should be for the iPhone version? 50mb? 100mb?

Thanks!

[ancestral]

I don't think it matters too much as long as it's under 1 GB. Just the core of the game and mainline campaigns should be good, I think. With the possibility of additional downloadable content, there might even be room for the add-on server

• Are you using SDL 1.3? I think you pretty much have to…
• Do you have any ideas on how to implement music and sound?
• Will most of the common commands simply be presented in contextual menus on the screen (recruit, recall, etc.)? Will the user press and hold for actions, or do you think you'll have an action bar?

[MrEPIC]

I have an iPod Touch and would dream of playing Wesnoth on the go!
As far as a size limit, I think that 200 MB is reasonable, but it can of course be more or less.
However, I really wouldn't be any help in the development of this port.
Good luck!

[Ken_Oh]

My g/f has an 8gig iPod touch. Yeah, it would be cool to play Wesnoth on it. Size isn't an issue really (we're going to be hard pressed to use up half of the space as it is).

[Max]

that would be really awesome...

i'm curious what you plan to do with missing dependencies. last time i looked there were still some libraries missing (including one of SDL core libs).

and i wouldn't care about the size - you need itunes anyway for anything bigger than 10mb and the navigation apps are >500mb^^

[AI]

I have an iPhone 3G and would like to see a port, but I see the following issues:
-wesnoth uses SDL, of which the (unfinished) 1.3 version is being ported, but isn't finished yet.
-wesnoth requires a bare minimum of 128 MB of RAM, the iPhone 3GS has this, the earlier iPhones and iPods don't.

[Jetrel]

As far as disk space is concerned, there are 3 big offenders:
1] Our music is the biggest part of our distro, IIRC. It's quit gently compressed; you could be much more aggressive, and probably recover half the space for a modest reduction in quality. Ogg is one of the best audio codecs in widespread use, and compresses very well. 220mb -> 100mb

2] Our text files take up an enormous amount of space. If you came up with a binary serialization, you could write a script to translate everything to it, and would probably collapse the size of our data files, at least by half, I suspect. Doing this would be very hard, but would be feasible. We have them editable on computers because it's such a catalyst for User Made Content, but they don't need to be editable on a mobile device; that's what PCs are for, and it would be horribly awkward to try and edit anything there.

3] unit and terrain images are split into separate files, which creates a lot of overhead. We'd get a 80% reduction in the size of our unit images if we concatenated the files together - I've tested it. Similar, though probably not quite so good, for terrain images. This would be very difficult to do and is probably beyond the scope of your port, but doing both of these would probably yield about: 66mb -> 10-30mb

I have an iPhone 3G and would like to see a port, but I see the following issues:
-wesnoth uses SDL, of which the (unfinished) 1.3 version is being ported, but isn't finished yet.

I'm very interested in any solution to this. I have an SDL game I'm personally interested in porting.

-wesnoth requires a bare minimum of 128 MB of RAM, the iPhone 3GS has this, the earlier iPhones and iPods don't.

Yeah, you might run into a big problem with this; the available ram *not* guzzled up by the OS is about 40mb on a regular iPhone/iPodTouch, versus about 150mb on the 3GS (and presumably the upcoming revision to the iPodTouch).

http://www.taptaptap.com/blog/the-impac ... -increase/

This is one of a number of reasons that Wesnoth's SDL backend sucks; it requires us to do some really, really aggressive caching to get a decent framerate. For example, our memory requirements are doubled against the case of simply having all our unit bitmaps in memory, because we have to store a separate copy of them in the alternate facing (because reversing it on the fly is too slow). Likewise, our case of having team-color shifting requires us to store a separate copy of every texture in memory, which again duplicates our memory usage. Another problem is our usage of IF macros, which multiplies the size of parts of our WML tree, the fact that our WML tree has to completely reload when certain changes are made, and can't selectively load sub-portions (I'm fuzzy on this, forgive me if I'm getting the details wrong - this was something he solved in silvertree, though).

Dave has solved most of these in his later game designs; Frogatto for example, requires only 50mb of ram when running, and it has graphical-processing and FML requirements that are in the same ballpark as wesnoth's.

The reason these aren't in wesnoth right now is that they're enormous, horribly difficult "gut the game and rebuild" projects. There is also a certain amount of scuttlebutt from people who refuse to buy hardware that will run OpenGL on linux, which I personally find inexcusable (but am not making waves about because I'm not doing a rewrite at the current point in time). If linux wants decent games, 3d-acceleration is not optional.

[ancestral]

I have an iPhone 3G and would like to see a port, but I see the following issues:
-wesnoth uses SDL, of which the (unfinished) 1.3 version is being ported, but isn't finished yet.
-wesnoth requires a bare minimum of 128 MB of RAM, the iPhone 3GS has this, the earlier iPhones and iPods don't.

Versions of SDL 1.3 can be downloaded with preliminary iPhone OS support. Last time I checked, most of the graphics routines had been ported. There might be some performance issues, though. (A Google Summer of Code participant was/is doing this.)

You are incorrect though; the iPhone 3G S has 256 MB RAM and previous models and touches have 128 MB. So I think it'll be OK.

[Max]

You are incorrect though; the iPhone 3G S has 256 MB RAM and previous models and touches have 128 MB. So I think it'll be OK.

i'm sure AI was talking about available memory and as Jetrel already pointed out this is only the case for the new 3gs.

Yeah, you might run into a big problem with this; the available ram *not* guzzled up by the OS is about 40mb on a regular iPhone/iPodTouch, versus about 150mb on the 3GS (and presumably the upcoming revision to the iPodTouch).

http://www.taptaptap.com/blog/the-impac ... -increase/

although the iPhone's virtual memory doesn't support swapping to "disk" at least it's able to drop read-only (code) pages. but i doubt that will change much^^

[appleide]

I've got a iPod Touch 16gb. It's applications only fill up a couple of hundred megabytes, so I don't think file size matters that much..

Just wondering, how much are you going to charge at the iTunes store, if at all? I'd prefer it to be free... But if you charge at $0.99 you could probably get away with it for several months before the competition catches up. I'd imagine revenue from the first months would be quite substantial. Of course you'd have to release the source code because its GPL.... though.

[teg]

For starters, I would like to see a show of hands who has an iPhone or iPod Touch and dreams of playing BfW on the go.

If you can make a BfW port for the iPhone, I might be interested in buying the iPhone to be able to play !

By the way, are you going to build Wesnoth for the iPhone/iPod or will you re-develop parts of it to adapt to the platform?

Will it be possible to connect and play on the multiplayer server with your version ?

[Dave]

This is one of a number of reasons that Wesnoth's SDL backend sucks; it requires us to do some really, really aggressive caching to get a decent framerate. For example, our memory requirements are doubled against the case of simply having all our unit bitmaps in memory, because we have to store a separate copy of them in the alternate facing (because reversing it on the fly is too slow).

While this is annoying, I actually don't think it's that much of a blocker to an iPhone port. I think even with all of our caching, the images take up a smaller proportion of memory than you'd expect. Ultimately any port to an embedded device can remove some graphical features to make things fit. Reduce the number of frames in animations, or remove animations altogether. Make all units face the same way. (Kinda ugly, of course...)

Likewise, our case of having team-color shifting requires us to store a separate copy of every texture in memory, which again duplicates our memory usage.

I actually don't know any other way to implement this, even with OpenGL.

For instance, the main reason why in Frogatto when you pick up a power up the game pauses for a moment is because it has to calculate new textures in memory to show Frogatto in the different colors.

Another problem is our usage of IF macros, which multiplies the size of parts of our WML tree, the fact that our WML tree has to completely reload when certain changes are made, and can't selectively load sub-portions

Actually the usage of IF macros is more of an issue with speed, not memory usage, due to having to reload. Not being able to load sub-portions of the WML is the big memory problem, though.

The big problem with memory usage in Wesnoth that is hard is that most every piece of game data is stored in a huge WML document. Worse, various game objects keep references directly into this WML document, meaning the entire document has to be held in memory while the game is being run. Even worse, the data structures that WML documents are implemented with in Wesnoth are very inefficient in both space and time. See http://dave.wesnoth.org for some analysis I've done on this. cjhopman has a SoC project to fix some of this.

I have solved this on later projects I've worked on using an approach that is very simple in retrospect:

- objects such as units are stored in a directory tree, with a filename containing their id. e.g. elvish_fighter.cfg. This file is loaded on demand when someone requests "elvish_fighter". The Wesnoth approach is to just load all unit definitions at startup.
- levels/scenarios are stored in different files and loaded on demand.
- only some very fundamental/basic game data is loaded on startup and kept forever.
- all WML nodes are managed using reference counted pointers. If you want to keep access to a WML node, just retain a pointer to that node. The document can still be deleted and the reference counting will ensure the node you have the pointer to remains valid. In Wesnoth this doesn't work: if you have a reference to a node within a WML document you have to keep the entire document in memory.

I actually considered approaches like this when making Wesnoth, of course, I just never imagined that enough people would want to contribute content to Wesnoth for the main WML document to actually end up as big as it is. mea culpa.

Dave has solved most of these in his later game designs; Frogatto for example, requires only 50mb of ram when running, and it has graphical-processing and FML requirements that are in the same ballpark as wesnoth's.

Actually it's partially solved in Frogatto, but more importantly, it's solvable. Frogatto's WML data structures are still pretty inefficient, however they are designed with an API that encapsulates them nicely so that if we want to/need to make them more efficient we can just modify one module, instead of having to modify the entire game.

[Dave]

• Are you using SDL 1.3? I think you pretty much have to…
• Do you have any ideas on how to implement music and sound?

I discussed this with Kyle, and I'm not sure what approach he's going to take, but he may be best to just heavily gut things -- essentially start a fresh write of the engine, while reusing any easily reusable parts of Wesnoth code, or simply using it for reference.

I don't think an iPhone version would need support for network play, the add-on server, themes, or a bunch of other features. (Though some of these might be nice to have, if possible, but not 'required').

David

[ivanovic]

Okay, some stuff regarding possible problems and sizes:
1) IMO it does not make too much sense to really add some compression to the config files, this will not save this much space.
2) What is required anyway is making use of tinygui since the screen resolution is too small for the "normal" or small-gui version. For small-gui the min requirement is 800x480. The use of tinygui leads to the next point.
3) Due to using tinygui all sprites have to be scaled down to 36x36 instead of 72x72. This also reduces the filesize, though it does not make much of a real difference due to blocksize (many small image <2kb and blocksize of 4kb means that each file will use more than twice the real amount). That is unless the iphone binary comes in some tar like "single file approach", this would directly tackle the overhead.
4) Memory usage: Making use of tinygui has a huge impact on memory usage. Space needed for sprites is basically quartered. Beside this teamcoloring is not possible anyway (due to the scaling color informations are not sufficent anymore for TC). So this part if removed, too.
5) Memory usage (part 2): you can easily make use of the lowmemory option. We checked some stuff at FOSDEM 2008. Have a look at the short summary of our tests written by boucman. Keep in mind that those numbers are extremely outdated by now since those tests were from shortly before 1.4. Though some general stuff is still valid... When reading this stuff keep in mind that the test case was a *really* simple scenario, just a replay of a skirmish match on a medium size map. So for campaigns with lots of complex WML like eg Northern Rebirth or Under the Burning Suns things will look differently.
6) Translations require lots of space. The translations in currrent 1.6.4 use up 60MB. Plus for the asian languages we ship a font that also needs 13MB. If you just ship the English version you can thus easily save 73MB.
7) Size for music: In current 1.6.4 music requires 104MB. IMO this can be included as a whole since the music creates a huge part of the atmosphere.
8) Size of the bundle: Currently an install of 1.6.4 on my x86 64bit Desktop box is at about 300MB. Without translations and the extra font it would be down to ~230MB. With tinygui images it would probably be at about 200MB, which should be really fine. This way *no* content would be removed from the game!
9) Input: you will have to find some nice way to make input "finger friendly", things might be a little difficult at the moment if you wanted to select menu items using your fingers. Beside this some way to create a right click is needed, plus maybe adding some buttons to the screen for "generic actions" like recruiting. Scrolling could maybe be done via tilting the device.

Short summary:
Yeah, an iphone port should be possible. Complex stuff can be problematic though when it comes to memory usage. Filesize should not be too much of an issue though. Some work has to be spent on input devices. Have fun and good luck creating this package.

[Kalajel]

Now I'm not a techno geek and I'll admit some of the techno babble that's been discussed in this thread has made my poor neanderthal-like brain spin, but there's one thing I do understand though and it's that by porting a complex game like Wesnoth to a portable platform like the iPhone, you'll have to cut corners and probably a lot of them… So here's some of my suggestion on which corner to cut (if that is possible);

• Music: a smaller selection of music will help save space. I don't know how many nor whic score (except one, see below) to cut, but good candidates would be one that don't have much in the "conflict, warfare, and confrontation" atmosphere. One I'd like to nominate for the axe would be the Knalgan Theme. Nothing personal against whomever wrote that score, but it is easily the longest and probably the most boring score of them all (I tried listening to the whole thing on VLC and had to struggle not to fall asleep…); it's lnog, monotone, and nothing really seem to "happen" in it… it's only saving grace is that I'm usually to busy actually playing the game to notice how boring this score is…

• Sound effects: I've noticed there's quite an extensive array of sound effects available; 3~4 bow sounds, 3~4 saurian hisses, 2 different horse hooves, etc. Couldn't we cut a bit in there to save space? Will the rebel really suffer if they use the same hoof sounds as the Loyalist?

• Unit animation/sriptes: while I feel keeping the various attack/defend animation is important, there are a few "superfluous" animations that could stand to go;
- "Recruit" animation: Too new, we didn't had it before 1.7 and could live with it. It is not necessary; it has to go.
- Dying animation: While cool, a lot of units still don't have any. Cut this and you save yourself 3~4 frames for a bunch of units. Just have a dying unit fade away…
- Faction colors: Have each unit's side indentified only by the colored circle at the base of their feet and do away with the "different-colored details" that helps differentiate a unit's side (some of those are already too small with normal resolution anyway, so just imagine with iPhone resolution…). And if that's not good enough, then maybe add a colored arrow over the unit's head…

• Terrain sprites: again a bit like the unit srpite point and sound effect point above… Do we really need 3 different types of roads? 3 different types of grasslands? An animated windmill? about 3~4 different house designs for each type of villages (maybe keep 2 at most)? And so on, and so on…

Anyhow, that's all I can think of right now off the top of my head… Hope my ramblings made some sense…