KRPG Editing

Mapping Guidelines

Dungeon map location guidelines

This goes for both new maps created from scratch as well as for existing maps being reworked for KRPG.

A dungeon that the player accesses from the travel map (the world) is at the location shown in the world. This means that if the player enters a dungeon in the middle of the desert (e.g. the Necros hub), the outdoor areas of the dungeon need to look it – there should be sand and very little if any vegetation around. This goes for all further outdoor areas of the map as well, not just right at the entrance.

As long as the player crosses to the next map of a dungeon hub through a door, tunnel or similar, i.e. the next dungeon map is obviously in the same world location, the same restrictions apply to all outdoor areas.

If the player crosses a magic portal to enter another dungeon map, the outdoor restrictions are lifted, since the magic portal could lead to a place nearby, a place at the other end of the continent or even to a place in another dimension.

There is one notable exception. If a dungeon map of a hub that the player reached through a magic portal has a normal entrance/exit connection to a world location, then this map’s outdoor areas need to conform to that location.

Theoretical example:

  • The first map of a hub is accessed from the desert on the world map. That means the outdoors areas of the first dungeon map need to be covered with yellow sand.
  • The second map of the hub is reached through a simple wooden door from the first map. That means the player is still in the same desert area, thus the outdoors areas are covered with yellow sand.
  • The third map of the hub is reached by a magic portal from the second map, so there are no restrictions.
  • The fourth map of the hub is reached through another magic portal from the first map, however it also exits into the forest far to the west. The outdoor areas of the fourth map have to look like the player is in the middle of a dense forest.

 

Dungeon map RPG complexity design guidelines

For the RPG setting „off“, the hub (or single map) should allow the player to quickly reach the exit/end boss/important area.

On the setting „simple“, there should be a few obstacles that force the player to explore more of the map/hub before.

On the setting „complex“, map flow should be designed in a way that the player is forced to explore all areas and kill most monsters to collect the keys or other items to unlock doors.

Example:

The map has a starting room from which three corridors lead to other areas of the map. Two of them lead to large further parts with many rooms and monsters. In these areas, three different keys are placed, one of them easily attainable, the rest between cascading closed doors around the map.

The third corridor leads to the final area of the map. On the setting „none“, this corridor is passable from the start. On the setting „simple“, there is a closed door in the middle, requiring the easy to attain key. On the setting „complex“, there is a different closed door in that corridor, requiring the fourth key that can only be attained by first getting the other three keys and unlocking doors.

 

Non-combat map design guidelines

Leave enough space in all areas where there will be a lot of NPCs, otherwise the player will have great difficulties getting through.

Since there are no monsters, there is no need for closed doors. As polyobject doors don’t work well together with 3D architecture, it’s best to forfeit animated doors in non-combat maps. Just create sectors for open doors at different angles.

Use visual tricks to make the settlements look much bigger than the actual accessible part.

 

Texture (and flat) naming guidelines

4 letters describe the type of texture, two digits give it a serial number, one letter designates a subvariation of the texture and one character is saved for special cases. Except for the 8th character, all other characters are obligatory.

Examples:

  • CITY02A is the 2nd city texture’s first (basic) variation.
  • CHUR03D is the 3rd church texture’s 4th variation.

For an example how this works: CITY13A is the basic wall texture using the big green stones. CITY13B is the same texture with a window on it. CITY13C is the same texture with a door on it. These correspond to the old ATOWN13, ATOWNW12 and ATOWND10 (or similar numbers, don’t remember exactly) textures, but now they are clearly delineated as variations of the same texture and are shown together in DB2’s texture browser.

Wall textures are using the serial numbers 01-70 and floors start at 71 (going up to 99), e.g. CITY13A would be a wall texture, CITY73A would be a floor.

 

Adding NPCs

(from an e-mail by Crimson Wizard)

There are two distinct “entitites”: a map thing, aka Actor, which uses sprites, walks and fights, and secondly a “person” – a conventional entity that defines the conversation (latter was added by me).

 

Adding a new thing

