This is not a tutorial, just some quick info for people already familiar with mapping from other games :)

Timerun Entities

In e.g. defrag you make a trigger_multiple and point it to a target_something (been a while, don’t quite remember..) but that’s the basics of it. You _can_ currently do that here too, but it will probably be removed, so stick to the following method:
1: Create a brush with the size and position where you want the start\checkpoint\stop like you would a trigger multiple, and apply the textures/common/trigger texture to it.
2: With only the new brush selected, right click in the grid somewhere and select create timerun start/checkpoint/stop.
That’s all.

Run teleport/kill triggers

There are no kill triggers in RIK, but there are teleport and respawn triggers, and a new type named “run abort”. The run abort trigger will stop your timerun and notify you about it. Then if you don’t load or respawn by your own free will, it will do it automatically for you. (after a player specified time, or you can disable it if you want)
For situations like in the below image, this is a far better solution as opposed to getting that annoying respawn or kill if you miss the next platform.
So, for the sitations where you have a fairly short fall WITH something you can actually walk on below, use trigger_run_abort and NOT the respawn or teleport triggers.

But if you have a larger fall, in particular if it ends on top of a skybox or something you shouldn’t really be able to walk/move on, then use the trigger_respawnplayer. It’s available in the right click menu as “Create respawn”. The only case where you should use actual teleporters is when moving the player from one place to another one. See below for an example usage of the respawn trigger.

Textures and shaders

Stick to the stock textures and shaders, at least for the time being. Any relevant changes or improvements to it, or additional colors\trims\etc should be added to the game files, not to a specific map :)

Heights and measurements

Note: the values here are recommended values, not absolute ones. But using values for e.g. jump height above this, might not continue to be supported, so try to stick to these numbers..
(all are in units)

  • Player width: 30
  • Comfortable jump height: 64
  • Max jump height: 80
  • Recommended stair step height: 16
  • Minimum stair step height: 8
  • Max stair step height: 32
  • “Doublejump box” recommended height: 64
  • Minimum crouch height: 64
  • Minimum walk height: 80

Tips / good practices / useful info:

  • If you’re making a styled wall (e.g. many brushes stacked on top of each other) and you want the player to be able to walljump off it, clip the entire thing with a textures/common/clip_wjok. The normal clip does not allow walljumps.
  • Overbounces and wallstrafe doesn’t exist and won’t exist in RIK. Any possible situations in the future where one might be able to cause either one will be “fixed” as well.
  • Map sources will be uploaded with maps (but not publicly downloadable), so any adjustments or fixes can easily be made to them in the future. Maps will be versioned automatically in the record system so you can actually see that it has been changed as well.
  • Refrain from any and all use of the “wait” key. I’m not sure it’s fully removed at the moment, but it can only cause potential problems.
  • Player spawns, don't bother placing them down to the ground and such, just leave them e.g. 64-128 units or so over the ground. The game traces down (for a certain amount) until it hits something and spawns the player there, not at the actual height of the entity.
  • Corners / edges, I haven’t yet been able to make a good fix for this, and hence corners of any walls should be made like in the left part of the image below, and NOT like the right one. This is to avoid buggy\bad behavior. Note that this will probably be fixed in the future, but isn’t a priority since you can easily map around it. Also, this particular corner would work somewhat ok, but any corners which have these “splits” on them can cause bad behaviour, so stay away from them.


I'll also send with some map sources to anyone who gets the alpha for mapping, so look at e.g. for a practical example.

Isn't that corner behavior backwards from how q3map2 works? :o
In regards to getting optimal tris, yeah, but not like that really matters performance-wise for a few corners, especially not nowadays. It's like this to some extent in q3\et\etc as well.. :)
To be more precise, this only applies to corners you'd want to "skim"/skip/whatever you call it.
Replaced it with a better example :)
What actually happens if you skim it or run into it?
Nah but really, most cases you'll be fine and it might just nudge you a little bit, but if you hit it at a specific angle it will stop you as if you ran into a wall. Pretty much like in other Q3 based engines, iirc it's like this in defrag too. (?)
This was really helpful dude. Some stuff i didnt know that ill put into my map :)