My struggles with engines
I should start off by stating that I don't have any direct question or point with this post; I hope I'm not violating the rules or rubbing against the standard. I've been struggling with this issue and I want to get these griefs out there. If anyone has feedback to offer, I would appreciate it, but I also understand if you don't.
I have this project buzzing around in my head. I want to get it made; I want something tangible that can actually run on a computer and be shared with friends.
This particular project is to create a late-90’s-style shooter. I want it to be low-poly, low-resolution textures without any smoothing, in a world built of simple shapes where the geometry is easy to read.
I also have plans for the game’s design and setting and gameplay and level flow and all of that, but they aren’t central to this discussion. What’s important here is the aesthetic of old-school late 90’s shooter.
While I have created a small number of
assets, I have done very little for this project because I keep
getting held down by one foundational aspect: the engine.
I debated about this a lot and did a
lot of experimenting, but here are the cliff notes of what has been
considered.
Building it in Unreal Engine 4 is out because I
cannot get the lighting dumbed-down enough to look right. I did a
bunch of experiments with the many options; it is simply too advanced
to pull of the aesthetic I am going for. Plus the BSP texture tools
don’t work, and that’s critical to a project like this.
I originally considered using a source port of Doom. Most of them are quite capable, easy to use, and can produce some reasonably good 3D environments. But there are certain limitations to world geometry.
I am very fond of using an old Unreal engine, making it as a mod of Unreal Tournament or UT2004. But I won’t be able to sell my final product because those aren’t open-source engines and Epic won’t license them.
This leads me to building my game as a total conversion of Quake 2.
This seems in most ways like my best option. It already has a complete single player experience that I don’t have to program, including enemy behavior, ability to go back and forth between levels, and custom keys. Nearly every last detail I want for my campaign could just be re-skinned Quake 2.
It also has multiplayer options
available, and even though it is not as robust as the multiplayer
form UT, it serves it purpose.
Heck, the game even operates with a
256 color palette. That pleases me, and I have enjoyed setting up
the palette for my game to use.
It seems like a perfect fit, but I keep
hitting problems that make me want to change my engine.
These all
stem from the fact that I have no prior experience making any kind of
mods to Quake games. I’ve done a lot with Unreal Tournament and a
fair amount with Doom, but editing Quake 2 is unfamiliar
territory.
To make matters worse, editing Quake 2 is not as
straight-forward as other games. There is no set standard of tools
to use, half of the tools out there don’t work on modern computers,
and most of the tutorials are either out-dated or on sites that don’t
exist.
I have yet to find a map editor that I actually enjoy using, (though I do have some that seem to be serviceable,) and every step I take I seem to face some issue I don’t know how to solve with few resources to get support.
These frequent frustrations keep leading me to question my choice of engine.
Yesterday I was thinking if I really
care whether or not I can publish my efforts. If I was working in
Unreal I could just start building levels <i>right now</i>.
I could start getting my ideas out <i>right now</i>.
And I want to start building levels.
I had contacted Epic about the
possibility of making something with an old Unreal Engine. They
stated that they are unwilling to license one of their old engines.
I suppose I could try to push them, but it doesn’t seem like
something that would prove fruitful.
Maybe if I was a proven
developer, but not me as I am.
Maybe if my project was nearly
finished and it looked good and professional, but even then it’s a
crapshoot if they might be willing.
So I keep dragging myself
back to Quake 2. I keep telling myself that this is the smartest
path, and I should hunker down and power through whatever problem I’m
facing. But for all the effort, and all the occasional advances I
make, I still haven’t been able to really start making levels. I
still haven’t made noticeable progress.
If I was building in
UT or UT2004, I could start now, and I’m confident I could create almost
everything I need without asking for help, and that I could get the
help I need when I do need it. With Quake, getting help is iffy, and
getting started has been slow going, and none of the editor I've tried seem to work that well.
But
of course, with Unreal I can’t publish my work. Also I can’t use
nearest-neighbor texture filtering. So what am I supposed to do but
just spend weeks on something that could have taken me a day.
Replies
My understanding of 1999 era game lighting was: it's dominated by the use of generic point lights (with or without cast shadows), with further lighting being handled by either manually painting it in via textures or vertex colors, or they baked the lighting with an offline render. Any shaders were absolutely kept to a minimum or didn't exist yet. There was also a lack of gouraud shading.
All of these are possible in UE4 if you strip back enough features. For example, for point lights you would have to disable any inverse square law and disable the automatic exposure (because 1999 games had not reached that technical stage yet barring any pre-baked content). There was also no self shadowing (that we see in games today), so it requires a more creative solution by either directly modifying the engine or creating your own material that's emissive enough so you wont notice it. To achieve flat shading would also require a material hack like this.
The last part may sound like cheating or not being 100% faithful to the original limitations, but unless you want to build a 1999 game engine by scratch, I personally wouldn't care how many restrictions you bypass to achieve a final look.
I played with the lighting for a few days, constantly looking for help on Epic's forums, but I never really got it close enough to be satisfied.
As I recall, one of the issues I faced was brightness. Lights in UE4 let you make a surface appear brighter than its default texel value. I found no way to get around that without restricting the brightness of the lights I was using, which was really tying my hands in the wrong way.
And then there's the issue of lighting all the dynamic actors. I couldn't find any options to get them to use cheap and inaccurate versions of vertex lighting.
Plus, the BSP texture alignment tools are broken, so even if I got the lighting right I still couldn't use that engine properly.
I think it is worth stating that my goal is not to create something that looks "bad" or "cheap," I want something that looks good, but is constrained to the limits of days of yore. I see a lot of people who think just having hard edges is enough to look like old-school 3D, or just having giant pixels makes a sprite look "8-bit." A lot of indie developers use the aesthetic of old-school graphics just as a means to put less effort into their art. Those old game were carefully crafted with a masterful style to create the best work they could have, creating art that took a lot of effort and skill just to look passable. A good portion of my desire to emulate those older games is because I've studied what they had to work within, and I am amazed at what they pulled off under those constraints. I want to stretch myself in like manner.
Unity by contrast is pretty blank slate and with this year's new scriptable render loops, they've exposed a hell of a lot of freedom in how you set up your renderer.
https://docs.google.com/document/d/1e2jkr_-v5iaZRuHdnMrSv978LuJKYZhsIYnrDkNAuvQ/edit
Gouraud shading is used with vertex-lighting. What "Gouraud shading" really is, is a way of interpolating values within a triangle.
Basically, to render a 3D triangle, the colours on its three vertices are calculated first (this is a mix of the lighting the vertices are receiving with user-painted vertex colours), and then all pixels that "fill" the triangle get a colour that is a weighted average of the colours of those three vertices, with the weights being the proximity of the pixel to the vertices.
Gouraud shading can be considered the default smooth-shading method in computer graphics since 1992, so it's definitely used in consoles (PSX, N64, PS2 etc.) and in desktop computers (since and including DirectX 2.0 and OpenGL 1.0).
--- edited for clarity.
As suggested above, focus all your time right now in making visual tests with Unity using a fixed-function shader since you're so fixed on having a "nostalgic" look.
https://docs.unity3d.com/Manual/ShaderTut1.html
It's exactly what was being used in those older games.
I guess it is a viable option, but as I think about it, it wouldn't be a very fun one.
There is no geometry editing for creating custom levels, so I'd have to build everything with pre-designed meshes.
And unless they've made some big changes to it, building materials is a huge pain.
Plus Unity has a bunch of hoops that I have to jump through if I want a larger game with several levels.
...But i already am familiar with scripting and the various quirks of the editor, so that's nice.
https://www.assetstore.unity3d.com/en/#!/content/3558
Basic version:
https://www.assetstore.unity3d.com/en/#!/content/11919
Progrids:
https://www.assetstore.unity3d.com/en/#!/content/4466
Bundle of those + bunch more:
https://www.assetstore.unity3d.com/en/#!/content/15447