# Mapmaking Discussion & Philosophy (WIP/Critique) > Software Discussion >  New battlemap-creation software on the way

## heruca

Hi folks. I am going to be creating cross-platform map-making software (for Windows and macOS), suitable for creating both for print-resolution maps and lower res maps suitable for use with virtual tabletop software. The program will be sort of a spiritual successor to Dundjinni, but with a greater focus on stitching maps together from pre-existing map tiles and then customizing the resulting map (with additional decorations, etc.) to suit the GM's particular needs.

The program should appeal to GMs of face-to-face game sessions and those using any VTT software, who want to create their own slick-looking battlemaps but who find existing mapping programs (including image-editing tools such as Gimp and Photoshop) too intimidating/confusing/expensive. 

In late January or early February 2017, I'll be launching a Kickstarter campaign to try to fund the program's development. The software will be priced to be very accessible/affordable, likely in the $20-$25 range (at least during the Kickstarter campaign).

I'm trying to gauge public interest in this, so please let me know if such software would be of interest to you.﻿

----------


## heruca

I think 1280x700 (ish) might be the minimum display resolution required to use my program. Would that leave many people out, aside from netbook users?

----------


## heruca

I can now reveal the name of my mapping program: MapForge

And, for now at least, this is the app's icon.

----------


## waldronate

Totally different from https://github.com/mapsforge/mapsforge then?

----------


## heruca

Completely.  :Smile:

----------


## wdmartin

Having names that similar might cause confusion.  Just sayin'.

----------


## heruca

Getting close now! The MapForge Kickstarter campaign will launch either on Feb 18th or Feb 20th.

----------


## Bogie

Looking forward to this Heruca!

----------


## Mark Oliva

Only because you asked for feedback:

1)  Will it be another outdated 32-bit program or will it discover that we live in a 64-bit world?

2)  Will it be strictly a battlemap program (as Dundjinni is for the most part) or will it be versatile enough to be a really useful application for city and overland maps too?

3)  If it will be useful for city and overland maps too, will it support objects with different scales for different types of maps?

4)  Will it be able to use PNG objects (symbols) and textures (fills) from other sources?

These would be key issues for me in deciding whether I'd do kickstarter support or buy the product.

----------


## heruca

While it is _primarily_ for battlemaps, I can see using MapForge to create town & village maps and overland/area maps. You could probably make something along these lines.


I don't really see MapForge being particularly well-suited for city maps and world maps.

MapForge can be used with artwork from your own library (PNGs, for the most part), so using existing collections like CSUAC and the Vintyri art will be nice. Textures can be BMPs or JPGs, too.

It'll run on 64-bit, but I suspect the executable is 32-bit.

----------


## Mark Oliva

> It'll run on 64-bit, but I suspect the executable is 32-bit.



Don't misunderstand me please.  You've been one of the really great assets to the cartographic community for a long, long time, and I really respect your work.  However, 64-bit operating systems have been the standard for some time too.  I have three 32-bit cartographic programs - Dundjinni, FM8 and CC3+.  I'm dissatisfied with all three because of the squeeze at the 4 GB memory border.  Even if it's far better than anything I already have, and if you're producing Master Forge it will might be, I still can't picture myself developing much interest in yet another 32-bit cartographic program.  For me it's not a still birth but rather an obsolete birth.

----------


## heruca

Fair enough. I'm limited by the development environment, so it isn't really my call.

----------


## Mouse

Don't be discouraged heruca.  No one ever learned to fly before they could walk, and its the same with software development I'm sure. 

I use CC3 mainly, and apart from the speed issue you tend to get when you have a map with 135 sheets (those are layers in PS-speak), and 350 sheet effects (layer effects), then things are going to be just a tad on the slow side - even with a 64-bit app  :Smile:   I have yet to see a bitmap app that can handle that many layers in one doc, and throw out renders (exports) at 10,000 pi square - but CC3 seems to do it ok, even though its only a 32-bit app  :Smile:

----------


## Mark Oliva

> I have yet to see a bitmap app that can handle that many layers in one doc


??? Bitmaps have no layers.  They're flat.

----------


## Mouse

GIMP is a bitmap app, not a vector programme.  It has layers  :Smile: 

