Discussion in 'Mapping Questions & Discussion' started by Arhurt, Aug 28, 2008.
Got the A point area of my payload map to a proper state! Orange blocks are currently placeholders for doors to different areas
Working on new car model.
Rough idea for a payload point I think would be fun to defend.
looks very similar to upward A
rough first draft of a neutral ctf map's midpoint, i plan on making the whole map's "flow" kind of a very vertically squished "v" shape
I've been slowly working on some more vehicle models
Emphasis on the word slowly
Another almost finished model!
Helltrain might be 3d this year>>>?????????
and not ctf
By golly he dun did it. exported map geometry and textures to blender. the mad lad
New version of helltrain almost done!
It's a new gamemode called "capture the points" >:]
mmmmmmm the shadow from that bridge
I and a friend have been writing a game engine from scratch (except openGL/SDL2) since late August and it's pretty cool. The architecture draws heavy inspiration from the Source engine, with simplification of all aspects to reduce the amount of bullshit (and the toll on our sanity).
The above picture is just it rendering a model of mine which is half a year old, but behind that model is a proper entity. The entity system utilizes C++ runtime polymorphism and a preprocessor trick to register entities automatically. Here, the entity "prop" derives from the base, specifies its own model and material, and renders them. The entities are read from the map file, which is a text file that specifies their key-value pairs. Some may be left out, and the entity implementation has the opportunity to set defaults.
Materials also have their suck stripped - they just specify which GLSL shaders they use, and then key-value pairs such as diffuse red.tga. The GLSL shader will then specify a uniform sampler2D map_diffuse and be able to use that sampler to access the pixels loaded from the texture red.tga. I'm super proud of this system.
Resources, e.g. textures, materials, shaders, and models, are cached by their name so the engine doesn't load the same thing twice if different things reference them.
Also, it obviously can't be shown with a screenshot, but all interaction with the engine is done via text commands, which are each mapped to their handlers. A handler gets the array of arguments and a flag for whether it was a press or release (no distiction between "usual commands" and "press/release commands" as in Source -- all of them can be pressed or released). Keys are bound to commands (yes, there's a command for that, and the engine runs the script at startup). Also, it's designed in such a way that when you're just pressing buttons in runtime, no text operation or copying goes on - the keys are mapped to the efficient representation.
Sorry for a barely related image and a wall of text, but again, I'm super proud of all of this, and wanted to share it. You can observe it on GitHub I guess, but we do treat that repo as a personal one, which it is. (I do with the master branch what my heart desires.) Also, it doesn't have the model or textures.
Going to have a play test next week-ish for ctp_helltrain! Its like a mixture of player destruction and ctf and deathmatch. Kills result in points for your team instantly, and the first team to 400 wins. The intel can steal points like on asteroid [up to 100] to make infiltration incorporated into deathmatch. The layout got cleaned up to make navigation easier but it will probably change some more.
A final part of level on my payload map, finally textured the whole thing. It remains only to make a background on the entire map, which is a ton of work, and to think through everything in more detail, rethink on some points.
Making some (slow) progress on this map.
What's up! It's been a month and I think we've got a working solution for visibility determination in our game engine. What you see here will remind most mappers of the contents of a portalfile, but it's hardly that: it's an octree, which subdivides more where there are many polygons, and less in emptier areas. It has a very simple and intuitive implementation, easy to get up and working. But I love the other spatial data structures I have been learning about, such as R-trees, and the usage of space-filling curves. You can get really clever if you want.
Anyway, this follows the philosophy that props are for things that are common and same, such as a street lamp or railing, and unique geometry should belong to the actual world. *But* the world geometry can and should be modelled just like the props are, with no additional limitations, and rendered in the same way - visually, you shouldn't be able to tell the difference, as you easily can in Source.
The map would define certain "occlusion planes". These resemble Source's world brushes in that they block visibility. But rather than serving as an input for a total precalculation, they are instead rendered into a depth buffer for the tree to test against (don't enter the branches whose cuboids are occluded entirely).
Spoiler: Bonus: a Blender view of that scene, shaded
So you can actually see what's going on in the scene. Yes, I acknowledge the fact that most things fall behind Hammer when it comes to actually making maps...
Also please warn me if you think the relevance is insufficient...
Haven't worked on a map since the semester started, so I wanted to do something small to get back into the flow. I decided to recreate one of the posts from the Architectural References thread.
Only been at it for an hour. Not very far yet, but I'm further along then I thought I'd be.
Separate names with a comma.