An Open Word

There’s trouble ahead.

Isn’t there always? Any creative effort has to struggle with obstacles. But there is no doubt that the one Scout’s Journey has to deal with now is an especially depressing one.

The game might have to switch engine. Mid production. Awesome.

In a recent talk with FTE’s author it was implied that I shouldn’t count on SJ-related bugfixes nor tech support. I have been encouraged to fork the engine and fix them myself.

I have come to the conclusion that this idea is illusionary. I don’t understand the innards of a Quake engine, and especially not those of FTE. I could probably learn it, but that would take so much time and effort that it’s unrealistic. I cannot realistically fix the bugs in FTE nor do tech support once the game releases. FTE is basically a black box to me. Without support, a black box’s only use is as a paperweight.

And there are bugs in FTE. Some have gone unfixed for well over a year. Physics and realtime shadows are far from production ready; these things are currently novelty features, I would say. There are also PVS-related bugs that require knowledge I definitely don’t have.

I don’t know where to find a programmer who can fix a Quake-based engine. It’s specialist work. Not that I could afford it anyway.

The sad thing is that I like FTE. But it’s clearly not suited to do a modern first-person RPG in; its additional features such as realtime lighting were probably always intended to use with Quake and Quake-like games and developed with a Quake-modding mindset. For what I want to do, that mindset won’t cut it.

This same problem also affects the Darkplaces engine. Its features do not extend past the Quake-modding scenario and it’s not actively developed by its original author anymore. So that’s not a solution either.

Another sad thing is that John Carmack’s GPL engine dream is probably dead. Almost no one used the GPL Quake engines to make new, original games with. There are more games that used the commercial idtech license than open source idtech ones. A major issue is that the advanced GPL Quake engines are under-documented and relatively arcane. Perpetual bugs and lack of tech support are another. Considering Unity and UDK are *free* to make a game with, well-tested and supported by well motivated teams, there is little reason to not simply use one of those. UE4 is 20 bucks a month plus five percent of the sales. And for a rock solid game engine with tech support and documentation, five percent is nothing.

Where to go from here?

First of all, Scout’s Journey isn’t going to die. It’s too far along to quit, and frankly it’s also too good to quit. This is just another obstacle and it’s not insurmountable. I will have to port a certain amount of code – all the RPG things are basically done – which is a minor nuisance but much better than being left in the cold with obscure engine bugs. The assets are all portable – luckily I already switched away from BSP half a year ago. Sixth sense, probably. Polygons are polygons, art assets are art assets, sound files are sound files and writing is writing, no engine required.

Second, the options are, in the end, Unity or UE4. I pondered finishing a prototype on FTE, which is feasible, but admittedly the entire situation depresses me so much that I can’t stand it. The less time spent looking at a trainwreck, the better. It’s just super depressing and that has to stop.

Third, this probably marks my exit from the active Quake modding scene. The engine was the last link. Scout’s Journey was still using the Quake engine because it organically developed from the unlucky foster child that was the Remake Quake project. I will continue to play and pass on knowledge and I’ll remain with the quakeone.com staff for as long as they want me, though.

Now for the positive things.

Getting rid of Quake might also be liberating. To be honest, every time you talk about game development with someone from the Quake community, they AUTOMATICALLY assume you are making a shooter game. I can’t count the number of times I’ve been asked “when can I shoot stuff in your game?” and the number of times I’ve had to explain that it just isn’t that kind of game. I’m sorry. It just isn’t. Shooting stuff is not at the top of the agenda here. “Will the physics be like Quake?” Well duh, um, actually, who cares. Probably not.

Full disclosure:

I find most shooter games incredibly inane, shallow and meaningless. I can usually only enjoy a shooter if it has been enriched with a certain amount of brains (Bioshock) or story (Stalker.) And I relish it when a first-person game dares to drop the gun. Mirror’s Edge is a prime example of what a first person game can be if you take people’s guns away for the most part. It was an eye-opener in so many ways (how many games have people actually hugging?). I would like to go one step further and just drop the player into the world without a lot of obvious threats and without a weapon. The first level of Scout’s Journey has exactly three enemies, the first of which can just be avoided. Later levels have patrols, but engaging them (and how you engage them) is completely optional. Scout is not a beefcake space marine. The only time when you will meet opposition is when you [SPOILER].

It is just tiresome to talk about shooter games all day when you really want to do something different, but no one understands what you want to do. Unity/Unreal have a much broader spectrum of games. Not shooting things in the face all the time might be better received there.

I keep hoping there is an audience for less violent, exploration based, problem solving, spiritual, soul-searching, more human and truly mature (and I don’t mean that in the “lol boobs” kind of way, I mean mature in the full sense of the word) first person games.  Leaving the FPS modding community behind might actually help me to get there.