Speaking from experience - although GIMP has features I can't reproduce in CC3, like the ability to variably blend one fill into another using a brush, it can only do so with a maximum of 7 layers at a time on my machine, whereas working on the very same machine in CC3 I can have at least 135 layers (CC3 sheets) in one file and still be working on it with all 350 sheet effects turned on.  That is why I don't believe 32-bit software is _necessarily_ inferior to 64-bit software.  

There is simply no way that I could have created Merelan City in GIMP on my machine.  GIMP might be a 64-bit app, but its just isn't efficient enough with the system memory and processing power to be able to do much more than a very small corner of the CC3 map I created.

The same is also true of all the other 64-bit graphics apps I have - CorelDraw 11, Corel Photopaint 11, Krita... and so on.

----------


## Mark Oliva

> GIMP is a bitmap app, not a vector programme.  It has layers


I'm not interested in arguing with you about this, but the above may confuse some others.  For their benefit:

The GIMP produces raster images, not vector images, and those raster images certainly are in layers.  However, the native format .XCF files with layers that The GIMP produces are not bitmaps.   The GIMP certainly can export the content of its .XCF raster images as bitmaps, if one wants a bitmap in the end.  And in fantasy RPG cartography, that's usually what one wants.

----------


## Mouse

Who's arguing?

I'm not  :Smile:

----------


## Mark Oliva

Back to Heruca:

Once again, I am in no way trying to put your MapForge down.  I've been following your work, mostly on the Dundjinni forum, for more than 10 years, and your contributions to the cartographic community are both tremendous and excellent.  That's exactly why I'm raising the issues that I did.  For the non-GIMP, non-Photoshop elements of the cartographic community, Dundjinni brought RPG cartography light years ahead in an age when CC2 Pro and FM7 still were stuck in vector cartography that usually produced maps that looked like something from a low grade imitation of an animated Disney film.

However, Dundjinni also is a program that burned itself out, and I would dislike very much seeing you launch a program that ends up doing the same thing.  Dundjinni is a program that didn't manage to grow with the times.  For those who still can get it to run (I can), it continues to make better battlemaps than anything I've seen (or made myself) with FM8 or CC3/CC3+.

However, when one tries to make a larger scale overland map or a city or village map with more than a few buildings on it, one gets into trouble.  The reason for this is that Dundjinni has a single scale for all objects (symbols) and textures (fills).   In comparison, CC3+ has four different scales available for each object or texture, and it automatically picks the best version of the object for the scale currently being displayed.  FM8, like Dundjinni, offers its objects and textures in a single scale, but unlike Dundjinni, FM8 has different scales for overland, city and dungeon objects and textures.  Both systems produce good results.

However, because Dundjinni has only a single (official) scale for all objects, and because Dundjinni can use only a limited amount of memory (like all 32-bit applications), one finds oneself in trouble in short order when making a map like the sample from our project group that you posted above (a map that was made with FM8 ).  When one sticks with the official, single Dundjinni scale of 40 pixels = 1 scale foot, the building objects are unnecessarily huge.  Some of these objects (symbols) have a size of more than 20 MB each.  That size isn't necessary for such a map, but it's the only official size.  In Dundjinni, duplicating the map shown above causes an incredible result.  One cannot merely make a cup of coffee while waiting for Dundjinni to draw the map on the screen.  One could in theory drive to relatives 50 miles away, drink a cup of coffee or two with them and then return home before Dundjinni is done drawing ... and that with a modern computer using SSD drives and 32 GB memory.  However, that's only theoretical.  In practice, Dundjinni will have crashed before one reaches the distant relatives.

That notwithstanding, one can successfully make such a map with Dundjinni, if one goes into a graphic program and makes new, scaled-down versions of the objects and textures being used.  I've made such maps with Dundjinni by scaling down the objects and textures from 40 pixels = 1 foot to 10 pixels.  However, that requires the creation of down-scaled versions of _every_ single object and texture used in the map.  Who wants to do that, when one can buy FM8 or CC3+ and avoid that?

That's the reason I brought up the scaling issue.  I'd like very much to see you succeed with Map Forge, regardless of whether I would use it personally.

On the 32-/64-bit issue:

