DualJoe

Looking great Raunhofer, that's a lot of plants indeed. My preference also lies more with these kinds of terrains instead of the miniaturized desert terrains like Takistan. I'm also working on a 8kmx8km project and was wondering by how much trees and bushes would drop framerates. Is there some trick where you can guestimate how the finished map will perform ingame? What cell size are you using by the way, if you haven't mentioned it before? I'm trying a 4096 grid with 2 meter spacing on a 1:1 scale map, based on a real life area. Bushlurker mentioned that working with 4096 grids causes problems and that's why no one does it. Do you have any insights on the grid cell size matter that you'd be prepared to share? I couldn't find any info on the matter and so far haven't noticed any problems, but I'm still working on the heightmap. So no models, roads or trees yet, just grass. However since it's mostly farmland I can't imagine framerates dropping significantly in the finished version.

I didn't get all the data, that' s why it's taking me so long, most of it is done by hand. Btw I'm using the river as sealevel and as you know most of the land is below the riversurface, which means height data becomes pretty much useless, except maybe as reference material. Could use as much reference material as possible, can't seem to find much apart from the Grebbeberg website. Still contemplating how far I'll go with the 1939 version of the terrain. The marsh area to the east of the hill used to be farmland at the time, but I kind of like the way it is now. I'm now reaching the detail level of ditches and such and I'm contemplating how much of the defensive positions from the time, I'll build into the ground-mesh, or to just leave it all for mission-makers (so they can experiment). I think I'll only do the primary positions along the vertical waterway and on the hill itself. I've also started researching materials and textures in Arma2 and trying to figure out a nice workflow including image editors. I'm trying to decide between Blender, Vector-based (inkscape/Xara etc) or raster-editors (Gimp). The last one seems to be the preferred option, however the first two offer some unique possibilities (like arbitrarily changing texture resolution without loss of quality, or reusing assets without added cost of memory/storage). If I take the time relearning Blenders powerful node-system, I could paint colored masks directly onto the model and with some procedurals mixed in for good measure generate all the needed textures for Arma2 in the correct format.

