Google+ Followers

Friday, 8 August 2014

Basic Isometric Maptool.

It took me some times, but here it is. If you have a look at the right column of the blog, you'll see that I have added three pages to the blog.
Those pages are detailed, step by step, explanations on
-how to add isometric movement to your own framework
-how to make basic isometric tokens
-how to turn any map into an isometric one, using Photoshop or GIMP.

Some of those explanations had been given on earlier posts, but those here are easy to follow without any knowledge about Maptool frameworks or Photoshop or GIMP.

Sunday, 6 October 2013

Isometric Maptool

A recent posts exchanges on Maptool forum reminded me of an old idea about using Maptool using isometric maps and figures. So, I decided to try it, to see how difficult it would be. To my surprise, it was very easy, much more than I anticipated.

The first step for me, was to make an isometric tilable background, to be able to draw maps on it, for gaming situations without full maps. Having to choose a square size, I decided to go with 150 pixels across and 86 in height.

Here is the background (the markings at the midpoint of faces are there to help drawing):

Just use it as background when making a new map and you can already draw isometric maps.


Next step, was to see how difficult to turn a squared map into an isometric one of the same proportions as the background above. Really easy. You can turn any square map in an isometric one in two minutes flat. You just need a program like Photoshop or GIMP and do the following:

- Step 1: Open your map and count the numbers of squares in size. Add the height (in squares) to the width (in squares); divide by two and remember the result for later.
Here, we have (10+7)/2=8.5

- Step 2: pivot the map 45° 


- Step 3: resize. Take the number found in step 1, above. Multiply it by 150 for the width in pixels, multiply it by 86 for the height in pixels.


And... It is done. But now, we need the figures to play on it. We'll need four views of each figure, one for each direction.

Making basic figures, like standing tiles that are used in some games (I think with Pathfinder), is as easy as making them in Tokentool. Just add those four new frames to the program and drag an illustration into it (once for each view). The result can be seen here:

It is possible to make better looking figures, like cardboard standups (using cardboard standups as a base), but it requires some work in Photoshop. I'll have to make a separate tutorial about it if there is any interest. Anyway, here is how those figures look like:

There still a better solution that I intend to explore, which would be to draw directly the views in an isometric perspective, but it would need four drawings for each figures and it looks a little like overkill for a style of gaming that is not very widespread.

Now, the last thing to do is to use all this stuff in Maptool. And, that also, proved amazingly easy.

First, as there is no isometric grid available in Maptool, you need to disable the grid view and the snapping.

Secondly, we'll need a new stat, called Table that should be added in the properties.

Now, for each figure, we must make a table. The table name shall be used as the value of the Table stat we added above. You must add the four views of the figure in the table and the value in the first colums should be 1 for the view going up-left, 2 for down-left, 3 for up-right and 4 for down-right.

There are a group of macros to add, to move and turn the figures.
The eight first buttons move the figures and the four last ones change the orientation.

There is still a problem to overcome. When a figure is moved, it must be placed above or under other figures, depending on where they are on the map. There is a line in the macros that take care of that when moving the figure with the buttons. To have the same effect when dragging a figure, there is a lib:token that must be added (this command is not mine, I found it in a post by aliasmask on the Maptool forum, so, thanks aliasmask).

You'll find all of this and a few stuff to experiment in the campaign file here.

