Myself and a regular VASSAL opponent are considering creating a personal-use WitP module. Before I commit myself, I want to know how many hours people think it will take to create the module, and, more importantly, whether VASSAL and 2 MB RAM can handle such a huge game!
I have over a decade of experience with Photoshop, and have converted ASL maps into VASL in the past. Neither me nor my opponent has much experience with programming.
Questions:
Given that DG’s WitP uses 7 mapsheets, and hundreds of smaller maps for tactical island combat, will this even run on VASSAL? I would imagine that the tactical maps will be in seperate windows. Does VASSAL preload all these island maps when you open the module, or will it load each map only when its window is opened?
My plan is to scan the maps and save them as .png files with as few colours as possible. This worked fine with the ASL maps. Do you think this will work fine for WitP? Will I have to use the same colours on every map to keep memory down?
Can anyone give a rundown of what kind of work I’ll have to put into converting the 9000+ counters?
From my perspective, I believe it will involve scanning/cropping each counter, naming it appropriately, and saving it with as few colours as possible. Then my opponent will assign them attributes and organize them in various counters windows.
If anyone has any other suggestions, comments, or ideas on how to make this work, please let me know. If a vassal module is a viable option for this, I will certainly be posting here more often in the future.
First, you absolutely must use prototypes. If you don’t know what they are or how to use them, read up on it and/or ask questions in the forums. They’ll save you much time & headaches down the road.
Second, decide on a counter dimension. I’m using 70x70 pixels for War of Resistance because I like the ability to see key areas up close. This is likely too large for WitP, although I don’t know what the counters look like. If they’re NATO, you could probably drop to 50x50 and still get by legibly.
Third, find a graphics editing program that lets you run batch processes. I use Adobe Fireworks. I take a hi-res countersheet scan, delineate slice lines (~10 minutes for a 280 counter sheet), then the program outputs 280 individual squares individually named by row & column on the sheet. I can process the front and back of a 280 counter sheet into matching image pairs in less than an hour.
Fourth, decide on an organizational structure for your counters in the module’s counter window. This puts more work on YOU the author, but saves the players a LOT of time when they’re looking for one specific unit.
Fifth, load em up. As yet, there’s no speedy way to do this in VASSAL. But as mentioned elsewhere, v3.2 will incorporate an autoloading script of some sort.
Lastly, are you hell-bent on creating one master campaign module RIGHT NOW? Or would you be satisfied with picking one smaller scenario and designing expressly to that while you wait for the counter autoloader and v3.2 to appear?
I would expect early svn builds of 3.2 including the autoloader to be available in one to two months. While it would be inadvisable to build the module using 3.2, you will be able to use the autoloader, then cut and paste stuff out of the buildfile.
I would agree with Shad’s comments regarding a staged build. Get your prototypes and palette structures sorted out with a few hand-built counters. Then, when that is loaded, do the bulk load.
For free software to do the same sort of thing as Fireworks, GIMP has the same counter cutting capability and ImageMagick is great for batch image processing.
Don’t even think about leaving the counters named as Fireworks/Gimp names them, you will be asking for trouble.
Rename the images with names that match the text on the counter. It’s a pain, but makes life SO much easier down the track.
The autoloader required that there be something in common between the front and the back image names (e.g. us-4thmar-1/1.png and u3-4thmar-1/1-back.png. I have always used this scheme in all modules and it makes it simple to find the correct one when you ‘misplace’ images.
Also remember that for counters with multiple copies on the counter sheet, you only need to create one in Vassal.
Hi guys, thanks for the advice! I’ve used photoshop to batch process stuff before, but I’ll definitely look into the other packages to see if they work better.
The most important question about creating this module still remains…
This is a huge game, with hundreds of maps! Given the memory management architecture of VASSAL, will it even work? Like I said, the individual tactical island maps will be in a series of seperate tabbed windows, or something like that. If VASSAL has to load all these maps at once, I think I might as well not even bother, because it’s going to be incredibly slow, if it works at all.
If, however, VASSAL only loads the individual island maps into RAM as their respective windows are opened, then saves and closes them as they’re closed, I think we’ll be fine.
Does anyone have an idea of how this will work, or have any suggestions on how to conserve RAM when creating a module of the size?
That’s not what he’s wanting. When you have a countersheet, the leftmost
front matches the rightmost back. Matching fronts with backs is not
something to do with ImageMagick, but rather something do to from the
script from which you’re calling ImageMagick.
VASSAL 3.1 (to be released over the weekend) loads map images when they’re
first displayed. Map images which are never displayed are never loaded, and
map images which are not currently being displayed are sometimes unloaded
in order to recover the memory. The thing which is most important here is
that no individual map image is too large. Don’t merge all 7 mapsheets into
one gigantic image, and you’ll be fine. I wrote all of the code which handles
this, and if it turns out that you’re not fine, I’d be interested in doing
further performance tuning in order to make it fine.
If you’re reducing the number of colors in order to save RAM, you are
wasting your time. Reducing the number of colors will have zero effect on
memory usage. Zero. All images are stored in memory as 32 bits per pixel
so that no conversion is necessary when painting them to screen.
Reducing the number of colors in order to make your image files smaller
is probably also a waste of time, as we’re certain to have the new web site
up before you finish this module, and we’ll have a much higher module size
limit than we do now.
There is one case, however, where you can do something worthwhile which
will reduce the number of colors in your image files, which is cleaning
up your scans. You’re likely to have a lot of hexes on your maps which
contain nothing but ocean, and so should be a single color. However, when
you scan them, you’ll end up with some slight variation across such areas.
(This can come from thermal noise, paper texture, poor quality printing,
and probably some other causes I’m forgetting.) Cleaning up this noise—
that is, making areas which should be constant-colored actually constant
colored—will, as a side effect reduce the number of colors in your image,
and probably also reduce your file size quite a lot. This is worth doing,
because it will improve the appearance of your images. The fact that it
is reduces the number of colors is only incidental, however.
I would think very hard about creating the counters as Scalable Vector
Graphics (SVG) instead of scans. If the counters consist of mostly repeated
design elements (ship symbols, boxes, etc.) and text, then you could save
yourself an enormous amount of time this way, and get much crisper results
at the end.
I did this for The Longest Day, which has approximately 3000 unique counter
faces. First, you need to create a library of design elements. For example,
you’d make the various symbols for land units and ships. Then, you enter
all of the data from the tokens into a spreadsheet. Finally, you generate
all of the SVG images from the design element library and spreadsheet data
using a script.
Some major advantages of this approach are:
Your pieces are rendered at the right size when displayed, and are not
just scaled bitmaps. Scaling bitmaps causes blurring, while scaling SVG
does not. Futhermore, scaled scans are going to look worse than scaled
hand-created bitmaps.
You can easily alter large numbers of pieces all at once if you’re
generating them. If you decide that you want to adjust a large number of
your scans, that will be a big job.
Vector graphics tools (like Inkscape) are better suited to working with
line art (which is what almost all wargame art is) than bitmap editors are.
Game art is not an array of pixels, but a bunch of geometric shapes, and so
working with it that way will be more pleasant.
Presuming that you actually meant 2 GB, then yes it should work. (2MB
is kinda small.)
I don’t think the maps will be an issue. There is a module for The
Gamers “Case Blue”, which is gigantic. In fact, you might want to
just try to start that module to see if the performance is adequate.
Well, that really only affects the module size. The in-memory size of
the images depends on their dimensions and not really on what format
they were saved in. Again, since Case Blue works, I would think that
WitP would also work.
How many different kinds are there?
I’ve never played, or even seen, War in the Pacific, so I don’t know
if it has unique individual counters or just lots of generic forces.
You really only need to create counters for each unique one.
Also, if these are the standard Nato-style counters without a lot of
specialized artwork, you may be able to make most of them using the
counter building tools (if forget the actual name of the tool) instead
of using scans.
Thanks for the information, guys. I’ve definitely learned a tonne about creating a VASSAL module before I’ve even started!
But I’ve also come to the conclusion that I’d be spending a lot of my precious wargaming time making this module - which I wouldn’t even be able to share with the general public, because Decision Games isn’t into that. I already spend 6-10 hours a day on my computer making graphics, not sure I’d want to do something similar for “fun” afterwards.
Bottom line is, I think I’ll buy a game that already has a wargame module created in VASSAL!
I really appreciate all your input into this, everyone. And I definitely appreciate the time you’ve all spent creating other modules…
(tar, I have used Case Blue, and it works fine. It’s not the size of the main maps I was concerned with, it was the hundreds of other maps in addition to the 7 main maps)
(uckelman, thank you very much for addressing my questions directly.)
When dealing with thousands of counters, I have found it extremely useful to be able to identify the counters by their name only - it has saved my sanity many times. If the names include the unit designations etc. then it also makes it simple to run your eye over them and identify missing units etc. In a large project, you will accidentally delete, misname or just lose counters and trying to find the missing one in a sea of generically named counters can be a nightmare.
I didn’t find having numeric filenames (093.svg) for coutners to be a problem
when I was making the TLD module. This is because I was generating all of my
counters, not editing them individually. If you are individually editing your
counters, then having meaningful names will be a boon.
As for deleting or losing counters: Use version control. Version control
exists precisely to help you with long-term projects where you want to
make sure you don’t lose all the bits.
I know that Decision Games doesn’t support a public VASSAL module, but Kevin Ankoviak and I are planning on making a VASSAL module of the game for our own personal use. This might take all summer - but it would take less time if other WitP players wanted to pitch in.
If anyone is interested in sharing the work, and sharing in the final product, please send me an email and we can start planning.