Little update, mostly meant as a personal log and maybe get feedback in an early stage. May not look like much, but it was a lot of work to stitch back all the previously separated areas and then adjust the entire map to arma2-sealevel while retaining most of the small detail (I'll get to digging out all those ditches in the top right down to sealevel when I get to those areas). The dark color represents the upper arma2-waterwash-effect limit. I'm now working on increasing the detail level one area at a time. In the previous version I made mess of the old 18 century defensive positions at the base of the hill (the pointy bits), which I have now corrected. So both sides of the canal at the base of the hill are practically finished including the sand road which you can just make out if you watch closely. I've now remade this area as close to the reference material I've found sofar. Next I think I'll concentrate on the area to the right of the pointy bits, and recreate them based on a couple of areal-photos from around 1930/40. Not because I'm anal about an exact recreation, but I suspect that the current marshy situation, may hinder gameplay more than I anticipated (didn't expect the distances to be that long). Got mixed feelings about the subject though. Part of me really likes some of the interesting features it has now, which I haven't seen in other arma maps. Like being unable to go prone, slower movement when the water gets to chestlevel and having to find a route with enough foothold so you don't end up swimming losing the abilty to fire until you regain foothold. EDIT Pretty close if you ask me. I've been doing some tests with the AI and I discovered that they will not swim across even a small patch of seawater. Bit disappointing, but I could work around it by making a couple of area's just deep enough to walk across. EDIT2 Pretty amazing how much information can fit into one little image. Rest of the (defensive) waterline to the north is now present, but the level is detail is getting to be a Pita. So much for thinking that a small 8kmx8km map would be easy.

Got my 8 gigs of ram and I am currently switching my toolchain from binary to compiling from source, which in the case of Blender and Gimp leads to an incredible increase of performance. I can highly recommend this for anyone working with opensource programs. For example I can now fluently sculpt the complete 8km² terrain in 2m per vertex resolution, while with the binary version my pc gets bogged down with just 1/6th the area in that resolution. I get a comparable speed increase with Gimp as well, 16kx16k as smooth as working on an icon sized image. The binary version was unworkably slow and laggy with the same sized image. Still searching for a nice application to convert 32bit openexr to 16 bit png grayscale, the one I'm using now is cumbersome and unstable. No ideas on how to run an automated object test on the map? I haven't been able to find any other info about 4096x4096 being problematic. I do have another question though. Is there a rule of thumb, or did anyone test how much performance decreases when placing objects like houses and trees? I'm worrying that I can't change the grid and cellsize after placing the objects. Which would mean that I'd lose all my work if I have to change it in the future. Currently on pc from a couple of generations back (core2duo e8500 and nvidia 560 Ti), framerates never drop below 60 on the 4096x4096 map with 2 meter cellsize, viewdistance around 1600m and 1920x1200 resolution. I'm only using the SgtAce grass material/clutter for now and have no objects. I did turn off SSAO. Would the framerate be halved or more if I dress it up comparable to Chernarus country side or the Utes island? Meaning a couple of small forests, predominantly farm fields and couple of small towns and some buildings here and there. NB When using google-satelite images, beware to edit out the watermarks. I just noticed some huge google branding while flying over my terrain, which wasn't that obvious while stitching the image.

Is there a way to procedurally place objects to test if the map will work? I really, really want to try 4096x4096 with 2m cellsize. Currently my heightmap is around 4meter resolution and tried to cut some canals, but if I place them at a slight angle I get ugly artifacts. I may have mentioned this before, but buldozer/visitor seems to be very sensitive about gradients in the heightmap. The first heightmap I tried may have been an 8 bit image exported from wilbur, anyway it had very noticeable banding/terracing in wilbur and horrendous performance in arma2. First thing I tried was a couple of blur-filters in Wilbur to get rid of the banding and performance increased dramatically. Finally I managed to figure out how the displacement baking worked in Blender and how to get the 32 bit floating point images converted to 16 bit png, which resulted in the terrain from the screenshots I posted earlier (very smooth but without the loss of detail from blurring). Framerates went up again. (Wilbur always produces banding/terracing for me on imported png heightmaps almost as if Wilbur imports at 8bit instead of 16). All these tests were done with the same 4096x4096 grid and the only real difference was in the smooth gradients of the grayscale image. This seems to imply that not only the height-value of each point is important, but also the differences relative to the surrounding vertices. It feels like the Arma2 engine has an optimization for smooth surfaces, which only works up to a certain angle. Break this angle often and your framerate suffers. Kind of like how smoothing and smoothgroups results in much better performance on the videocard than the same object flatshaded.

Visitor not taking 4096x4096 grids, wow, that's a pretty major bug then. Shouldn't stuff like that be mentioned in the wiki? I can imagine people not willing to test that stuff. Would be pretty irritating finding out it doesn't work after spending a lot of work to get there. I did test with 4096 and as you said I got it in game, but haven't tested placing objects and such. 1kmx1km would be cutting it really close for what I'm trying to do, even if I'd scale down the terrain from real life. I'm expecting my RAM-upgrade tomorrow, then I'll have enough memory to be able test some of those high end maps (can't work on very large images at the moment). Had to pull some very creative stunts to get the map to where it was in the screenshots, which was about half the resolution I'm going for.

There's one thing that doesn't make sense to me though. I can understand that you'd want to increase texture resolution to compensate for lack of geometry when using a large cell size. But why would you want to increase texture-sizes when you're increasing the geometry resolution, by using a rule of thumb like 10x the heightmap? Since the engine only supports up to 4096x4096 grids, consequently the heightmap resolution is also capped at 4096x4096 pixels. However 10x that resolution and you're already working with an almost 16 Gigabyte sized image (single white layer). Talking about the size inside a program like Gimp, not the compressed filesize on disk. The article on the wiki is a bit dated on this topic talking about adjusting OFP-maps to Armed Assault, but they do talk about pixels/meter as a guideline, which makes more sense to me. I'm only going for an area of 8kmx8km. For 1m/px resolution, that would mean a sat-image of 8192x8192 pixels would have the same visual quality as Sahrani. I have no idea what m/px resolution is used on the Arma2 maps, but because I'm aiming for high resolution geometry, maybe I can get away with an Arma-level of detail terraintexture. For people working on huge maps, this could be a problem, unless you have an absurd amount of RAM. Maybe vector-based image editors would be a better better choice then, could be something to look into. Another possibility would be to use a very fast ssd as swap-disk.

Thanks again for taking the time to answer me Bushlurker. I read your pdf-tutorial a couple of times and read the Biki pages repeatedly, maybe because of the similar names, but somehow it just didn' t land. Or as the Dutch saying goes, the quarter(It's all about the money) didn't drop. Hmmm, Photoshop, damn, up till now I managed to work around this particular requirement, because I can't justify the price for it compared to my use for it. I' m not too keen on the less legal download options, I'd rather go for free alternatives like The Gimp. I'll see how far I can go once my ram-upgrade arrives, or get really creative.

Have to be a little patient, apparently I ordered my RAM-upgrade just as the store ran out of stock. In the mean time I've been researching the other parts of terrainmaking and texturing and noticed that the biki articles aren't very in depth. Leaving me with a number of new questions. First about the xyz-format, are there any known converters for this xyz-format to and from more standard 3d-fileformats (like .obj)? I can work with the png/pbl set for now, but I wouldn't mind the increased control of a 3d-mesh. I can imagine that even a 16bit grayscale image would limit the heightresolution in case of more extreme terrain differences. Second about textures. As I understand it now there are 3 textures visible on the terrain. Close by the texture defined in the rvmat for that type of terrain, then a (alphamapped?) detailmap texture further away and then in the distance the big satellite image covering the whole world. Is this correct? I've only seen people talk about a single detail-texture. Is it possible to have more of these detail-textures, one for each of the 4 types of terrain? Also I'd like to know at what distances these transitions occur. This would allow me to guestimate a minimum texture-size I could get away with for maximum performance and acceptable quality. While I'm at it, does the large worldwide satellite texture affect the terrain color right at your feet? If not, is there another way to make color-variations possible instead of having the exact same looking 3/4 materials covering the entire world? Also in the biki there was quite a bit of talk about blue lines, blue and such, accompanied with a number of puzzling formulas, which left me completely baffled. Do I have to do something else than just creating a single big texture-image? Thinking about the memory limit of arma2, does this also mean there's a size limit to the satellite image?

Thanks for the info, Bushlurker also gave me some tips in the official terrain-editing thread. By the way, there seem to be quite a high number of Dutchmen active on this forum. I'm aiming for 2 meter cell size, which I'll try to compensate with a lower resolution texture. Ideally I'd like to incorporate some historic ditches and trenches, which I doubt will look convincing in 4 meter steps. But before that I'll have to upgrade my pc, I've reached the end of what she can handle. I even tweaked the hell out of my Linux setup and used a different memory manager for Blender, but I'm just 1 Gb of ram short for the next level of detail. I've started working on small parts, but that's taking to much time and concentration. I was looking for a ram-upgrade, but for double the price it seems that I can upgrade my entire system to a 6 core 8 Gb set. I think it's about time for an upgrade then, I'll collect some information tonight and go to the shop tomorrow, so I should be up to speed again pretty soon.

Thanks again for the info Bushlurker. Still can' t believe how I missed this section of the forum, somehow I completely focused on the OA section. I hope BIS reworks this water business in the future, since it leaves a rather large part of the populated areas of the world out of the equation. Holland for one, here a lot of the land is well below sealevel and most certainly below the elevated canals and rivers. That's where all the water from the land is pumped into. Hurricane Katrina, Bangladesh and the recent floodings also kind of illustrate just how much of the heavily populated areas are below 0 meters. Fortunately the terrain I'm working on is mostly designed to be flooded, albeit less frequently than the tides. Could make the map more interesting if you're not always able to take the same routes. I'll just have to be creative with the surrounding area and figure out a way to fool the players. There may be a workaround for the AI not seeing the pond objects though. Just as the ponds are invisible to the AI, the opposite can also be true. What I mean is that the AI is able to detect and react to certain objects, but that does not mean that the object has to be visible to the players. ... Aha found something, in a thread I had completely forgotten I ever started. This was for armed assault however, so I'm not to sure if the things I discovered there also apply to the Arma2-engine. Damn never did get to finish that project, because of a stupid mistake I made, think along the lines of " format c:". Anyway there are a couple of things to try to block the AI from pond-objects in the form of "invisible" LOD's. Either by modifying the current pond p3d, or as a separate object to be placed in the same location. I've no idea if this could work for very large area's, I only tested it on that building which was just a bit over 100 meters long. Another option would be to find a willing arma AI scripting guru, to help us find a way around (water)obstacles for the AI. Compared to some of the demonstration videos I've seen on Armaholic, you would think that it should be easy enough. Otherwise there might be another chapter in your tutorial about adding custom LODs to your map so that the AI moves as it should.

Nice map Frostybowman. How did you manage to get such nice watery rice paddy fields and tight transitions of water in general? I'm also working on a river-map and using sealevel as a workaround to get my river. However I'm having a trouble with the combination of low lying land and the seasurface shining through the ground, eventhough it's 1 meter or more above sealevel.

Yes! Bushlurker, thank you! I got it ingame, framerates are acceptable on my system. Screenshots mosty with 2600 viewdistance (was playing around with the setting to test framerates). Maybe I should let other people test the map as well. Still some oddities, like water shining through some surfaces although they are about a meter above "sealevel", but the heights are very close to real life now. Hmm, nice line sight from the hill, pretty obvious why the Germans had a hard time here. Anyway, this is a big motivational boost for me. EDIT: Some reallife photos from the net for comparisson. 1939 - http://www.grebbeberg.nl/index.php?page=photo&pid=1061 more recent: http://v3.cache3.c.bigcache.googleapis.com/static.panoramio.com/photos/original/3263629.jpg?redirect_counter=2 http://v22.lscache3.c.bigcache.googleapis.com/static.panoramio.com/photos/original/14486398.jpg http://v7.lscache5.c.bigcache.googleapis.com/static.panoramio.com/photos/original/22255862.jpg I'm a little surprised how close to reality it already is.

I'm in a similar situation, my preferred OS is linux. I also run macos and window 7. I'd be really really happy if I could run Arma on something other than Windows. Windows 7 may be a step up from xp, but that is not saying much. When I'm forced to use Windows 7 it feels like an archaic system and it's a resource hog as well (not something to boast about if you like to run simulation games). You could keep an eye out on the wine project (winehq.org or codeweavers), which is also available on MacOS. It'll run operation flashpoint just fine, but the menu buttons don't work in the newer engines. It does render the 3d stuff, which makes it tantalizingly close to working.

@_William: I've downloaded pretty much every remotely useful image from that site. My intent is to make the May 1940 version, but as you said I have to figure out the whole pipeline first. Ideally I'd like to include stuff like the trenches and destroyed buildings. Simulating a war in a picture perfect town with even the windows intact kills a lot of the immersion for me. But first I want to figure out a nice balance between terrain detail and framerate, it also depends on how much time I can spend on it. At the very least I'd like to have cobblestone roads and little things like that. Leaving out the "Kazematten" would almost be blasphemous. Not much to show today, I'm currently working through Bushlurkers excellent tutorial. I've tried copying SgtAce tutorial configuration and edited it to suit my terrain and naming. While doing this, I think I may have found the main culprit for low framerates. It probably is the texture per meter setting, from what I've learned modding for other games is that textures tend to have a far greater impact on framerates than polycount. I am getting very decent framerates in buldozer now, which loads the textured version of the terrain just fine. However once I pack the map and try to load it in game I get an rvmat error and the game crashes shortly after. I just want a very simple material so I can test the terrain, but apparently I'm doing something wrong. Trouble is I'm not getting any error messages in any of the preceding steps, which makes it a lot harder to locate my mistake.

Oops, hadn't occured to me to check under the Arma2 section for a terrain subforum, I picked this one because I saw some other folk posting their island threads here. Maybe this thread should be moved then. @Bushlurker: Whoa, you've got some impressive examples there, nice work, I'll try those out asap to check the framerates. Oh another tip, maybe Sculptris would be better suited for sculpting terrains, it's free to download at the pixologic site and has a very easy UI. I didn't use it this time, because I needed to follow a reference image. Also I'm familiar with Blender, but it took me quite a while to get used to the Blender interface (and now I have to start all over again with the new Blender). I did get srtm and Aster height info for the area. Unfortunately the Aster data for my region is damaged with large bands of missing data and srtm is too crude for my needs. Also Aster seems to have some odd quirks, where forested areas are interpreted as valleys and water pits as high peaks. In the end I did use one of the geotiff images as my utm base reference and projected the other reference images onto that. I also used Blender for this, because I couldn't figure out the GIS-apps that supposedly can very easily georeference and reproject images to UTM. Eventually I found a website with a googlemaps style representation of heightmaps made with lasermeasurements. I took a couple of screengrabs, merged them in The Gimp (no not the movie character) and then manually replaced the elevation colors with my own grayscale ones. This helped in giving me a starting point, but looking back I could have saved an enormous amount of time if I had gone straight to blender. Okay here's what I have sofar, the hill sections are still very crude and I have to adjust those to arma sealevel. I haven't even started on the north and south areas: I'll try getting this ingame first to experiment with cellsizes. I've exaggerated some features in case I need larger cellsizes. Pending the results I may do another detailing round. Got to say though with each level of increased detail the workload seems to double. I already feel like I've walked 8km a couple of times over. I'm starting to feel a new found respect for the amount of work Bistudio put in their maps with all the detailed villages and cities.

Ha, I won't stop anyone from adding what they want once it is done, but don't expect a lot of intense figthing when there are coffeschops around. Little update (with and without satellite image and transparent waterplane): Small section of the map, because I have limited ram I had to split the thing up. This the area east of the hill (part the hill is still visible) and north of the river. I expect most of the activities on the map will be in this area. This is the area between the river and the winterdyke, should the water in the river rise this area would mostly flood, but I'm afraid that won't be possible in the arma engine. The rest is not as detailed as this yet, but it's getting there. If I find the time I'll work on it some more this weekend. I'm pleasantly surprised how easy and fast sculpting a terrain is. Way more intuitive than working with 2d heightmap or some of the other terrain editors I've tried. Being able to toggle the googlesatmap on and off is a big plus as well.

I'm going through my DAC-calls with a microscope at the moment, if I'm unable to work it out, I'll pm Silola. Currently DAC is the best thing I could find for generating not so random points and I'm staying very close to the way DAC was intended btw. I'm only integrating it in my own setting. Everything else is working, I just thought that DAC-camps and DAC-artillery would add a nice touch. The way I've set things up now should make it easy enough to replace DAC with something else. In the future I was thinking of making the use of GL4/UPSMON optional via a parameter at missionstart. Could be, I'll make my own camp/units generator in the future.

Title is not set in stone, but somewhat captures what I'm trying to do. This all came about because of me getting fed up with a couple of mp-missions. Before asking for feedback I'll elaborate a bit on the context. The problem I have with making my own missions is that I don't like playing them. I find it very difficult to be unpredictable to myself. However it seems I may have found a way around that with the mp-mission I'm working on now. The setting is a country not part of the G20, divided by 2 factions at war. The players in the role of mercenaries trying to cash in on this business opportunity. Small teams of 1 up to a maximum of 4 players for each team competing with each other in a living, breathing sandbox world. First I'll describe what I've done sofar and which seems to be working surprisingly well. I still get more than playable framerates on my 3 year old pc, with most settings turned all the way up. Using the improved BIS-modules the world is no longer desolate. Towns have civilians in them, sometimes driving on the roads and there's wildlife all around. Next I've made a script which does the following: At the start of the mission territory is randomly divided between the two factions in the form of connected towns. Those factions take turns trying to conquer each others territory. To keep framerates manageable only two towns duke it out at a time. Supplies are distributed across the network of connected towns of each side, and this will decide what kind of forces are generated for that particular town. If a town is captured this will change the supply distribution on both sides. It surprised me how well this works, big thank you to Silola for DAC. I've laid the foundation for the missiongenerator I'm currently writing, which will hook into the above turn-based war. The outcome of side-missions like blow-up the fuel-supply or steal the payroll, will have an effect on supply state/number of troops available for one of the towns in the coming battle. It's with the main objectives and scoring system that I could use some feedback. I'm having a hard time coming up with an alternative to the Vietnamwar scoring system, which is still rewarding for players and competitive at the same time. The basic idea I have, is for the players to compete with other teams via objectives and playing smart, instead of impersonating Rambo. Couple of possibilities I've come up with sofar. - Similar to the tabletop game Risk, each team is assigned a random objective at the start of the mission and all teams try to complete their objective(s) before one of the other teams does. - Money, earn/grab/steal and collect the biggest stash of cash. - Mutual exclusive objectives, both teams fight for the same objectives, but from opposing sides. A bit like domination team vs team, but on a smaller scale. As I said, I've seem to have run into a bit of a creative dip and would appreciate some ideas and suggestions.

This thing is fighting me every inch of the way. Everytime a fix one bug, more of them pop up. This time I suspect that I've run into a bug in DAC. Somehow after a first war-round between 2 towns, in subsequent wars DAC places all generated camps in the exact same spot, which seems to be the campsite from the very first time DAC_fchangezone is called. I've only noticed this now, because I had camps turned off till now, to make testing faster. I'll ask in the DAC forum if there's a solution, otherwise I'll have to disable DAC-camps, which would mean no artillerie-support.

Hmm, seems I spoke too soon. I'm working on a mission which uses DAC very heavily now and I just noticed units deserting to Map-coordinate 0,0,0 eventhough the DAC-markers are off. Although in my case it only happens occasionally and only for a few units at a time. I started a thread about the same issue, but can't find it anymore. Someone mentioned having similar issues with upsmon and he had to hide the markers or something like that by making them transparent. I suspect DAC is using a marker for some of it's mechanics, but I haven't got a clue how to "hide" it. So it seems I'm in the same boat as you now and also in need of a workaround. Guess I'll try finding a way to locate markers and setting them to transparent.

I had the same issue and what solved it for me is to disable the DAC-markers. There seems to be a hidden feature in Arma2 that when a marker is placed a certain way, units will ignore their waypoints and move to that marker instead.

Big sigh of relief, that took considerable more effort than I was expecting. Took me several hours to figure out a bug with converting an array of strings to a list of arguments for a function-call. String conversions in arma are plenty difficult. Didn't help that I had very little time to spare this month. Anyway, in the little time I had left do some tests, all seems to be working well, except for a bug with the turn-based background war. How it works now is that at the start of the mission a couple of scripts are started in parallel. One of those is turning on and off territories from a territory-pool, depending on the distance to the players. That pool of territories is gradually being generated and filled by another script running in the background. Starting with the territories nearest to the player character. Currently generating all the territories takes a lot longer than I'd like. DAC has difficulty placing camps in a few towns with rugged terrain (currently testing on the Takistan-map). I remember reading something in the DAC-manual, about adding locations manually in the editor, which should speed up this process. After those territories are generated turning them on and off seems to be working like a charm, also comes in handy for resetting the stage for a mission. I'll also have to do some major cleanup in the future, because it is currently very messy and I put a lot of stuff in the init.sqf instead of the scripts (I got lazy and frustrated and just wanted to get it to work). Eventually I want to have a single script-call with some arguments/parameters, and one central place for all customizations like units to generate, area of influence and such. Things left to do, before I have a testable demo-mission: - Working out the bug with the new victory-system I had to make for checking which of the towns won the war. - Writing a new mission-generator for my rewritten dynamic war script. - Come up with a good name for my script, which describes what it does. - replacing the default DAC units and camps with custom versions. (Using the default DAC-settings, feels a bit unbalanced, suddenly being confronted by a tank-platoon, while driving around in my rusty car with my trusty old pea-shooter.) - Make a few missions. I'm a bit tired at the moment. Once I've got a bit of time and energy to spare, I'll continue.

Little update. I'm still working on this, I had planned to have a demo ready by now, but I'm reworking my dynamic world script. I discovered a feature in DAC which possibly should make my dynamic war script far more efficient, especially if numerous human players are active. Also while working on my mission-generator I ran into a couple of things I needed which are missing in my current dynamic-warfront-script. Generating multiple DAC-zones in succession after the mission has already started takes up quite a bit of time. The current system generates completely new zones on the fly and on demand, but I'm starting to suspect that this is too slow for numerous fast moving players and multiple missions. The new system I'm working on will do all heavy cpu-stuff at the start of the mission and after that should work its magic unnoticeably for the players no matter how fast they move. I've got a couple of different solutions I'll need to test, to see which one works best. Unfortunately, because of my lack of experience, this will require quit a bit of Bistudio script-language puzzling and testing will add a big delay before I'll have a demo ready for testing.

That's exactly where I was planning to go with this. As of now I don't have a mission to test, unless you like to watch the war between two sides one town at a time (Which is actually very addictive I've noticed, far more enjoyable than most screensavers with virtual fish and such). As I said the supply distribution and background conflict is now working fully automated so the stage is set, but now I'm getting to the nitty gritty. I'm currently trying to work out a bountyboard-like feature. I hope the mission will be popular enough that a number of teams could go up against each other, but realistically I think it should work for small teams going up against the AI. Should another playerteam accept the contra-mission, the AI will then be replaced by the other team. There are a couple of ways I could implement the bountyboard-style missiongeneration. Hardest thing is figuring out a nice balance between single team missions and a large number of teams. For example, should I make every mission available to all teams, playable from both sides? Like the missions in Domination. This would mean you're not only trying to defeat the enemy and complete the mission, but also have to keep an eye on the competition so that they won't run away with the prize. Although I kind of like this idea (very easy to implement and I suspect easy on the cpu as well), I'm afraid it will be very difficult to keep this from becoming complete chaos. Also it would go against the up close and personal effect I'm trying to get. Alternatively should a mission be generated for two teams at a time (where the two teams are opponents, or AI generated as replacements if no opposing team accepts). After two teams accept no other teams are able to select the mission. Because of the turn-based flow of the background war I could also make a mix of the above. First generate a few small missions, which when completed/failed will trigger the big multi-team missions which will have an indirect effect on the following war between two towns (How much and what kind of units are available for each side, for example). After this war has finished the cycle repeats with a number of small missions generated, which if the frontline has changed could be very different from the previous round. Another point I'm considering. Should I generate a bountyboard in each town with missions close to that town? Or should the players return to a central location each time they want a new mission? First option would mean less boring long trips on the road, while the latter would mean more interaction with other players, provided the mission is popular enough. EDIT As a reaction on the mission ideas A buddy of mine was experimenting with Hitman style missions, very similar in style, change uniforms and hide your weapon, that kind of thing. The tricky part is how to allow players to do such tricky business and still register the score, like with the rigged car. As long as there are only 2 teams, tallying up the score would be easy, but add more teams and suddenly it is not that easy anymore. Although pulling of a stunt like blowing other players in their own car, would be a reward in itself.