Jump to content


  • Content Count

  • Joined

  • Last visited

About Enhex

  • Rank

Profile Fields

  • Website
  1. Wow so many social justice warriors here. It's just Postal 1 with updated graphics and a cheesy trailer monologue.
  2. Enhex

    Advice on flat art style?

    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.
  3. Enhex

    Advice on flat art style?

    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: 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:
  4. Enhex

    Advice on flat art style?

    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:
  5. Enhex

    Advice on flat art style?

    Spacescape will be perfect for this.
  6. Enhex

    Advice on flat art style?

    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?
  7. 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: (please try to ignore the lack of anti-aliasing for now) Anyone have suggestions about how to improve it? Perhaps make it more vivid?
  8. 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.
  9. 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. Yeah you could build such hierarchy using hierarchical prefab system.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  • Create New...