Last time in the developer series I started our Dynamic Dungeons project with the intention to showcase how to make some simple tools for a more fluid dungeon editing experience. In this issue, I will continue on with that project, and add some improvements to it, such as taking care that our entities are placed on the right sheets, meaning we will need to dive into sublists, and I will also automatically generate walls to go along with our floors.

As last time, I prepared a short video to show the tools in action. At the end of the video, you’ll also see that I show the classic dungeon tools correctly interacting with my entities.

To be able to follow this article series, you should have read my earlier articles in the series.

Continue reading »

In this article in the development series, I’ll start putting the things we have learned into some proper useful commands for CC3+. I’ll be going for designing a set of dynamic dungeon tools that focuses on making the drawing of a dungeon quick and easy. In particular, I am aiming at making a set of tools that lets you draw the floorplan in a more fluid manner, and easily do things like changing the shape of a room by adding a small alcove or similar, without manually manipulating the entities. I am also making sure that the floor will always be merged to a single polygon so we avoid breaks in the fill pattern.

This will be a series of several articles, so in this first article we will be getting started with the basics. We will start by writing the code for drawing polygons, and we will see how we can merge them automatically to a larger polygon. This should give us a great starting point, which we will build upon in future articles. This short YouTube video shows a demo of what the code below achieves in CC3+.

To be able to follow this article series, you should have read my earlier articles in the series.

Continue reading »

This is the fourth article in my series about XP development. To understand this article properly, you should be familiar with the contents of the previous articles.

In this article, I’ll be taking a closer look at how to interface with some of CC3+’s own functionality, in this case how to set CC3+ variables and how to call native CC3+ commands from an XP. I’ll be showing you how to use the SetVar and ExecScriptCopy API calls.

Continue reading »

This is the third article in my series about XP development. To understand this article properly, you should be familiar with the contents of the previous articles.

When writing commands for CC3+, we frequently need to communicate with the user. This is often in the form of requesting some data from the user, such as where to place a node or which color to use, or we want to provide information to the user, such as instructions on the command line or the information the user requested. In this article, I’ll talk about the Text Formatting & Output Service (FormSt) used to prepare data to display to the user, and the data request format (ReqData). We have been touching both of these briefly in the two prior articles, but it is time to discuss these a bit more in depth.

Continue reading »

Welcome dear cartographers, to the June newsletter! Now that half of the year is over, GenCon looms on the horizon.

News

• • The June Annual with Jean-Michel Bravo’s “Ancient Tombs” style pack has been available for download since the start of the month.

Resources

• • Use the Symbols in Area command (SYMFILL) to create drawing tools for scattered woods (as opposed to dense forests).
  • We have a new selection of Maps of the Month for June.

Articles

• Remy Monsen looks at “Entity Basics” in his new article on developing plug-ins for Campaign Cartographer 3+.
• Ralf continues the series of articles on creating your own map styles, looking at editing fill styles and creating new ones.

This is the second article in my series about XP development. To understand this article properly, you should be familiar with the contents of the previous articles.

In this article, we’ll talk about how we can manipulate our drawing. In CC3+, a drawing is really a series of entities, so we are going to have a closer look at what an entity really is, how to create new entities in the map, and how to access and manipulate existing entities.

Entities

Everything in a CC3+ map is an entity; a symbol, a line, a landmass and so on. This term should be well known to all CC3+ mappers, as it is the term used in official documentation. However, it isn’t just these visible things that are entities, almost everything stored in a CC3+ drawing is an entity, such as a map note or an effect. We can view an entity as a data container for one specific thing or aspect of our map.

When working on an XP, you are almost always going to be handling entities. After all, manipulating entities is needed no matter what you want to do with the drawing, including extracting information from it, so understanding how to work with these is very important.

Continue reading »

Campaign Cartographer 3+ is a a very configurable and extensible program. In addition to the core program, users can purchase official add-ons, providing not just new artwork, but also new tools. Users can easily add new artwork such as symbols and fills, and many users with an artistic talent create such resources themselves and import into CC3+ for use with their maps. It is also easy for users to create their own drawing tools and organize symbols into symbol catalogs. For the more advanced users, it is possible to customize the menus and toolbars, and write macro commands which can be used to add additional functionality or automate tasks.
But, the most powerful option is the possibility of writing your own add-ons, or XP’s. While you can do a lot with macros, you are still limited to the commands actually provided by CC3+. Clever combinations of these commands can yield interesting results, but sooner or later you will run into things you can’t do. And this is where XP development comes in. By writing your own add-ons for CC3+, you get direct access to the building blocks of your drawing, and can write your own commands for CC3+ to do all kinds of stuff.
In this series of articles I will teach you how to write these add-ons yourself. A word of warning here; these articles will teach you about XP development, but I’ll have to assume you actually know something about programming, and in particular, C++. If you don’t know that, I recommend you find yourself a free C++ tutorial on the internet and start there before coming back, as you will have problems following the tutorials otherwise.

In this first tutorial we’ll look at how to set up your programming environment, as well as making our first code.

Note that you can easily find all the articles published in this series so far by using this link.

Continue reading »

When Simon and I discussed how to fully integrate the city creator, code named “Map Invoker”, the idea of it working like a Wizard surfaced. 

With a wizard like interface, each layer of objects (Waterways, Roads, Walls, etc.) would each be generated by a different page on the wizard.  A “generate” button would draw the objects directly in CC3.  If the results were not what the user wanted, the user could press the “generate” button again and the old objects would be removed and the new ones drawn.  Once the user liked the output, the “next” button would take the user to the next wizard page.

Now this sounded like a great design to me.  But …. I had some technical issues to overcome and some design work to make life a little easier.

The main technical issue was that the built-in dialog system was not made to ever run custom code and call XP functions while the dialog was still visible.  This was solved by using C# to write the Dialog code and communicating with CC3 via a simple callback class and a delegate.  I will go into this solution in depth in a later post.  Right now I want to go over the design work I did to make life easier passing data back and forth between C++ & C#.

Here is the diagram of my classes thus far.  They are simple value classes, with no behavior.  In a previous experiment, I created a REAL object (data & behavior) but because of the fact that a real class crosses native and managed code, it worked great in a all C++/cli environment, but I could not use it in C#.  So I decided to split data and behavior into two separate dlls.  The cc3objects.dll, a C# set of value classes and cc3actions.dll, the C++/cli dll that implements the behavior.

Now, what this does is let me create an entire object, or set of objects that can be directly converted to native CC3 objects.  So, I actually build my objects in C# then pass them to my C++/cli XP dll.  Plus, once I get done with this project everyone will be able to use these dlls.