|
Apple Mac Printer Utility
|
An Apple Mac version of our printer utility would be useful, as we have quite a high
proportion of Mac users (turn-based games do seem to suit creative people).
We're thinking that C might be the tool to use for something to work on older Macs if
that's thought worthwhile, and Object C should do the job for newer ones.
The Delphi source code of the printer utility is not commercially sensitive, and the
Pascal source of the original DOS version is even less so, which means we should be
able to provide those to work from.
|
|
Linux Printer Utility
|
A Linux version of our printer utility will probably be wanted sometine. We can
easily produce a Kylix version, since the Windows version is maintained in Delphi,
but Kylix is installation dependant. Not all Linux users would be able to use it.
So the same situation applies as for Macs, to duplicate the printer utility using
a system that does deploy across different Linux platforms.
Not as important as a Mac version right now, but probably more important in the
long run.
|
|
Turn Analysis
|
In almost any of our games there's lots of data that could be extracted from the
game reports and stored, analysed and presented in other ways, cross-referenced,
summarised or turned into graphs or graphics. The game report is a simple text file,
so it's not too difficult to read.
It's a fair bet that other players would be interested in utilities that did
things like that.
|
|
Map Utility
|
We've got a number of games that use maps.
For several the maps are available as image files.
Quite a lot of players colour them in, using either the paper or the electronic
versions.
A smart piece of software might be able to extract the information in a game report
and colour the map automatically.
Then the same map could be made available to everyone online very quickly, or
people could generate their own.
|
|
Printer Graphics
|
At present we have no graphics in our game reports, just text. Even for the games
that have maps there's only the very limited map in Dark Age (which hardly qualifies
as a graphic).
The printers we use are quite capable, however, and a mixture of line graphics and
text is quite feasible (that's how the Dark Age map works - the same approach would
still work with a more detailed image).
For maps what's need is a utility to convert a simple image file into an even
simpler bitmap with a format and dimensions specific to the capabilities of the
printers (which in this case is a linewise bitmap). That could be handled by our
software (in Pascal) and so integrated with our game reports.
The same system could then be used for all sorts of other purposes.
It looks feasible in Delphi, where there's bitwise access to the canvas object and
a facility to read images directly to the canvas, and that probably means it can be
done the same way in any other modern language for Windows or anything similar.
It's something we'd be doing ourselves, except there's always something more
urgent that needs attention.
|
