Some old svgmap document

So, what does one do when bored and looking a way to write something even remotely meaningful, but not too public, at least yet. Write non-shared articles in google docs for possible publishing later? Yes, here is the first one. Not too great, but it has information not found elsewhere.

Svgmap is project forked from Canthan(is a rewrite of The Peli(many rewrites of it before it)(is a python rewrite of the Coolbasic version of The Peli)) with and aim to investigate the possibilities of using SVG as a source of map data.


Rationale: There is plenty of good SVG editors(Inkscape for example) so there is no need for a separate map editor. No need to design one from scratch.

Challenges: SVG is more complex format than a simple text file and has numerous features like bezier lines, so not everything can be supported easily. Different editors also express certain things different ways, some use absolute coordinates, some relative. Some use layers in addition, some use matrix transformations. This variety makes it harder to make a simple parser that supports multiple editors. Must pick one and focus on it or support every possible variation.

The plan: support only a few very core features and ignore/fail at the rest. For example use only paths with 3 points for landscape(and not with 4 or n, also don't support polygons with 3 points even if they are basically exactly the same thing) and circles for things like flags and other interactive things.


If it'll ever even get to there(functional version exists, but it's... unpolished). Possible game modes could include capture the flag, king of the hill, [team]deathmatch and even race. More 'exotic' modes could include cargo(bit like one flag ctf, competing teams and bases, central point where cargo can be gathered and then must be brought back to base, lose some cargo on every hit maybe)

Addendum: a look back

SVG is a viable, but too diverse/unfocused technology to be used right away. It might be reasonable to use custom map format and tools for the sake of productivity and ease-of-use. Also, additional features would be much easier to implement. What followed was eventually the editor connected to the project USG.

Addendum: additional technology used

Cool vector graphics need particle effects and bullets, lots of em. Python/numpy reached performance limits, so had to finally learn C++ to first write a pipe based collision detection calculator, and then a DLL. DLL offered much simpler interface to C++ methods, so moving few fairly heavy drawing functions and particle effects to it was a great way to boost fps. Because python side of the game handles events/resources and actually everything else, the C++ side was fairly easy to code.

PS: Don't underestimate sound effects. They make everything feel much better.