さようならクリーミー、お見逃しなく！
This guide is not tailored for Hammer newbies, but here are a few guides for them.
A 15 minute video with a general rundown of Hammer fundamentals.
A playlist of Source SDK tutorials that go a little more in depth, including water creation, lighting, skyboxes, and more. Does focus around a newer version of Source SDK, but most still applies to our version of Source.
A wiki dedicated to documenting virtually every entity and fundamental in the SDK. By default, you will also be taken here if you press F1 while in Hammer.
In case you encounter an error when compiling (and you will!), paste your compile log in here and you will be told what borked and what you can do to fix it.
A bunch of decompiles of vanilla NEOTOKYO maps. You can load these into Hammer to learn how maps work, or create your own version of a map.
Recently released method to get Hammer++ working on NEOTOKYO. Hammer++ is a superior version to standard Hammer, with numerous QOL improvements which can save you a LOT of time.
It is strongly recommended that you get a few hours under your belt so you understand Neotokyo's gameplay, and the layouts of some of the more popular maps. Generally, Neotokyo follows the standard 3 lane layout. Teams will spawn in or on the opposite team's capture zone, with the Ghost spawning in various locations around the map.
On Studying Maps
NEOTOKYO maps have different varieties of layout and style. Some are short and compact, others are large and sprawling. You should take note of how things are laid out and placed in different map styles, like how Oilstain has a large meeting point in the center, or how Turmuk has a lower tarmac to avoid sniper fire from the upper tarmac.
Before even opening Hammer, you should first start by drafting a layout on paper before creating a greybox of your level. When drafting the layout, keep things simple and stick to just the three lanes you need to create. Don't bother with super complex flank routes or an impressive vent maze yet, you should only be concerned about adding these complex features when the map may call for it down the line.
A standard NEOTOKYO layout is a three-lane map with varying degrees of verticality. Areas of conflict should take place at least halfway through each of these lanes, with options to rotate into different lanes readily available.
On Sightlines
Due to the nature of NEOTOKYO's gunplay, you should make sure that you don't have any unnecessarily long sightlines within your map. Random spread can be annoying at long ranges, and if your map is completely wide open (Think nt_isolation_ctg) then your map may simply become a race for an SRS, which you do not want.
On Ghost Placement
Ghosts will spawn at specified locations at random. Each position should have some thought put behind them. I.e., the ghost in Server Room on Rise is placed in a commonly contested hotspot, the winning team of these shootouts can come out on top with the ghost. As far as anyone knows there is no known limit to how many ghost spawn points there can be, but most maps typically have 5-7 ghost spawns. Avoid placing ghosts right next to capture zones, as teams should be given a chance to contest their capture.
The info_player_start entity acts as the 'start camera', what you see before reaching the team select menu.
Each spawn should have a minimum of 16 spawn points per team. info_player_attacker is the spawn point for Jinrai, info_player_defender is the spawn point for NSF. Ingame, these spawns will swap each round, so by round 2 Jinrai will spawn on the NSF side, etc. It is ideal to space the spawn points for each team apart, otherwise you may end up with a player being spawned in the info_player_start instead.
The direction the mannequins face will also dictate which way players will face upon spawning. The direction should face toward a point of interest, such as a lane to travel through. Avoid facing players up against walls if possible.
Greyboxing is when you create the core basis of your map using simple dev textures (Greybox gets it name from how most engines have a default 'grey' texture color)
First, you need to ensure that leaks cannot be created in your level. Personally, I use the Cordon tool to create the skybox for me, so I can easily adjust as I go along and easily enable and disable it in the future. After your first few Alphas, however, you should implement a form fitting skybox, as a skybox cube is not performance friendly.
Stick to a larger grid size when blocking out your map. Values above 16 are optimal, but 32 is recommended for brushes which are intended to break up different areas of the map.
Avoid detailing, unless if absolutely necessary for the purpose of telling rooms apart or for cover/concealment purposes. If you throw down a lot of props early on and find that the room needs to be completely redesigned, you will have to erase a lot of your work.
Avoiding Fullbright
You will need to create lights in your level, otherwise the engine will automatically enable mat_fullbright 1 ingame, and make it difficult for you and your players to judge depth and distance. For your first alpha version, you can get away with simple lighting by placing default light entities around your map, and using an env_light entity to brighten up exterior environments. In later versions, you will have to move these around and illuminate your map properly.
To enable the CTG Gamemode, you must place a neo_game_config entity, access its properties and enable the CTG gamemode in the Game Type keyvalue. Not doing so will default the map to Team Deathmatch, which for some maps may be favorable. The only gamemodes which currently work in NEOTOKYO are Team Deathmatch (TDM) and Capture The Ghost (CTG). Any attempts to use other gamemodes will lead to dissapointment.
Next you need to place the capture zones, which are entities called neo_ghost_retrieval_point. You will have to adjust which team "owns" the point by attacker or defender. When it comes to attacker/defender spawns, you should assign these opposite to their spawn zone, i.e. the capture zone in the attacker spawn should be owned by the defender team, and vice versa. You can adjust the radius for the capture zones by dragging the drag points on the circle in the 2D view, or manually entering a value in the retrieval point's properties menu. These should be a tad larger than you think you may need them. Most NEOTOKYO maps use this style of capture zone placement, but it is not a bad thing to be creative with it! You can always adjust these spawns in later versions.
Finally, you need to place locations where the Ghost can spawn. This is done with the aptly named entity neo_ghostspawnpoint. As mentioned earlier, there's no known limit to how many of these can be placed (Do ring us if you find out!) but most maps use roughly 5-7 different ghost spawns, depending on the map size. These are really a "set it and forget it" entity, no configuration is needed (or available) for this entity. Do note however that the ghost model is not indicative of where it will actually spawn ingame; it seems to vary inside the yellow cube.
You will never get things right the first time, your A1 will take up many compiles before things work correctly. For every compile you run for the purpose of testing things out, you should run it in Fast/Fast to reduce the time spent waiting for your compiles to finish. Some things like lighting, prop placements, route adjustments and other in-depth aspects of your map will need to be handled internally, as they may not warrant a full on playtest by the community. Some things, however, like a completely new version of a map, will require such a playtest.
When testing for optimization, visibility and framerate, you should instead run it on Normal/Normal so VVIS does everything necessary to optimize the map as opposed to Fast/Fast.
However, this does not mean you can't test if things are working properly by yourself. For example, you should test to make sure that you set up the CTG entities correctly before publishing a map. Enter the console window and enter sv_cheats 1. This will enable cheat protected commands. Here's an incomplete list of some commonly used commands and what they may be used for:
Commonly used debug commands
sv_cheats 1 :: Enables the cheat commands add_bot :: Spawns a bot. Pretty dumb and useless on their own, but they will kick off the player requirements needed to start CTG, which will allow you to test your CTG entities. mat_wireframe 1-3 :: Adds wireframing to materials and draws them through walls. Useful to debug map optimization, i.e. ensuring that a part of the map isn't rendering when you are a considerable distance away from it. give weapon_x :: Spawns a weapon of your choice. Useful to test penetrations on walls or test nade bounces. noclip :: Allows you to fly through walls.
When you are finished with the minimum viable product of your map, where the
You may be ready to publish the A1! You may need to do the legwork to organize a playtest of the Alpha, by messaging server owners and asking a group of players (Usually PUG players) to try a playtest of your map. It's not recommended to ask to push an Alpha 1 to pub servers, though owners may do it you will get a lot of angry complaints about the map having dev textures and very little actual feedback, if it hasn't already been RTV'd to Rise.
When playtesting, you should try to play the map in the way you have intended, to see if it actually fit the vision you had for it. This will either show your playtesters how the map flow works, or show you how off you thought the timing on some routes were. Make note of these concerns, as well as any criticisms/critiques your playtesters have about the map. Use these and apply them to the next version of the map, your Alpha version 2.
Naming Conventions
Each map should meet a standard naming convention, which goes like nt_mapname_gamemode_versionx. The initials of NEOTOKYO, followed by the mapname, followed by the gamemode, then the version number. If a map is finished, the version number is removed, and this considers the map "final". This makes it easier for admins to switch to your map, as it is more common for the version number to appear at the end of the mapname. The version should have the initial of the version type, followed by the number. For example, nt_mymap_ctg_a3 is clear and understandable that this is the Alpha version 3 of the map MyMap. Betas are marked with B, and Release Candidates are marked with RC.
Playtesting in Pubs
When your map is well into its later Alpha/Beta stages, you may feel inclined to allow the community at large play it rather than keep it locked behind PUGs. You should not feel ashamed or selfish for this, full stop, you're providing something new and fresh for the community and you should not feel bad about it, and you deserve to play on something you spent countless nights perfecting.
That said, in its current state Pubs are not entirely friendly to the concept of new maps. Quite often will there be players who vote to swap the map to a vanilla map like Rise or Oilstain, basically robbing you out of your enjoyment, your time and your energy because they spotted a dev texture on the floor somewhere. Please feel free to report these instances to the BonAHNSa staff if and when this occurs.
Other than that, you will also receive rather nasty comments about your map, and unfortunately you will have to determine for yourself if these comments are helpful or offer nothing of value (The latter quite often being the case). At the end of the day however, this is your map, not the communities’, and you get to decide what you want to make out of it. Ignore nitpicky comments, complaints about map style/aesthetic, and never people please just to hear some positive feedback for something you didn't want in the first place.
Each version should have substantial changes made compared to previous versions, whether it is routing changes, detailing, and of course a healthy dose of bugfixing. It also tells how far along a map is in its development cycle, an Alpha 6 is further along in development than an Alpha 3. However, it helps to tell the players/playtesters if something is planned to be final or not. An Alpha [Initialed by A] tells players that things in the map are still subject to change, such as layouts, routing, or other features. Beta [initialed by B] maps are mostly set in stone versions which may mostly focus on detailing or polishing the map. Release Candidates [initialed by RC] are one of a few final releases for a map, which may solely just focus on squishing a last few bugs or issues leftover from Beta that may exist.
Even though NEOTOKYO is a Sourcemod, there are a few things from the 2006 version of Source that are either broken, unimplemented, or entirely missing from it when used ingame. Here's several things which may not work if you try to implement them:
You may have created a neat little prop you want to plaster around your map, or you downloaded a prefab to navigate around a certain issue. But when you click to spawn the prefab, it doesn't do anything. For some reason prefabs will spawn with a wild offset and may make it look like it failed to spawn altogether. Fortunately when a prefab is spawned it is automatically selected. Simply hit CTRL+X to 'Cut' it out of the game world, and press CTRL+V to paste it back in. You'll eventually work this into muscle memory.
If your map has a spawn (or both spawns) which includes a moving element like an elevator, you may run into the fact that spawn points cannot be parented to the elevator. However, there is a pretty simple workaround for this problem.
By using trigger teleport and teleport destination entities, you can have players spawn inside the teleport brush and have them teleport into a spawn location. Since info_teleport_destination entities can be parented, all one has to do is parent the destination to a moving platform, or leave it as is to prevent players spawning in the info_player_start in crowded servers/environments.
You may download a simple prefab of this setup HERE
If you play enough NT, you will eventually come across a situation where some goober decides to throw the ghost off the ledge to make it unplayable for everyone, or the ghost ends up in a location where it is virtually unreachable. You may also find that there's no stock brush or entity to prevent the ghost falling off these ledges. You could just place invisible brushes around these areas, but invisible brushes will block everything, including players and bullets. So, what's one to do about this?
The answer is pretty simple but it took ages to discover. Since the Ghost is a VPhysics Object, the func_clip_vphysics brush entity will only collide with VPhysics objects. Since the player and thrown grenades are not VPhysics objects, they will not be blocked by this brush.
The Ghost is a VPhysics object, but so are all the other weapons in the game. Maybe you want only the ghost to collide with this brush, so you can laugh as some guy drops his SRS over the ledge. This is pretty simple too. By using a filter_activator_class, you can specify what VPhysics objects will interact with this brush. In the filter settings, have it "allow" any entities with the name "weapon_ghost". Now have every func_clip_vphysics entity use this filter. Now you have a perfectly functional ghost clip brush. Do note that this won't stop someone from just carrying the ghost off the ledge. Unfortunately we're still trying to find an entity to fix dumbasses.
You may download a simple prefab of this setup HERE