This really has nothing at all to do with learning to walk before you fly.  Writing 64-bit code is no more difficult than writing 32-bit code.  But many of your potential users are running 64-bit Windows, and a substantial number of them will have 8 GB memory or more.  Many decent laptops leave the factory these days with 8 GB as standard.  People are starting to want to use what they buy.  If you read through postings here, you'll find that one of the things, among others, that are driving CC3+ and Dundjinni users over to The GIMP and Photoshop are the limited resource usage of Dundjinni and the frequent crashing and non-performance of CC3+ (If that means nothing to you, read ProFantasy's own forum).

From your last posting, I assume that Map Forge will be an application that runs on top of another program's machine, just as CC3+ is an application that runs atop Evolution Computing's FastCAD.  If that's the case, and the machine you've selected is 32-bit only, you have no alternative.  That's similar to the dilemma that ProFantasy faces with Campaign Cartographer.  To produce a 64-bit version, Evolution has to come out with a 64-bit FastCAD machine that ProFantasy can use or ProFantasy has to drop FastCAD and program its own machine ... no minor chore.

In any case, if you're committing a lot of your time and/or money to Map Forge, I hope you'll seriously address the question of how many people might buy your product over what period of time.  If it's a 32-bit edition, my guess is that most folks will look at it as an alternative new Dundjinni version, and that it will have decent startup sales among Dundjinni users who want an update.  But will it be able to sustain sales after that initial bubble breaks, or will it burn itself out and lose its market like Dundjinni did once Fluid Enterprises decided to drop the program after the big Dundjinni bubble.

You've done a lot for us here in the cartographic community.  I'd like to see you succeed.  That's the only reason for these remarks.

----------


## Redrobes

> The GIMP produces raster images, not vector images, and those raster images certainly are in layers.  However, the native format .XCF files with layers that The GIMP produces are not bitmaps.   The GIMP certainly can export the content of its .XCF raster images as bitmaps, if one wants a bitmap in the end.  And in fantasy RPG cartography, that's usually what one wants.


You confusing bitmap the generic term for arrays of pixels with bitmap the file format as in a windows.bmp file. Windows chose to make the file format named 'bitmap' to refer to the arrays of pixels when at the time of Windows 16bit there were not many image file formats about. So Gimp is definitely a bitmap editor.

For Hernan, You probably know this and I am not sure what language or OS your intending to write this new app in but I believe that if it is for Windows (given the target of 32bit) then it may be that MS make the C/C++ compiler free for 64 bit if you take the version without the maximum amount of optimization. Its been a while since I made Windows apps but I think it was called Express or Community edition. The GUI for the free visual studio compiler at the time when I looked at it was not free. I am not sure what the state of that is now. Also for Windows there is the MinGW system where you can compile it using gcc to create 64 bit apps on windows. I thought that if you were writing in Java then the JVM would be 64 bit anyway - but I am no Java coder.

Final thoughts are that even if you write a 32 bit app which has limited memory to 1, 3, or 4 Gb of memory depending on the machine set up, its still possibile to write it multi process where each process has that limit and you can transfer data between processes. Also, its not a fundamental limit of the bits / RAM that determines how many layers you can handle and if an app is written so that it targets the idea that many layers is going to be used then better handling of the memory could prevent the issue. Gimp is super lazy about how it manages the images that it holds.

Also, for Mouse, if you have layers that are greyscale (shadows, masks etc) then do set the Image / Mode to Greyscale instead of the default RGB which should quarter the amount of RAM Gimp will allocate for it. But 10K x 10K x greyscale x 135 = 13.5Gb of RAM uncompressed and if they were RGB then that would be 54Gb of RAM required. Not many image editors are going to handle that and CC3 is not going to either if those are genuinely bitmap layers your referring to.

----------


## Mark Oliva

> You confusing bitmap the generic term for arrays of pixels with bitmap the file format as in a windows.bmp file. Windows chose to make the file format named 'bitmap' to refer to the arrays of pixels when at the time of Windows 16bit there were not many image file formats about. So Gimp is definitely a bitmap editor.


I probably wasn't clear enough.  The GIMP (in native .XCF format) generates layers of bitmaps.  The XCF file contains not one bitmap but several.  For distribution, most people want "a bitmap," which requires a flattening of the image and then exporting into a bitmap file format, such as BMP, PNG, JPG, etc.

I agree with most of the rest of what you have to say on the topic.  I can't shed any new light on current free vs. not-free issues.  I retired in 2009. My son took over my Microsoft compilers.  I have no idea what's current now.