Interesting times. For now I will concentrate on assets and other engine-independent things. There’s enough work to do that has nothing to do with programming. People (especially FPS people) always underestimate how much work is in writing and concept art, for instance. I’ll be busy enough.

 

 

Advertisements

7 responses to “An Open Word

  • motorsep

    I agree with your summary of Quake1 GPL forks (DP and FTE in particular).

    If you have all time in the word, and don’t mind paying for updates every time they come out, and 5% share and the fact that not only you will need to learn Blueprint, but C++ too, and that Blender’s FBX exporter gets broken with every FBX SDK update, then perhaps going with UE4 is the right thing. I wouldn’t use Unity for an FPS game – there haven’t been any successful projects doing that.

    I would offer you to wait until we release Storm Engine 2 (modified Doom 3 BFG engine) with all Blender add-ons I’ve accumulated through the course of development, but the story is similar to any FOSS engine – you will need C++ programmer or you need to learn it yourself (the code is a way cleaner and leaner than DP’s and FTE’s code, IMO) to modify game code. On the bright side there are a way less bugs in our engine.

  • toneddu2000

    All the best man! I encountered same problem when I switched from Darkplaces to UDK.
    1° week I was banging my head against the wall, 2° week I was thinking: “Darkplaces…mmm..Darkplaces, this name reminds me something.. well let’s go back to program with UnrealScript! :)”

  • kneedeepinthedoomed

    Thanks guys.

    Storm engine 2 looks cool, but my Doom 3 mapping experience hasn’t been very positive. It is not a fun engine to map for. I really want to do all environments in Blender (or Modo or whatever, if I have to.)

    I don’t really want to do any engine coding. I’m fine with C++ though, I actually prefer a real programming language. I have modded games that use C++; I don’t fear it.

    I’ll look at the options and then decide what is best for the project.

    • motorsep

      Mapping for Storm Engine 2 (almost similar to Doom 3) can be quite similar to UE. You can make your meshes in Blender, and then block out level in brushes with caulk and place meshes for architectural details. The only thing that if you make entire level as one model, you need to cut it where vis portals are placed.

      Dark Radiant level editor has layers, configurable filters, and a way more streamlined UI. I also have Doom 3 map exporter for Blender, which export convex meshes as brushes. So you can make your level out of more complex primitives than just scaled cubes. Plus I have entity exporter add-on, which saves out entities. This way you can make a block-out map and architectural details, then export blockout as .map, models as .LWO, and then the same models as entities. So when you load block out map in DarkRadiant and import .map with entities, you automatically get your level ready. Just place lights and other entities/triggers/etc. and you are good to go.

      Everything is real-time too – no need to wait for hours for lightmaps being compiled. Of course the lighting is more stylized than pretty baked, but that’s something you either have to accept as style to enjoy benefits of unified lighting model. Or not and use some other engine 🙂

      Doom 3 has 3 layers of code, unlike DP/FTE. Core engine code (rendering, input, networking, etc.), core game code (lower level base functionality), game scripts (that where you work with AI, make new entities, weapons, etc.)

      I am not gonna lie here saying our engine is a rival to UE4/Unity. It’s not. But it’s a way more robust engine than DP/FTE when it comes to making a game. Like every engine it has its limits, but if you understand the limits you don’t have to code the engine ever – just extend existing classes for gameplay and write scripts.

      One thing I can tell you is content will take a way more time to create. So might as well just make art first (which you can carry across multiple engine) and then worry about code.

      • kneedeepinthedoomed

        I’m already using high-poly meshes and baking them down etc.

        I think soft shadows (shadowmaps) and realtime sunlight will be required for SJ. Trees have to cast proper shadows and all that.

        I have already used the caulk hull / detail models approach. It’s OK. The main issues I encountered when mapping for Doom 3 was that portals seemed to interfere with AI although they technically should not. And I can’t stand the way you have to light a map in Doom 3. SJ has detailed indoor environments with many light sources. High-resolution lightmaps (combined with some realtime lights) are a must.

        I’ll take some time to check out Unity and Unreal 4 and do some comparisons.

  • motorsep

    Doom 3 is different, and you gotta think differently when using it. Sure it would be nice to have deferred rendering and shadow mapping so designer could just dump lights into scene without thinking (although even UE4 and CE and U has limit of how many lights can be used to cast shadows).

    I think UE4 would be a best bet, not Unity. By the time it will mature, you’ll have all your assets made and ready.

  • onetruepurple

    First thought: fucking LOL. This game has traversed through the entire Quake engine family tree just to completely leave it. 😉

    I do hope the switch works out fine for you in the end, though. And yes, UE4 sounds like a good bet. I still hope to play around with it a lot, myself.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: