So, yesterday, after days of doing practice exercises, watching tutorial vids and following along with them, I finally decided that I would start fleshing out the map I was imagining.
I started by drawing some very simple plans for the map, and flesh out a vague idea of what I wanted to do with it.
This is the extent of the progress I made on the map as of yesterday:
It's not much at the moment. I was mostly wrestling with the alternating altitudes and ramp sizes, and trying to solve the geometry, making it all touch without making any concave brushes (which are not allowed in Hammer)
For the most part I want to make a very, very rough version of the map, to get a general feel for the size and scale of the map before I go deeper into detailing, as it is my first actual attempt to make a hammer map for players to play on.
Thanks for taking the time to read! I'll be posting updates as I hit certain milestones in the map, so keep an eye out if you're interested in that.
I am noob. What are you planning on doing with this map?
From what I have read this is the map editor for SOURCE based games. The thing I saw showed Half Life. Which was based on the Quake engine.
The Quake engine maps were based on using Binary Space Partitioning (BSP). Hammer appears to use BSP also. Quake used the term BRUSH also as a 3D convex object. I seem to recall a brush was needed for the BSP to work correctly. This let the engine divide up all object faces as in front or behind a plane (face). Somehow you can then draw each face in front to back order which greatly sped up rendering in the old days, since most things would fail the Z buffer test and not be rendered fully.
It also looks like this editor is very similar to the RADIANT editor for Quake. Interested to see how close they are in operation.
I do not know what modern game engines use for space partitioning. Since GPUs are so fast, they may just draw everything and let the far plane clipping, MIP MAPS, and LOD do the work of speeding up a scene.
I believe the BSP was also used for object collision. Modern games again have way too many faces to attempt clipping. So there are usually invisible collision objects created that surround a very dense 3D object. Unreal engine uses this technique for example. Since Quake (Half Life) ran on slower PCs I have been tempted to make a ridiculous high poly Quake 3 map to see how good it can look on my fast PC.
I am noob. What are you planning on doing with this map?
The room that I've been uploading videos about will be copy-pasted in order to form the apartment block. After that I'll change the textures on the walls and try to make each apartment unique; adding props and other fine detailing work.
Overall, this apartment complex will be part of a "fishing village" taken over by the Combine. The map itself will be focused around the "fishing" gamemode.
I say gamemode, but it's written entirely using map logic, so realistically you could have a gamemode AND still fish. I guess it's more of a minigame at that point. Nobody knows who wrote the map logic for the fishing gamem, but me and a friend think they were japanese (due to the names of the entities; hari, sao, etc.)
From what I have read this is the map editor for SOURCE based games. The thing I saw showed Half Life. Which was based on the Quake engine.
Yep, yep. You bet.
The Quake engine maps were based on using Binary Space Partitioning (BSP). Hammer appears to use BSP also. Quake used the term BRUSH also as a 3D convex object. I seem to recall a brush was needed for the BSP to work correctly. This let the engine divide up all object faces as in front or behind a plane (face). Somehow you can then draw each face in front to back order which greatly sped up rendering in the old days, since most things would fail the Z buffer test and not be rendered fully.
In addition to this (or perhaps, instead of this? Not sure) Valve added VVIS (I think it stands for valve visibility engine or something). While you compile the map, it splits the world into "visleaves", the dimensions of which are determined by the contours of world brushes.
The application then determines which leaves can see each other (or may potentially see each other), and then this information is baked into the map. Leaves which can see each other or can possibly see each other are drawn. Anything else isn't. There are other ways to tweak visibility and object culling but that's how VIS works to the best of my knowledge.
I believe the BSP was also used for object collision. Modern games again have way too many faces to attempt clipping. So there are usually invisible collision objects created that surround a very dense 3D object.
For map geometry yes. However, physics objects do use simple collision boxes in Source. That's all I know about that.
Hammer was pretty fun way back when I messed with it, but I didn't stick with it because documentation was in the middle of being moved over and was really... really bad. Be cool to watch you progress on this. Looking forward to updates.
Relic Entertainment
cblanco ★ 
보드카 중대 
VonManteuffel 
Heartless Jäger 