Multi-processing certainly does accelerate things, but I can't agree that it makes up for the lack of RAM at the 4 GB level when one is doing heavy duty graphics.




> Gimp is super lazy about how it manages the images that it holds.


Ainnit the truth, as my Dutch grandfather used to say.

----------


## Redrobes

Lack of physical RAM is a problem whatever bit program your using I agree. But what I was saying is that if you had say 16Gb of physical RAM and you want to run a 32bit app which then limits the apps process to being able to access 2 or 3Gb or so (depending on the setup) then you have 13Gb of physical RAM you cant access unless you use a 64 bit app. But you can run a 32 bit app which creates many processes (instead of many threads) whereby each process can run up 3Gb of allocation. So its possible to have a 32 bit app use all 16Gb of physical RAM. Most web browsers open a new tab in a new process because a) it isolates the page from other pages which is for security and b) you can have pages running up large memory footprints and have many of those pages. So what I was saying is that being a 32 bit app is not a hard limit to accessing large amounts of RAM. But a lack of memory sticks in the machine is always going to be a problem for large multi layered maps no matter how you slice it. But if you can only compile / write 32 bit apps (see herucas post #12) then its not a dead end situation for the ability to deliver large mapping capabilies.

The XCF thing I agree with you. It didnt appear from post #14 as though that was what you were saying. But with that clarification - I agree.

----------


## heruca

I do remember Dundjinni taking what seemed like hours to export the final map. I ran some tests with MapForge, exporting a 10Kx10K pixel image in 24-bit color (uncompressed size: 300000000 bytes) and it took between 8 and 31 seconds to complete the export to PNG format. Exporting to JPG and BMP format took much longer, but was still very fast in comparison to DJ.

----------


## heruca

To clarify, what I exported was just a floodfill tile texture that was randomized to make each tile different. MapForge doesn't really have layers yet, aside from a grid overlay (which adds about a second to the export time, if you export with a grid). This is being tested on an early prototype. Performance may be slower in the final shipping app (which WILL have layers), or it may be even faster once optimizations are added.

----------


## Mark Oliva

> Lack of physical RAM is a problem whatever bit program your using I agree. But what I was saying is that if you had say 16Gb of physical RAM and you want to run a 32bit app which then limits the apps process to being able to access 2 or 3Gb or so (depending on the setup) then you have 13Gb of physical RAM you cant access unless you use a 64 bit app. <SNIP>


I understood, and I agree.




> The XCF thing I agree with you. It didnt appear from post #14 as though that was what you were saying. But with that clarification - I agree.


As I said, I wasn't very clear.  I think describing The GIMP as a bitmap program with layers will leave a wrong impression with some people who don't have a lot of technical knowledge, leading them to think that The GIMP produces bitmap graphics that one can open in programs like MS Paint with file extensions like BMP, JPG and PNG.  This, of course, isn't what The GIMP does,  It produces a raster graphic file that consists of one or more layers, each of which is a bitmap.  To make this into a flat bitmap that's the kind of file many understand a bitmap to be,  the content of the native XCF file graphic has to be flattened and exported as a BMP, JPG, PNG or whatever.  I thought this difference should be mentioned.




> I ran some tests with MapForge, exporting a 10Kx10K pixel image in 24-bit color (uncompressed size: 300000000 bytes) and it took between 8 and 31 seconds to complete the export to PNG format. Exporting to JPG and BMP format took much longer, but was still very fast in comparison to DJ.


If I counted the zeroes right, 300000000 bytes = 300 MB.

That's a pretty good performance statistic.

Not a plus-or-minus point, but a curiosity.  You mention the PNG conversion being faster than the BMP and JPG conversions.  As I understand it, all three were exports from Map Forge.  A question then:  Assuming (perhaps incorrectly) that the conversion was a direct conversion from memory to new file, did you compare the JPG and BMP export times to the times that would result in converting an exported PNG file from Map Forge into BMP and JPG files with an external program?

Whatever the case, I'll be watching this with interest.  Even if the end result is nothing more than what amounts to a new and improved version of 32-bit Dundjinni, it's still more than we have now.  I'm on your side.  I hope you succeed!

Good luck!

----------


## heruca

I think you counted the zeroes right, because my BMP export was 300MB. I think most of the time saving to BMP format is spent writing the huge file to disk. The PNG export was just 4.9 MB. JPG was around 3 MB, but it took so much longer it's not worth the savings. Probably faster for a user to open the exported PNG in MS Paint (or whatever) and "save as" a JPG.

----------


## Mouse

> ...Also, for Mouse, if you have layers that are greyscale (shadows, masks etc) then do set the Image / Mode to Greyscale instead of the default RGB which should quarter the amount of RAM Gimp will allocate for it. But 10K x 10K x greyscale x 135 = 13.5Gb of RAM uncompressed and if they were RGB then that would be 54Gb of RAM required. Not many image editors are going to handle that and CC3 is not going to either if those are genuinely bitmap layers your referring to.


That's a useful tip about using greyscale in GIMP.  Thanks Red  :Very Happy: 

In answer to your last point - CC3+ uses bitmap textures to fill polygons, and most of the symbols/icons are tiny bitmap images, but none of them are stored in the CC3 file.  They are all referenced by the software and 'called' (I hope that's the right term) from elsewhere to be displayed on the screen and used to calculate the final output render/export bitmap.  Its just easier to refer to them as layers when discussing them with non-CC3 mappers  :Smile: 

EDIT: Heruca - When I made my earlier comments about 32-bit being perfectly ok, I was trying to encourage your entrepreneurial spirit, not start an argument with anyone! LOL! Best of luck with your project  :Smile:

----------


## heruca

Thanks. Not sure that anyone's really arguing, though, just clarifying misunderstandings.

----------


## Redrobes

Agreed, when designing systems the devil is in the details. Its important that the details are well understood by everybody in the same way. Small differences in understanding always lead to big implementation problems. Its not that in this case were designing it but it is important to understand the design details that Heruca is outlining.

300Mb sounds right to me. 10,000 x 10,000 x 3 (RGB) is 300 million bytes. Its odd that it takes longer to compress to JPG than PNG. Its almost extraordinary that it is longer to save an uncompressed BMP file than a PNG. In the process you have compute and I/O. Since the PNG is only 5Mb then it implies that the system on which it was being tested had great CPU performance to compress it but terrible HDD performance to store it. If you had used a slower CPU machine with an SSD I would have expected it to be very different. Also, it implies that the system did not have 300Mb of cache RAM spare to offload the file before it was saved. Most systems / OS's 'save' the file to a system buffer which then chugs it out to the HDD in the background and gives control back to the app. Its possible tho that the app tried to check the file by reopening it (or doing some kind of stat on it) which would force the OS to stall that check until the save had fully completed. I know on my app the PNG is the slowest, JPG is better and BMP is fastest. I do overlap the render and save at the same time for bitmaps (BMP files) but I cant do that for the other two tho. So maybe that skews the timings a bit. Even so I would think that you may need to check those times on various bits of hardware before really relying on them. Its a very unusual result to say the least. JPG is normally quite quick to compress and quick by being small to save so normally wins. Some CPUs have special instructions that can be leveraged to help save JPGs but a JPG library may need to ask for them at run time. If they didn't exist then it could be slower. Lots of reasons the speed could change between hardware.

I agree that CC3 is doing special stuff regarding its layers. It obviously has to in order to do 135 layers. So its not comparable to measure it against GIMP. The texture fill thing is an obvious trade off between memory usage and versatility. As an bitmap / raster / image editor (you pick) Gimp is clearly going to be able to have anything going on at any point in one image layer since it has allocated enough memory for the whole sheet. I know a lot of mappers here at the guild are artists that make great maps rather than CAD like in their approach which is why we get a lot of photoshop / Gimp users. Artists will make use of the layers at all points and so Gimp runs rings around CC3 in that respect. So you win some you lose some by taking the trade off. Incidentally its a trade off that I took with my app and as such you still needed an image editor to use it properly. In my mind CC3 and Gimp (a vector - hybrid and a raster app) operate in two separate spaces. But I know I would be fighting a lonely battle if I kept up with that argument - but I believe it nonetheless. Some apps like Xara bridge it well but no app does both sides as well as the best dedicated ones. To pick a camp one side or the other is to miss the point so to be entrenched into one side and waving the flag proudly is a poor decision.

So yeah, how to make a mapping app that handles the best of vector and raster at the same time ? If you go for one or the other then there are other apps out there already which do it well I think because its easier to persuade people of the benefits of each individually and so the graft of development has already happened. But I am in the camp that if targeting maps specifically as opposed to maps of pure art then there could be a better option. That option is still not implemented. Its a hard task. Part of the task must be to persuade / show or realign peoples mentality about how to go about mapping to the way your app is going to do it - which is something I found extremely challenging. So my very best of luck to you with your endeavor.

----------


## heruca

I have an SSD on my computer, but it is nearly full and is probably having a hard time because of that. That might explain why the BMP took so long to write to disk.

What is your app called, Redrobes? Good to see you here again, by the way.

----------


## jfrazierjr

> I have an SSD on my computer, but it is nearly full and is probably having a hard time because of that. That might explain why the BMP took so long to write to disk.
> 
> What is your app called, Redrobes? Good to see you here again, by the way.


ViewingDale.   There is an older Youtube video if you want to check it out.   The way it deals with zoom is really really cool.   If I did not have a VTT, I might consider it simply because of that feature.

----------


## heruca

Oh, I'm familiar with ViewingDale. I just thought he might have made a mapping app, rather than a VTT.

----------


## Redrobes

It started out as a mapping app but it was a requirement that it render fast so that I could do the zoom. So if I can render fast then I could change it at the same time so I added networking to it and then you could move the bits of the map over the network in real time. So it sort of morphed into a VTT. Although I think we all developed our apps at about the same time for a year or two without anybody elses apps out there as a reference, (not even google maps at the time) we all released our apps at about the same time. I recall Kloogeworks first but I am unsure it had much of a visual interface. Then around late summer 2005 we had mine, yours, and then maptool all came out within about 3 months.

I have retired my app for the time being. I am porting it to linux but it runs pretty good under wine. But I want to access the hardware graphics of the raspberry pi. Last year RPi got hardware accellerated GL driver. (I should explain for the linux bods that I want it without a desktop - i.e. no X - so no wine on rpi). I have not had as much time to devote to it so its ongoing. Doing a lot of code refactoring at the same time which makes it twice as hard but ultimately worth it. I will get there - eventually.

I did write GeoTerSys as well which is my terrain generation program. Not quite a mapping program and its command line only and a total pain to use. (https://www.youtube.com/watch?v=rDe43KserA0). It was used as part of the MeDem (Middle Earth Digital Elevation Model) build which doesn't have a web site right now tho I am told one is in the pipeline. MeDem data set was ported to Outerra which is a really cool 3D terrain renderer that is jaw dropping and totally not mine at all. So try checking out youtube medem on outerra. You can download the data and an Outerra demo to run it free but you need windows and a good graphics card. Not sure how to set it up anymore - see outerra.com for however you are supposed to do it.
https://www.youtube.com/results?sear...a+middle+earth
So I spent quite a lot of time on MeDem instead of working on VDale... Outerra has just added river support so soon we had better export all our rivers into their native format then the rivers will look good. Theres a big thread about medem on this site with more technical info and the process etc:
https://www.cartographersguild.com/s...ead.php?t=1332

But most of my maps I do over here I use another app I wrote which is a programmable texture engine which is well cool and very small. Another unreleased command line app. I don't do so many maps thesedays. Can't compete with the raw artistic talent around these parts.

Oh and always good to see you here too Hernan. You should drop by here more often. I know you have a pretty active forum yourself without having to take on others too but I havent looked at how BattlegroundsRPG is doing. In fact cant recall the last time we had VTT (software) posts - must be neigh on a year or so.

----------


## heruca

I just wanted to thank Bogie for this announcement he posted in the News subforum and Mark Oliva for this update (because it's not possible to respond in those threads). You guys are awesome!

And to update that update, the MapForge Kickstarter has since blasted past the first Stretch Goal, which means that 5 free Add-Ons will be produced and released, some of which even allow for publishing and commercial use. More info here. As for the funding, it just broke $21K.  :Smile: 

Quick question: Are CC3 symbols in a standard/open format, or in a proprietary one? Are they simply vector shapes, or is there more to a symbol than that? I ask because MapForge could work with vector shapes, so I'm wondering if that presents an opportunity to greatly expand the potential usable art library.

----------


## Mark Oliva

> Quick question: Are CC3 symbols in a standard/open format, or in a proprietary one? Are they simply vector shapes, or is there more to a symbol than that? I ask because MapForge could work with vector shapes, so I'm wondering if that presents an opportunity to greatly expand the potential usable art library.


The CC3+ vector symbols are in a proprietary format, but their line-tone character, I think, would make most of them rather useless in the types of maps that MapForge makes.

The CC3+ raster (bitmap) symbols all are normal PNGs, but be careful here!  ProFantasy has very, very tight license restrictions on its symbols.

----------


## heruca

Stretch Goal #3 has been unlocked! MapForge will now have 9 free content Add-Ons! That should help offset the modest cost of the software.

An Update will be posted tonight on the KS page to preview the 4 Add-Ons there were just unlocked.

The MapForge Kickstarter campaign now has well over 1000 backers, and 18 days remain.

----------


## Redrobes

Cool - Well done ! I have no doubt that you will deliver something excellent and worthy of their backing.

I think if I make you a software dev / publisher then you can post into the news section yourself. I thought that you had it already. Edit - checked and you do but it doesnt seem to show. Anyway, you may be able to post into the news yourself. Edit2: There you go - green name, software dev / rep.

----------


## heruca

I already have that status, I was just beaten to it.

----------


## heruca

> An Update will be posted tonight on the KS page to preview the 4 Add-Ons there were just unlocked.


Here's a link to that Update.

----------


## Falconius

Looks like a good piece of software for quick maps.  Nice presentation.

----------


## heruca

Thanks, Falconius.

I just announced a couple more content Add-Ons for MapForge, including one from Bogie. That makes around 9 Add-Ons that allow for publishing and/or commercial use, plus 9 completely free Add-Ons that make for an awesome "Starter Set".

The MapForge Kickstarter campaign now has close to 1300 backers, and 12 days remain, during which the last Stretch Goal will almost certainly be unlocked (just $3K to go).

----------


## heruca

The last Stretch Goal was unlocked with 9-10 days to spare.



I also added a new Pledge Level, for people who want to publish or use their maps commercially and want a bundle discount.

----------


## Mark Oliva

> I also added a new Pledge Level, for people who want to publish or use their maps commercially and want a bundle discount.


Where is the information on this?  I'm unable to find it on both the kickstarter site and the Battlemap Games site.

----------


## heruca

Along the right hand side, where the pledge levels are listed (if on a PC, it's a different layout on a mobile device).

Also see the new block of bold italicized text I added to the "Add-Ons" section of the project page.

----------


## Mark Oliva

I'd add that on my machines, you need to click the "Campaign" menu option to get there (Windows 10 PCs).

----------


## heruca

Ah, I thought that the campaign tab was the default for everyone, and that from there you could choose the FAQ, Updates, and Comments tabs. Thanks for clarifying.

----------


## Mark Oliva

All's well that ends well.  I got there and you got my hundred bucks.  Everyone should be happy.

----------


## heruca

The MapForge Kickstarter campaign is down to the last 2 hours!

Now with over 1800 backers. All Stretch Goals unlocked (again!).

*MapForge is now officially the highest-funded mapping software project on Kickstarter, by a decent margin.*

Read this Update if you've been on the fence. It might just change your mind. 

Always try to end on a high note, they say.  :Smile:

----------


## heruca

Final funding: $82K
Backers: 1828

Thanks to all the CG members who backed this project!

----------


## heruca

Just popping in to let people know that MapForge v1.0 was finally released last March. There were some initial hiccups, but some quick patches and bug fixes got most of the issues smoothed out, so MapForge is currently at v1.0.3, with v1.0.4 expected in a couple of weeks.

MapForge also has a new website on a new SSD-equipped server, and the MapForge Store is finally open for business.

I'm now running a new Kickstarter campaign to get more content Add-Ons developed, with a strong focus on Sci-Fi and Modern, this time around (as most of the 50 current Add-Ons heavily favor Fantasy).

----------


## heruca

> I'm now running a new Kickstarter campaign to get more content Add-Ons developed, with a strong focus on Sci-Fi and Modern, this time around (as most of the 50 current Add-Ons heavily favor Fantasy).


Now 50% funded, but only 59 hours remaining. New Stretch Goal announced.

----------

