http://store.steampowered.com/app/459630
http:///
Hello Everyone!
We are a small team with rendering and simulation background creating an entirely new gameplay technique by doing a 100% physics based game that is fully unscripted and animation free. The idea is to only use Nvidia PhysX interactions (forces, impulses and joint motors, i.e. real life things) to control every gameplay input and by doing so to achieve the highest possible realism of motion with all its variety (the ‘no session like the other’). We did not do any public blogging etc for the last 1 1/2 years and worked behind closed doors because the concept is new and we were not sure if it was technologically possible to have it run stable. The game runs in Unreal Engine 4, which also adds realistic graphics. All in all, with the novel gameplay technique it will be a ‘hate it or love it’ game, which is perfectly fine with us. We are all in technology day jobs and in a position where we can be more innovative, can try riskier things business-wise, than a publisher who depends on the financial success of a game.
We want to share some crucial findings/experiences along the way that might help others here and there. Many long time users will already know about most of it, but maybe it helps some other users. I have been doing some modeling for the project and will do the blogging.
We want to share our findings about these topics:
1. Physics Stability
2. Assets
3. Optimization
4. Publishing Mistakes
Physics Stability
- general physics instability: UE4 provides Substepping. We ended up using 16 steps with max. 16.67ms. Without substepping, solid physics was not possible. We also use position and velocity iterations for each actor on high values (80, 10).
- We had to cap the framerate to 55 fps, which corresponds to 18.87ms frame time. This is longer than max 16.67ms for substepping and as such leaving buffer. This was very crucial and instantly made the physics much more stable.
- We use many UCX collision assets. In terms of collision penetration of two objects, it was very noticeable, that more UCX (or convex decomposition) facet are more stable. We assume it is because there are simply more checks between objects, reducing the chance that collision is overlooked.
- Level streaming and physics proved unstable. If there are constraints within an actor to be streamed with a level, they most likely ended up cramped. Not quite so if constraints are individual actors. We assume it is because of internal synchronization. We ended up having all physics actors and constraints in the persistent level, and then only streaming geometry. Some physics toys with constraints we spawned as actors after the level geometry was streamed.
- Having all physics components in one actor proved also more unstable than having them as single actors in the scene, with only one of the single actors controlling them all. So the parts of robot, the catapult and the catapult are all individual actors sitting in persistent level.
- This goes hand in hand with above: Having several physics blueprints/classes with event ticks was more unstable than having everything in one big blueprint/class. We assume this is because of lag introduced by blueprint/class communication and accumulated desynchronisation of physics thread and render thread.
- The game spawns a lot of constraints and we had to use terrains made in VUE and exported as obj/fbx to have ropes etc stick to the terrains with constraints. The UE4 landscape actor has no PhysX box (it does have collision though) that can be grabbed by a PhysX constraint.
Assets
We used Speedtree on the $20 subscription. The subscription is worth every penny. The trees are graphically most impressive with moderate runtime budget and modeling in Speedtree is just fun. It turns out that with the UE4 reimport option you can get really fast iterations done on trees. The UE4 marketplace proved of great value to get going fast with materials. We basically bought assets from there for some hundred dollars and used many of them as starting points for our own modified shaders/models. Some assets we used even directly, although only a few. I am sure the old hand users here in the forum will recognize some. The best one was the water, which is a heavily tuned version of the river material in the procedural nature pack. Also some trees from the other nature pack made it directly into the game and the modular building pack was the starting point for our city levels. Overall, the game will clock in at 2 years development time, and without the marketplace it probably would have been 3 years or more. The marketplace is a real win-win situation, because on one hand it makes some income for people who release on it and on the other hand gives a huge jump start for small teams.
For modeling we use 3ds max for complicated things and blender for the rest. For Audio with use Acoustica Mixcraft to remix and adjust songs etc to our game and a Tascam DR-05 V2 to record sound samples if we need some. Vue is used for terrains and hero plants.
Optimization
- We use rather large amounts of foliage. There are the usual LOD transitions. We found to our surprise that the Blender Decimate tool very efficiently strips polygons from geometries without changing the overall shape much. In fact, we ended up using it almost exclusively for LODs, although there are many other options out there. For adjusting foliage draw distance by user input we use the 'minimum screen size’ console command. (foliage can also be fully disabled with this)
- for all material mixing we use height lerps with noise textures and normal blending. One big pitfall in UE4 is the noise node in the material editor (Perlin etc), which increases instruction count by a lot and we avoid it for this reason. Otherwise we use maximum 2K textures and mix textures heavily. This way we get complexity and stay low on texture size. Except for the water, which costs some 200 instructions, all materials stay below 150 instructions, and most of them well below.
- other than that we provide sliders for all things like Shadow Quality etc. via console commands and created variables to change effects amount etc everywhere, but this is kind of the usual workflow. We also have all particle emitters move with the bot/vehicle/drone and in this way avoid having to place any particle emitters by hand in the levels. We also have one large initializing sequence running once the game starts, where all savegames are loaded and all variables are set to avoid potential problems with variable defaults set in the Editor not being transferred properly to the shipping built. In general, you have to explicitly define all render settings in some initialization sequence, otherwise they will be set to Epic in the shipping built and your game looks different then to the ‘Play in Editor’ Mode.
Publishing Mistakes
We did Steam Greenlight and contacted Publishers. We ran into a pitfall.
We did not know that if you are on steam greenlight, and later on a publisher shows interest, that the publisher has to stick with your ‘amateur’ greenlight campaign. Valve will not allow to cancel it and to use the established publisher steam channel instead. This is reasonable because the publisher’s PR possibilities would augment the true interest from the community. In some sense, this is probably what you would do as well if you owned steam, it is just understandable practice. But no need to mention, it does make publishers exactly happy if you are already on greenlight. So it took us by surprise because it was not written anywhere. We did not care much about publishing for the last 1 1/2 years, in fact for at least one year we never thought of publishing at all because the project was a hobby of us and we are all in technology day jobs that put food on the table. So we carelessly put it on greenlight and at the same time contacted publishers. Then the hammer hit us, we were told about the greenlight campaign thing by one publisher. We got lucky enough to have the game greenlit very fast, but this can be a bad thing for your game. If the game is on Greenlight for a few weeks, it ends up on the later pages and this can be a dead end for any game, disregarding the quality of it, with ~2000 games on there. You also can not remove it from Greenlight the way it is set up right now and thus it will sit there for years to come.
So the right order definitely is to pitch the game to publishers first and if that does not work out, only then do Greenlight. This on the other hand forces you right into the arms of publishers before approaching steam. It is an upside down situation: on one hand Steam aims at creating a channel for indie developers, and without doubt it is a very good thing, without it many indie developers would have no opportunity at all, but on the other hand the publisher-greenlight blockage forces indie developers to seek their luck with publishers first.
Also Kickstarter does not sit well with publishers, but that is normal, because you indirectly sold many copies already on Kickstarter which they would have sold.
Other than that, we can recommend to contact publishers. Many did not reply yet, which is kind of normal, but some replied. We only contacted german publishers because we are from Germany. The nicest one was Kalypso Media (the Tropico guys). They told us straight away that they do strategy games these days and our genre was wrong for them, but at the same time they explained us in great detail how our game could be improved and what we could do better, which was very nice. They were really helping with plenty of advices and were open. So we think the rule that you should only contact publishers who work in your genre can be ignored.
Hopefully some bits of all that help here and there.
