Unity sale rumour

Word on the street is that Unity may be getting sold. The entire company, lock stock and barrel. Hmmm.

Depending on who the buyer is, this could be good or bad news, but I think it might be one of the large tech companies if it’s true at all. I reserve judgement, but I don’t really like the idea of depending on some tech monster company’s whims to make my game. Their only interest is profit, which means they’ll dump their software and its users when they feel like it. I’d rather use an engine that’s made by an actual game company.

Funny thing is that a lot of people are now clamoring for the supposed benefits of open source engines. Hey, that gives you full control over everything, and makes you totally independent, right?


People are forgetting that the open source attitude to bugs is “fix them yourself.” You don’t have full control over an open source engine unless you either are an experienced C/C++ programmer or can afford to hire one / are successful at recruiting one. And then you’ll have a new dependency on that person.

The mindset in the open source world is totally different from the one it takes to make commercial games. There is a lack of discipline and commitment there. This is why open source games have never taken off. Read my previous blog posts if you want more insight.

Not to mention that maintaining and fixing a modern game engine is a shit ton of work, probably too much work for most indie developers.

Open source is not the perfect candy dreamland that some people seem to think it is. It doesn’t really solve more problems than it creates. It is not a substitute for something like Unity.

Anyway, I’ll be watching the development around the Unity engine curiously, as will a lot of others.

Unreal 4 better be good.

Friends in Unlikely Places


Found a better way to transfer .map to .obj after reading the tip somewhere on quake3world.com. Instead of q3map2 one loads the map into Q4Radiant (of all things) and then simply select everything and export selected as .obj.


This is the q3map2 version – as we saw before, it looks like a shattered mirror. The geometry of the version exported from Quake 4 (upper image) is very clean, and a single “tris to quads” in Blender gives you a workable mesh.

This will save me a huge amount of time.

In theory, this also means that you can easily map in Radiant and export to Unity. You just need Quake 4.

Currently still looking at engines, not decided yet. It can be done in both Unity and UE4 though, I’m sure.

And Another

I realize not everyone loves to read a wall of text. So here’s a synopsis.

SJ is switching engine because I have the feeling that the open source engines are not dependable and their authors not committed enough. My fear is that a nasty bug pops up when the game ships (or during testing), and the engine coder is not motivated to fix it at that time. With a commercial game, this is a pretty bad scenario that could get ugly fast, especially that late in the development process. Consider people writing angry reviews and wanting their money back – this is something that can’t be allowed to happen.

The decision was not rash; there is a two-year history and a collection of issues behind it (even longer if I count the mod project preceding it.) It is not a personal thing, it is a management decision for the best of the project. I realize that such decisions might be viewed as harsh. Consider that they are also harsh on the one who has to make them.

One could make the argument that these engines are free, thus it can’t be expected for them to be fully dependable. From their perspective, that is correct and it is hard to argue with that.

From my perspective it matters little, because what good is any engine that might fail at a critical time? No matter if it is free. Consider that Unity is also free.

I hope this is easier to read.

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.



Chatty 2


So, continuing work on dialogue system.

I did a bit of research and it became clear to me that a huge box full of text and 6 or 7 clickable choices is probably information overload. That was cool in the Nineties, but more modern games have done a lot to refine the way we deliver dialogue in games (Mass Effect series, Deus Ex: Human Revolution are two examples.)

The main thing where we made progress is this:

Seperate choices from plain talk.

This means there is a difference between interactive and non-interactive dialogue pages.

There is also a variation of types of choices (multiple choice, yes/no choice, choice affects player alignment etc.)

And finally, recent games have a tendency to minimize the amount of choices vs talk. Deus Ex: Human Revolution does this to the point where many dialogues will only include a single choice for the player to make. Everything else is practically just a cutscene.

So there is a spectrum where a game can fall between “lots of player choice” (old RPGs such as Baldur’s Gate mark this end of the scale) and “lots of non-interactive (more cinematic) dialogue” (as in recent games.)

The upside of the cinematic approach is that conversations have more of a natural flow and that dialogue is a smaller part of the game compared to e.g. shooting people in the face. For some games, this is right.

The upside of more choices is the opposite; dialogue becomes a major interactive system, and narrative becomes potentially more player driven (as long as the options make sense.)

SJ will probably fall somewhere in the middle. Have fewer options but make each one count.

My current test case dialogue clearly has some redundant choices in it; in the above image, if you look closely, the “I’ll do it” option is redundant. In other words, if the player wasn’t interested, they would not even click on the “why would I do that” option!

The doodad in the middle has several functions that I’ll not dive into. Suffice to say it is an indicator.

I’m not done with dialogue yet by far. Creating a dialogue system is a science, and it ideally interlocks with several other game systems. So I might yet end up with something totally different.

Getting chatty


I’m currently working on NPC dialogue. Players will be able to participate in a branching dialogue with certain NPCs. To this end, I have designed a scripting language for dialogue files.

The scripts are inspired by those used for interactive fiction games / interactive novels. They are written in such a way that they are both easy to author and easy to translate.

