Wow so many social justice warriors here.
It's just Postal 1 with updated graphics and a cheesy trailer monologue.
Quote from blackdogWell neon bands will definitely have a gradient of some sort, that will help a little. Then you can inset neon bands a little in the geometry.
Instead of grids you can give a very light material texture, a grain, that might help?
I replaced the completely flat texture with one that has some grain. It doesn't help with the lights but it helps with tracking the ground while not creating tiling patterns on large surfaces, it just gets flat on far surfaces because of texture filtering.
Quote from KlemsDisplay MoreMaybe this can be of some use
External Content www.youtube.comContent embedded from external sources will not be displayed without your consent.Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.I had the same problem about sensing speed on a flat texture. The answer isn't hard though: don't use flat textures. Lighting and reflection can do wonder. Another solution is to add some grain to the texture, either in a shader or on the diffuse. You can also try changing the fov depending on the speed, or add a looping sound (whoosh like) and change the pitch/volume according to the speed.
About being able to see edges, you could add black/white outlines to the geometry, or make a shader which read the depth buffer and do something at the edges. The problem is that each surface is completely flat, so the eye doesn't catch the edges as there's no normal/light change. You should smooth the edges in the geometry, so you can either add lighting or a rimlight effect.
Use dithering if you have color banding issues.
Omnific was my first inspiration but because of the lights problem it didn't look good. Dithering will require modifying the game engine and that will require way too much time learning how to implement (could take over a month) and I'm not 100% sure it will even solve it or that other problems won't appear so it's too much risk. Grain to the texture could help but I don't believe it will be enough to make it look good. Source uses baked radiosity lights which again will take too much time and too much risk to pursue.
This is how the omnific expirement lights looks like:
[Blocked Image: http://i.imgur.com/YpBsBw5.jpg]
You can see the overlapping patterns and banding.
What I've seen on radiosity lighting is that it calculates it per square so you get an average light for that square, which gives less sharp edges for the light spheres and the light bouncing around also helps to level things. In source it also seems like there's some extra stuff done to deal with banding, I've seen shades of green and wave'ish patterns of what seems to be dithering on places that would normally have banding.
Keep in mind that so far this is a solo project and I don't have infinite resources, so in some cases I have to min-max things to get the game finished.
BTW here's the flat level with space skybox:
[Blocked Image: http://i.imgur.com/uKSrelQ.png]
The engine I use is Urho3D.
Reflections are a good suggestion, and I hope it will combine well with space skyboxes.
I started with grids and I think completely flat textures look better and more coherent, with the downside of speed perception problems. We need to keep in mind the world geometry isn't axes aligned so texture alignment could be a problem, especially with curved ramps which I'll want to have later on. Example:
[Blocked Image: http://i.imgur.com/4H1eSfY.png]
I did try to test using grid textures, but unlike portal I want to use more complex world geometry, in which case completely flat textures look more coherent, especially with the neon'ish stripes.
Using vertically aligned stripes is possible and I've been thinking about it. I don't like the idea that it will "segment" the ramp, but maybe a staggered horizontal line can be used like on the standing platform.
I also wonder what kind of skyboxes can be used with such style?
Hi guys,
I'm currently working on a surf game and I want to have simplistic and abstract art style.
I want to use flat textures but it turns out to be problematic in some aspects:
- Point/spot lights suffering from color banding, making them look awful.
- Sensing speed. There needs to be stuff for the brain to track in order to get a sense of speed.
Stuff in the background and on the ramps can help with that.
- It's hard to tell where edges are at.
I'm using outlining to make them visible.
This is what I have so far:
[Blocked Image: http://i.imgur.com/B7tMxZK.png]
(please try to ignore the lack of anti-aliasing for now)
Anyone have suggestions about how to improve it? Perhaps make it more vivid?
Quote from clankill3rBtw, I'm pretty sure you won't do it but why don't you hook up with Lajron?
Well Sledge Editor is an editor for the Source engine, thus it's using Valve's technology and it isn't generic. Under the hood the editors work differently.
Regarding your ideas:
1. Sure thing, that's a pretty standard feature. Tho I don't plan on having crashes.
2. That sounds like a problem that can be solved with prefabs.
3. Well that's a feature that is used to save on compile time when you want to test a sub-set of the level. The editor is generic thus things like compiling and skybox implementations are at the game-level, so the problems you mentioned aren't part of the editor. Adding such feature is possible and isn't hard but it's not a priority for me for now.
I do have a roadmap here with milestones and features.
Quote from clankill3rRequests
1. Yeah that's pretty much the idea with the scripting. (Tho your example can be done more easily with "shift-copy")
2. That's a prefab system, I have it planned.
3. The levels are saved in text format, so you can use it with git / mercurial to save the delta changes.
Quote from blackdogI would like to have some principles from HTML entities, be able to define bulding blocks and change the wall height for all the walls on a floor with two clicks and a console command.
Yeah you could build such hierarchy using hierarchical prefab system.
Quote from CastleNo, the fact that its a fully 3d interface with seamless play testing capability combined with a multiplayer workflow.
A 3D interface could be nice, tho it isn't too different from the 2D grids. It is very useful for an in-game editor in which you don't have a cursor to use grids with, or screen space for them (tho it's possible).
With a generic editor the game itself is outside of the scope - it's not an in-game editor. BUT a game can support live reloading of a level file, so it can be a game-level feature.
My initial thoughts about multi-user editing is that it's gimmicky and that users will anyway want to work on different areas to avoid stepping on each other's toes. Though using hierarchical instancing with real-time updating and letting each level designer have his own sub-section instance to work on you can achieve similar result in which multiple users can work on the same level at the same time.
Though the problem with it will be accessing objects from different sub-sections, which will be really limiting, and to solve that you'll need all the users to be working on the same file, like the original suggestion.
When it comes to new editing tools, I'm trying to think about problems to solve. One problem is repetitive tasks, having to repeat the same action many times. For example making a spiral staircase or a curve in a surf map - they require relative position and rotation to the last element. In that case a script can be used to do the repetitive tasks. e.g. take object X, clone it, move and rotate the clone by Y, repeat Z times. You can save the script and use it on any object. You can use it to make much more complex things and save a lot of time.
To come up with new tools we need new problems. Problems that start with "why can't I just..." and don't involve mind reading can be good.
Quote from CastleA generic editor is a tough pill to swallow when it comes time to start a serious project. First of all most public, non obscure, brush based editing tools are in a state of stagnation. The only generic brush based editor that arguably isn't in a state of stagnation would be Hammer. But even Hammer has some serious flaws when it comes to making life easier for next generation games.
The very first thing I would suggest before taking on a project like this would be to take a solid look at the next generation engines out there then think one step ahead of those. Specifically Crytek and UE4. Making another version of Hammer when Hammer itself is showing its age would be a mistake. If you want an example of taking that next step ahead of everyone else take a look at the Reflex editing tools. And if you want to really think ahead, take a good look at the implications that real time ray tracing will have on the development environment. Something like that will completely change the industry let alone our tools.
I've watched this video about Reflex, tho it seems to be in too early stage to learn things from it. Right now it doesn't have GUI and it's just memorizing shortcuts and commands.
My goal with the editor is making user created levels feasible. That means that the editor needs to be intuitive, easy, and fast to learn. The Hammer/Radiant geometry creation is the best method for these requirements that I know of, fast and simple, and I'm also a big fan of 2D grids for fast and accurate positioning.
On the other hand at least Hammer's GUI design is really bad. You have to open windows for the most basic tasks like selecting a texture or editing properties, not to mention selecting a model. It also uses a lot of dropdown menus which are annoying to use. For the GUI design I'm learning from Unity, which does it right and doesn't have all these problems. I also have few planned features which I haven't seen in other editors, so it will have more to offer.
Also it doesn't use brushes, Its shapes are more similar to meshes, but like brushes allow storing the material info for projection. That means you can create concave shapes if you want to, which means one less thing for the level designer to worry about.
Regarding advancements in technology, well, I can't imagine anything better than polygons to work with, so I can't do anything about it.
To conclude the editor is designed around making modding feasible to the players, providing better UI & user experience, and making it available to be used for any game.
Quote from EwokI think this is a fantastic idea; and something Unity sorely needs. I found modeling simple rooms and shapes in Blender a chore, especially when it comes to texturing. Sometimes I don't want to unwrap, and it'd be nice if I could just apply textures to a face like in Hammer, and be able to stretch geometry without the texture stretching with it.
Rather than having a custom level file format, wouldn't it be better for the program to output a model in a few common formats? That way, you've got a truely generic and cross-engine level editor basically from the get-go with no implementation necessary.
Either that, or you keep the custom level file format, and have an export function that can save the level in one of a handful common model formats.
Yeah, I felt the same need for Hammer'ish editor when I checked out Unity, and I do plan to officially support Unity on a later version of the editor.
Regarding the file format, it is required to store the materials info for projection, though it's possible to build the shapes and save them in any format you want (after projection). Entities still needs to be stored somewhere and using model formats would mean a level will require multiple files, so it makes things a bit more complex.
I think the best option is to make a level loading library that can convert the shapes to common formats to be loaded by any engine. This way you still have 1 file and you don't have to implement shape loading for every engine.
Added to the todo list.
Quote from NakromaLooks really good so far. For which engine are you creating a level for?
It's a generic editor which means it can be used for any engine or game. The only thing required is supporting the level file format, and providing config file for the editor.
The file format is a simple JSON (parsers available for any existing programming language) which contains shapes (static world geometry) and entities (the rest).
The config files tells the editor where to look for game assets which include materials, models, and entity config(s).
The entity config tells the editor about the properties of each entity so you can edit them inside the editor (things like lights, monsters, pickups, you know...).
I'm currently developing it and testing it with my own game engine, and later I'm considering to support popular engines such as Unity/UE. But again any engine can use it.
Heck, you can even use it for 2D games if you ignore one of the axes. It would be nice to see 2D games which have vector based worlds instead of grids.
Hi guys,
For the last several months I've been working on a generic level editor which I plan to use for future game projects.
It's inspired by Hammer(geometry creation) and Unity(GUI Layout) and designed to be even better in some aspects.
The two main goals are to make something that can be used for any game, and to have simple geometry tools to make user created content feasible.
Longer pitch available here.
Video: (feel free to skim it, it's making a level and playing it)
So I'm wondering what you guys think?
Maybe you could suggest things you always wanted to have or something? Workflow, features, etc.
For example I know of some cases which scripting can be useful to generate parts of the level (before it's saved so the generated stuff are part of the level file), which is something I haven't seen with the editors I got to use.
Also one of the saddest books I've read
I just take it as a bunch of important lessons.
The only book I ever read and finished out of my own free will:
[Blocked Image: http://upload.wikimedia.org/wikipedia/en/5/53/Masters_of_doom-Book_cover.jpg]
