After reflecting a lot on this, we made the decision to not go ahead with our already-late 3rd game “Flyer”.
About the game: Flyer is / was an air combat simulator where the player takes control of a hovercraft to defend a fleet of space ships in the atmosphere of a gas giant as they get attacked by drones.
Why we’re stopping development:
I (Udo, this is mostly from my perspective since Sven hasn’t been involved in the game) dramatically underestimated the effort required to make 3D models that actually look acceptable, as well as the general effort it takes to make a 3D game. Since we’re making these games in our spare time, and there was a distinct lack of spare time during this last month, it’s no wonder that Flyer didn’t get off the ground there.
The gameplay is difficult and unrewarding. While I personally had a lot of fun playing the game, I don’t think it’s suitable for pretty much anyone else. Playability-wise the game combines the “worst” aspects of a helicopter flight simulator and a flight combat system. There are good reasons why helicopters don’t get into dogfights, but I pretty much made a game about that anyway.
It’s boring. I can sit for hours and just fly around in this game, but that’s not an exportable idea of fun and engagement. Even the action scenes, when I viewed recordings of them later, felt extremely boring and confusing,
The little feedback I got was negative. For the most part, people didn’t react to the game at all, which is always a bad sign. When I pressured people into giving me feedback, it was unanimously negative. On a very basic level, nobody saw why you would want to play this.
Big studios cancel games all the time for the same reasons, and I understand a little better now how that happens. I have no doubt that we could have salvaged this project by sacrificing more time to it, but that’s counter to our current mission. We want to explore and iterate on games quickly, throwing more good time after bad is not on the agenda.
Sorry if we disappointed anyone this time, but we’re already throwing around some ideas for our next project and the next time, we will have something to show for.
The idea of making one game a month is certainly not new, it’s even been meta-gamified with #1GAM. One of the questions we got was why we’re not participating in #1GAM? Well, part of it is we’re busy making the actual games, and we have to choose where and how to commit our resources carefully. I briefly considered it in order to connect to other people making games, but it doesn’t seem likely for us to forge a lot of meaningful relationships in a mature community of 13,000 developers. It’s also not like we need the motivational aspects of gamification.
So Why One Release per Month?
We need time to get comfortable with our tools and our processes, but more importantly we need to explore the space for a concept that will stick. We’re not ready to spend months chasing down one illusive idea if we’re not reasonably sure, both of our own interest in the concept and the public demand for it. It seems easy to commit to the first idea that comes our way, without knowing if anyone (including us) will care about it long term.
That being said, we aim to make our monthly game concepts high quality, fully playable downloads without game-breaking bugs. As far as we know, our last release had only one major defect regarding the persistence of savegames.
When Will We Make a Long-Term Game?
Right now we have a lot of ideas we’d like to test drive. Some of them may work out well, others may not. That’s an expected part of our process right now. We’ll commit to a longer-term project when we feel we have the experience and the data we need to make it.
Even though we’re not charging money for our monthly releases, UDVEN is fundamentally a commercial endeavor. We’ll know the right factors are in place for a bigger project when the financial aspects seem feasible – which is a good benchmark, I think.
In this game, you take on the role of Commander Wallis, a medieval watchman who must protect the shrines of the Holy Spheres from a sudden onslaught of tentacled beings of unknown origin. It is your job to prepare the defenses, place troops, and then coordinate the battles.
We focused a lot on strategy aspects and issues of balance. As you progress through the levels, you get access to more types of units and defensive measures, and we wanted to make sure every unit and item in the game has a unique purpose.
So I’m doing this, Spaceport Manager is going to be made. The only question at the moment is which game engine or framework (if any) to choose. I went over this with a friend who knows actual game developers, and this post roughly reflects the state of our conversation, plus the conclusion I eventually arrived at.
What I Want to Build
Spaceport Manager will be a base-building game where players build space ports and keep them running. As such, it will probably draw some inspiration from Dwarf Fortress, Prison Architect, Sim City, Rimworld, and others. It’s most likely going to feature a 3D top-down or isometric/angled view, although I’m still considering a 2D world as well. In any case, the game’s main view will be a map displaying some dynamically generated planetary environment and then a lot of buildings on top of it. There will be lots of people and machines milling about. Spaceport Manager is expected to make somewhat heavy use of advanced UI elements such as windows, list and tree views, and possibly 2D visualization widgets.
Any game framework or engine must at the very minimum fulfill the following critera:
run with minimal effort on current Windows, Linux and OS X installs
be friendly to dynamic content
allow for a reasonable programmer-centric workflow (as opposed to designer-centric)
enable extensive customization and UI work
I considered 4 choices for this project:
Choice A: Unity 5
A lot of games are getting made with the Unity engine. From what I can tell, Unity enjoys exceptional support from the indie game community, and it’s the default engine for Ludum Dare. Its 3D engine is certainly impressive, giving developers easy access to an almost AAA-level graphics implementation. Programming happens in an ancient dialect of C#, which is not the worst thing in the world, and apparently performance is decent.
On the con side, you can never “own” Unity, you need to rent it for 75 bucks per month plus some revenue sharing. While that cost is relatively low, the thought of renting a content creation tool and losing access to it when I stop paying bugs me. When using Unity, you are expected to buy things from its asset store, which I am not necessarily opposed to. However, my expected use of both the engine’s central 3D editor as well as the asset store is very limited given my game’s nature. If I choose Unity, I will spend most of my time writing C# code that puts objects on the screen, and this gives rise to the feeling that the engine is probably not designed with that specific use case in mind.
If I use Unity, my game will probably run fast on all platforms, and it will look great. However, I will probably spend a lot of time both learning how to use the engine and re-inventing the wheel because my game would probably be an off-label use case for Unity.
Choice B: Unreal 4
The Unreal 4 engine is a top-of-the-line choice, it’s what a real game dev studio would use. The graphics capabilities are simply amazing, and it too runs on every conceivable platform.
Like Unity, Unreal 4 centrally features its own 3D editor, an amazing tool I’m not going to use. Programming-wise access to the Unreal engine is facilitated through C++ or language FFIs.
The pros and cons are in fact absolutely similar to Unity. The central concern remains that my expected workflow will be very different from the use case these engines are optimized for.
Choice C: from scratch
To be honest, this is instinctively my most favorite option: build the game in C++ with OpenGL and SDL bindings, and maybe a script interpreter like Lua. However, since the clock is actually running on this project and I want to get a reasonable prototype out of the door quickly, I’m shelving this option for some future endeavor.
Choice D: Chromium Weirdness!
This one is a bit out there: I could just use the Chromium browser as a platform. It has decently fast WebGL and general hardware acceleration support, and it can be combined with web workers and the node.js runtime to write actual desktop apps. But why would someone do this?
On the con side, web technologies are certainly not fast by any stretch. I recently made a dungeon-crawler prototype in WebGL only to discover it was unplayable on my friend’s laptop even though the graphics were straight-up nineties level. If I used this, I would be relatively free as a developer in any sense, but the cost would be that the game could only run on recent hardware, and the graphics quality would be …underwhelming. Mobile and console versions of my game would be out of the question.
Like almost everything in life, this project starts of with a choice driven by weighing tradeoffs against each other. Whatever I do, I am faced with the possibility of discovering insurmountable problems at a later stage, at which point I would have to trash everything and start over. This risk seems especially prominent with the Chromium option, but I can see similar issues cropping up with Unity down the line. Even considering the Unreal engine, some nagging doubts about the cost of wheel-reinvention and off-label use remain.
Knowing the risks, I choose the Chromium option, for several reasons. Most importantly, my familiarity with the platform will ensure a reasonable speed of development from the get-go. If I accept the comparatively bad visual quality of the end product, the only potential showstopper will be crushing performance issues. The number of unknowns is probably small. From my current perspective, there is more potential for unwelcome surprises hiding inside Unity and Unreal.
How Could You?
I’m not sure it can work out, but I’ll certainly try. I’ll revisit this decision if something serious comes up. If this fails, I’ll blog about it, hopefully this will be useful to someone having to make a similar decision.