There are still two questions that I would like to ask:
Is anyone interested in this style of gaming? I can see myself making maps and figures for peoples to use in their games. But probably not if there is not much interest. For my own use, it shall be used only in very prepared games. I am mostly trying those days to reduce the amount of preparation needed before play, and it takes myself in a very different direction (but that's for another post).

Is there any chance to have Maptool next version supporting an isometric grid. This system works without problem, but being able to use snapping would be fine.

Anyway, let me know what you think, here or on the Maptool forum.


Sunday, 11 August 2013

3D Traveller style planets maps for space opera games with Hexographer and Sketchup

For me, one of the most enjoyable parts of mastering a space opera game, has always been the mapping part. I have always loved the idea of making the planetary maps on the icosahedron projection that was used in RPGs since Traveller. Like that one:

(this map comes from the Hexographer free map generator, read further)

Whilst I make with great care the maps that are required for the scenario, I have always needed more maps than those. Indeed, the players are bent to wander around and, after all, one of the attraction of space opera is the possibility to travel around in an almost limitless setting.

So, I also need to be able to populate parts of the setting that are not vital for the scenario. It is quite easy as far as stats are concerned (all rulesets have generation systems for sectors, stars and planets), but it can be very time consuming if you want to map all those planets, or even some of them.

That's where Hexographer comes in. It is a simple mapping program that lets you make normal maps. And, if you have never heard about it, you should have a look, it can make your life as a GM much easier.

But it also has a setting for icosahedral maps. And what is even more interesting, it can also generate maps from a few chpices (hydrography, mountain ranges,...) which are the kind of informations that your game system and scenario has normally provided. And then it lets you customize the generated result.

But it is even better: there is a free version here that is limited to planetary maps. It should be enough for what we are speaking about here, though I would advise you to buy the full version, it is not expensive and you won't regret it: it will give you access to other mapping functions, styles,...

Anyway, download it, open it and generate a few maps, it is fun and even addictive.

But, why stop there? Why not present those maps in a 3D way? Like this one:

This is simply the map shown above turned into a 3D view.

First, you'll need Sketchup to change the flat map into a 3D model. You can download it Here.

You'll also need the empty 3D model planet. It is a Sketchup skp file with empty faces, and you can download it Here.

Now, generate a map with Hexographer, we are going to turn it into a 3D planet.

Open the empty Sketchup planet file with Sketchup, it should look like this:


Click on the A1 Tab. Click once on the face that is in front of you to select it. Then, Right-click>Texture>Modify Image Texture.

The face A1 that you were facing should open itself in the graphic program that is associated with Sketchup (if no graphic program is associated with Sketchup, go to Preferences>Applications and choose one, something like Photoshop or GIMP would be perfect).

Now, open the map of the planet you generated with Hexographer and select the part corresponding to the A1 face, paste and resize it. Flatten the layers and save.
The new image should now be visible in Sketchup on the 3D map. And as there are twenty faces, yes, you'll have to do it twenty times (from A1 to C5).

To make it easier to select the part of the map associated with a face, here is a little sketch of them:


When you are finished, just save your Sketchup model.
You, of course,  can re-open it any time and make any  changes you want, using Sketchup.

But if you prefer that your players, whilst being able to see and manipulate the 3D map, are unable to make changes, let them open it using Sketchup Viewer, available Here.

Have fun.


Friday, 3 May 2013

Le framework maptool approximatif, instantané, quasi universel, sans encodage, pour le jeu sur table


Maptool peut être utilisé tel quel, comme un simple tableau blanc sur lequel il est possible de déplacer quelques pions.

Cependant, afin de faciliter le travail du maitre du jeu, il est possible d'automatiser certaines choses ; et, c'est à cet effet que j'ai créé quelques frameworks (le terme de Maptool pour un ensemble de propriétés et de macros) destinés à m'aider à maitriser l'un ou l'autre jeu (par exemple, ici ou ici).
Mais ils se sont révélés bien trop lourds pour la façon dont je conçois le jeu.
Utiliser un programme de table de jeu virtuelle est, pour moi, essentiellement une façon d'alléger la préparation et l'organisation des séances de jeu. Et, bien que plutôt simple par rapport aux standards de frameworks de Maptool, je me suis aperçu qu'ils encombraient mon usage du programme.

En effet, j'utilise Maptool exclusivement pour des jeux sur table traditionnels, avec des joueurs en chair et en os, et pas du tout pour jouer en ligne. J'utilise Maptool, à la fois pour illustrer les actions pour mes joueurs et pour enregistrer facilement des données de jeu. Vous trouverez ici une description complète de la façon dont je m'organise, mais, pour simplifier, il s'agit simplement d'un ordinateur avec un second écran qui y est attaché pour les joueurs.

J'ai rapidement réalisé que je n'avais pas besoin d'un outil pour gérer les personnages ou les PNJs. Puisque nous sommes tous rassemblés avec des fiches de personnages classiques, et que je dispose de mon scénario contenant toutes les données dont j'ai besoin.
Je n'ai donc aucun besoin d'introduire les données du jeu au préalable dans le programme.
Et, puisque le framework est utilisé par le maitre du jeu (moi-même), il n'y a pas de nécessité pour le programme d'effectuer un contrôle ou une validation des actions. Les règles n'ont pas à être introduites dans le framework, je les connais.

Un de mes objectifs principaux a donc été de me débarasser de la nécessité d'introduire les caractéristiques avant le jeu.
Si je disposais de cartes et de pions, je voulais pouvoir simplement charger le framework et commencer à jouer directement avec la plupart des jeux que j'utilise.

Ma conclusion fut que, contrairement à mes frameworks précédents, je devais me contenter d'enregistrer les points perdus ou dépensés (points de vie, points de pouvoir, destin,...) au lieu de les soustraire d'un maximum introduit au préalable.
De plus, je devais me débarasser de toutes les automatisations pour calculer les niveaux d'effets ou les effets spéciaux lorsqu'un certain nombre de points sont perdus. Je devais le faire comme je le faisais de toute façon : en lisant mes notes.

Si vous êtes comme la plupart des joueurs, vous testez probablement régulièrement de nouveaux jeux ou en dépoussiérez quelques anciens de temps en temps. Réaliser un nouveau framework à chaque fois (ou en adapter un) est trop de travail pour une séance de test ou un scénario isolé.
Aussi, j'ai décidé de réaliser mon framework autour de caractéristiques « génériques », dans l'espoir que je pourrais l'utiliser avec la plupart des jeux que je pourrais être amené à utiliser.
Je n'avais donc besoin que de quelques compteurs pour les caractéristiques variables (celles qui changent durant le jeu), celles qui apparaissent dans la plupart des jeux, afin de n'enregistrer que les points dépensés ou récupérés.
Ce qui effectivement retire la nécessité d'introduire des maximums avant le jeu.

Ce framework s'est révélé capable de fonctionner avec la plupart des jeux que j'ai utilisés. Je suppose donc qu'il devrait être utilisable avec peu de modifications pour la plupart des jeux, ou même, qu'il pourrait servir de base à un framework plus développé.
Il devrait être possible d'ajouter une macro ou deux pour des besoins spéciaux (je le fais pour mon framework Flashing Blades qui nécessite une possibilité d'enregistrer les manœuvres d'escrime que choisissent les NPCs). Ou, il serait possible de retirer les macros qui ne sont pas nécessaires pour le jeu en question (par exemple les localisations des blessures pour un jeu qui ne les utilise pas).

Le framework qui résulte de ces cogitations est très léger et même simpliste, il ne fait pas grand chose, mais il ne demande rien en temps de préparation et il fonctionne, plus ou moins, avec chaque jeu avec lequel je l'ai essayé. C'était ce que je recherchais.

Comme framework Maptool, celui-ci n'est pas impressionnant, il n'est pas original, mais il est utilisable directement dans mes jeux sans travail préalable, et, pour moi, c'est la priorité.

Et, ici, se trouve le pdf expliquant comment l'utiliser. Le framework est très simple, aussi, les explications ont été rédigées dans l'idée que le lecteur a peu de connaissance de Maptool. Si vous avez une expérience du programme, vous n'avez sans doute pas besoin de le lire.



Sunday, 28 April 2013

The (almost) universal, face to face, no input, Maptool framework.


Maptool can be used "out of the box", as a simple whiteboard upon which you can move your game tokens.
But, if you want to make your work as a gamemaster easier, you can automate a lot of things, and, therefore, I developped  a few frameworks, intended to help me (see here or here, for exemple).
But they proved to be much too cumbersome for the way I play.
Using a virtual tabletop is, for me, a way to simplify my preparation and organization of the game sessions, and , whilst quite simple by Maptool frameworks standards, I found that they were still getting too much in the way for my use of Maptool.

Indeed, I use Maptool exclusively to play face to face games, with real players, and not to play online. I use Maptool as a display for my players and to record easily gaming stuff. You'll find a compleat explanation about the setup I use here, but, basically, it is simply a computer with a second screen attached to it.
I quickly realised that I don't need a tool for managing the characters or the NPCs. As we are all gathered with classic character sheets, and I have my scenario containing all the values I need. So, there was no need to record those values in the program beforehand.
The framework is used by the gamemaster (me), so, there is no need for control or validation from the program. Rules don't need to be set in the framework, I know them.

My main objective was to get rid of the need to input values before playing. If the maps and the tokens were present, I wanted to be able to open the framework and begin to play with most games I am using.
The conclusion, was that, in opposition with my earlier frameworks, I was going to record spent points (hit points loss, power spent,...) instead of substracting them from a maximum that I had to input before the session. And, I was to get rid of any automation for calculating levels or special effects when those points were lost. I was going to do it as I do it anyway: by checking my notes.

If you are like me, you probably dust off old games from time to time, or try new ones. Making a new framework each time, or even adapting an old one is too much work for one-off or trial sessions.
So, I decided to make the framework around « generic » stats, in the hope that I would be able to use it with most games I could decide to try.

I decided to just have a few counters for the stats that appear in most games and only record spent or recovered points. That did take away the chore of inputting any maximum (or even any stat) before gaming.

This framework is pre-ready to play with most games I have been using, so, I suppose it should be usable with very few modifications for most games, or even, as a base for a more full-fledged framework.
Maybe you could add one macro or two for very special needs (I am doing it for my Flashing Blades framework that needs a way to record combat maneuvers from the characters). Or you could remove the macros that have no use for your game (the locations of wounds, for exemple, if your game does not use it).

The resulting framework is really lightweight and simplistic, it doesn't do much, but it doesn't take any preparation time and it works, more or less, with every game I have tried upon it. That's what I wanted.

As Maptool frameworks goes, this one is not much to look at, it is not original at all, but it is usable directly in my games without any preliminary work, and for me, that was the priority.

So, here is the Almost Universal Face to Face No Input Maptool Framework for even Game masters that have no Maptool experience.

And here is the PDF explaining how to use it. The framework is a very simple one, so, the explanations have been made with the idea that the reader has almost no knowledge of Maptool. If you have any level of experience with Maptool, you don't really need to read it.

You'll find very useful information for modifying it to your taste (changing the stats names or macros, for exemple), here (read Introduction to Tokens, Introduction to properties and Introduction to Macro Writing and you'll know as much as I do).

If you are an experienced Maptool user, you can safely disregard the framework and the pdf, but I hope it shall prove useful for non power users like me.