How to add new thing. There are two problems: register new class for the engine, and register new type in the DB.
Actor classes are registered by adding them to /koraxrpg/basepak.pk3/actors/ (also just /koraxrpg/actors/ – because engine checks both pk3 and subfolders). These text files are read at engine startup. Their format is called DECORATE, and is thoroughly explained in ZDoom wiki: http://zdoom.org/wiki/DECORATE

Let’s do a simple sample thing. Open /koraxrpg/basepak.pk3/actors/krpg/townfolk.txt and find this line:

 actor NPCTownFellow1 : NPCStrifePeasant 19003

This is an actor declaration. It makes a type “NPCTownFellow1” inherit all properties of base type NPCStrifePeasant (which defines all the animations). 19003 is map thing id.

Make a copy of the whole block of text:

 actor NPCTownFellow2 : NPCStrifePeasant 19010
 {
 ConversationID 4
 Scale 1.20
 }

Now you have NPCTownFellow2 thing of map Id = 19010 and with Conversation id = 4.

If you do not like to keep same sprites as for basic peasant, you shall replace them in a way similar to how it is done for NPCStrifePeasant. What you will see in its declaration is a classic state-machine: there is a number of actor states (names are quite self-explanatory) each having number of actions. See http://zdoom.org/wiki/Actor_states

For example:

 Spawn:
 PEAS A 10 A_Look2
 Loop

This runs when actor is spawned on map. “PEAS” is first 4 letters of sprite name, next follow sprite frame (“A”), third is frame’s delay (in 1/40 second IIRC). Finally it is an AI function to call (“A_Look2”). There are a lot of available AI functions, but that takes time to learn, so you may just copy these from existing actors and monsters.
If you want several frames to play in order with identical delay, you may write this:

 PEAS ABCDE 10 A_Look2

This way 5 frames (A to E) will play one after another. A_Look2 ai function will be called on EVERY frame. If you want it be called only on the first frame, split this sequence in two:

 PEAS A 10 A_Look2
 PEAS BCDE 10 A_Look2

“Loop” command means loop this state commands forever (actually – until state changes). “Goto” command means switch to another state.

If all you want is just use different sprite group, simply replace PEAS names with something else. For instance, replacing them with BISH will make new actor have Dark Bishop’s sprites.
Just be careful: the sprite set you are using should at least have all the same frames (BISHA.., BISHB.., etc), or the game will crash.

 

Registering a new thing

Registering your new thing in DoomBuilder2 is pretty simple. Find KRPG (or whatever you are modding) config: there should be several *.cfg files. I think KoraxRPG_Things.cfg is the right one. There’s a lot to use as example there.
DB2 allows to split all things in groups. Here’s how NPCs group looks like:

 npcs
 {
 color = 10;// Light Green
 arrow = 1;
 title = "NPCs";
 width = 16;
 sort = 1;
 19001 = "Ramb Orc";
 19002 = "The 4th Class";
 19003 = "Town Fellow 1";
 19004 = "Town Barbarian 1";
 19005 = "Town Cleric 1";
 19006 = "Town Mage 1";
 19007 = "Shop Attendant 1";
 }

Simply add your new actor as:

 19010 = "Town Fellow 2";

or whatever.

There are more things to customize in DB2, like adding a sprite to display in place of the marker on map, setting individual width, etc. IIRC the individual attributes just replace the group ones:

 19010
 {
 title = "Town Fellow 2";
 
 width = 20;
           sprite = "PEASA1";
 }

 

How to add a new conversation

Go to koraxrpg/data.pk3/ and find coninfo.txt. This is the base conversation script. I’d recommend not to put actual conversations there and use it only to import other files, like:

 import town1

this will use town1.txt for conversations.

There should be example of conversation I added for shopkeeper. It has this header:

 conitem NPCShoppeAttendant 100, ShoppeAttendantMain 0

First goes official “person” name and its Id. It is this Id that is assigned in the Actor’s declaration (ConversationID). Then goes conversation item script name and its related Id. You may have unlimited number of conv.items per person and switch between them in game by using SetActiveConItem(person_id, conitem_id) command in map script.

I think I uploaded number of conversation scripts to your file server once, but I will attach them to the mail just in case. They are working scripts from the Strife mod I was making back then using similar dialog system. I also attach a conversation script documentation.