Currently, the scripting side is well developed; touching a trigger or character initiates dialogue; parsing the scripts from SSQC basically works (string buffers); and strings are being sent to CSQC for rendering. Next up is programming the actual display part in the CSQC GUI code, which is why I created a mockup. I’ll need positions for the background and each line in percent of the screen size, and the only way to get those is applying a good old fashioned tape measure. It’s done like this for all CSQC displays in SJ.

Stuff is subject to change, especially the background.

Here’s an example snippet from a dialogue script:


Dialogues can be as much as 10 levels deep and 10 – 12 lines can be displayed per page.

The player will receive quests via dialogue (except the main questline, which auto-activates in the first level and daisy-chains from there.)

As far as I know, FTE has full support for UTF-8 which will become interesting once translations are made (there will be at least English, German and Danish versions.) Strings from code can be translated, too, by GNU gettext.

I’ve been putting branching dialogues off for a long time, because I was unsure how to display them – an old idea was to use a console object (FTE can display multiple consoles and they also support links.) Well, it somehow fell into place now and I guess consoles can still be useful elsewhere.

I have to thank Spike, as usual, and this time also Sharkbanana (who is working on a game using FTE as well) for a pile of grizzly programmer wisdom. I’m sure I can be a nuisance sometimes. Programming stuff like this robs me of my last nerve and only large doses of metal music will ease the throbbing brain ache. \m/



I’ve been checking out the recent git version of MyPaint (the free digital painting app.) There’s a bunch of new stuff – a dark theme, new icons, and the layer etc. windows now automatically dock into a neat sidebar. There’s a new panel at the bottom of the window that relates some additional information, including possible keyboard shortcuts (zoom, rotate canvas, pick colour etc.) The colour swatches on the bottom left are kinda useful – you can use the left swatch to pick a different value of your current colour (lighter/darker) with the stylus which is nice. Of course there are also various colour pickers and a scratchpad.

MyPaint currently has an experimental branch with support for layer groups and, finally, layer masks. So these features are coming. There is also a new bucket fill tool, and I spotted a lock-transparent-pixels feature which is implemented as a blend mode on the brushes. Very handy for masking operations. There are also many new layer blend modes – the list seems to be nearly complete now.

The line/curve/ellipse tools are more visible in the toolbar and related keyboard shortcuts (turn a line into a curve, rotate an ellipse etc) are better explained. The brush settings window has been redesigned, so creating your own brushes should be simpler. A pretty nice new brush package has been included.


The major thing MyPaint is missing are selections. So I’m not sure why there is a bucket fill tool now, which would typically be used to fill a selection. Oh well. They aren’t indispensable for concept art with a plain background anyway, since it’s possible to just paint yourself a mask like I did here (the white) and there is also alpha lock for quick “masking.” Or you could just use temporary layers.

I believe I mentioned the HCY colour wheel (hue chroma luma), the support for loading and creating Gimp palettes, and the very cool gamut mask feature in an earlier post. This is pro stuff and a joy to work with. The colour picker that displays a realtime preview swatch while you move the stylus over the image is pretty cool as well. And last but not least, the git version now supports vector layers(!) which a lot of people will like.

Current git version is still a bit crashy, but I hope for a stable version 1.2 soon.

Ubuntu (and Arch) users have it easy – they can just install the mypaint-testing package to get a very stable git version; Windows users will have to jump through a few hoops unfortunately. The stable Windows version is ancient.

I did a comparison between MyPaint and Krita as well, and while the latter does bring selections and a text tool (which will please comic artists) there is no doubt in my mind that MyPaint still takes the cake for concept art and illustration because it’s smaller, leaner, faster and more user friendly. MyPaint seems to put more of a focus on its core drawing/painting/brush engine functionality.

Krita failed to support pressure sensitivity with my Ubuntu and Wacom tablet, while MyPaint does this out of the box. Krita’s UI is comparatively cluttered and seems overloaded with features. I’m not sure why e.g. special effects filters are necessary at all for digital painting. Something that really bugged me about Krita was having to go through a fullscreen “New file” dialog after every lengthy startup. By comparison, MyPaint simply displays its default endless canvas after an instantaneous startup.

For open source digital painting, the combination of MyPaint and GIMP Paint Studio still looks unbeatable – for what MyPaint can’t do (marquee selections, copy merged, free transform, text, gradients), you can depend on the heavy artillery of GIMP. The two apps interact perfectly via the Open Raster format (meaning layers etc. stay intact) and GIMP can read/export PSD files.

Still, options are great – I’m glad to see the Krita kickstarter was very successful. Free digital painting has come a long way. The only major Photoshop features still missing from GIMP/MyPaint, as far as I’m aware, are clipping masks (though Krita has those), adjustment layers, and an easy way to record macros (Krita does those, I think.) The various dev teams are also talking to each other – for example, MyPaint’s (excellent) brush engine can be loaded into Krita and is scheduled for inclusion in future GIMP versions. 16 bit colour support is also coming to GIMP.

Good times for free painting.

Bonus: I was recently made aware of this outstanding digital painting tutorial playlist. I can’t recommend this enough. Best of all, it is free.


Get every new post delivered to your Inbox.

Join 49 other followers