Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
19. July 2017


The following tweet, sparked off a bit of an interesting conversation about game development, game engines, game journalism and it’s affect on end users.

image


I understand the perspective Adrian takes and I agree and disagree with him all at once.

First off, the part I agree with.   The end users should not be prejudging, or in this case, outright dismissing games based of the engine they are developed in.  This is like dismissing a film because of the way it was filmed.

However, that same analogy holds true.  Think back to the beginning of the 3D movie craze around the time of Avatar and all the CRAP films that were made because of this focus on 3D.  Dismissing a film because there was a 3D version available was a dumb thing to do... but being wary of it it certainly wasn’t.


This is where I stand on the subject, from a developers perspective.  When it comes to 2D games, I think this is pretty much a moot point.  The game engine is really quite transparent on 2D titles and really it’s the art that sets the tone.  With 3D however, it’s not so simple.  3D game engines certainly put their fingerprint on the games they create and game developers should be very aware of those fingerprints. 

There are two ways a game engine influences the underlying game, design and results.  Let’s quickly talk about both.

Design is when the structure of a game engine influences the structure of the underlying game.  For example Unity by default has a very level oriented work flow, while CryEngine has a very landscape/terrain focused design and both it and Unreal Engine are very 1st/3rd person oriented in their design.  In all cases this can be overcome...  Mortal Kombat is an Unreal Engine game, Cities: SkyLines was made using Unity and Star Citizen was made using CryEngine (now Lumberyard).  In every case though, this took a great deal of effort and wrangling an engine into doing what the engine didn’t want to do.  I remember a great deal of complaints among early Kickstarted CRPG games (like Wastelands 2) about the game engine negatively influencing the end game.

Where it is increasing noticeable though, its in the results (AKA graphics) and this is for a couple of different reasons.  First, when you are dealing with a 3D game, there is a great deal more computation going on behind the scenes than in a 2D title.  You have a 3D renderer, materials system, lighting system, physics system etc.  All of these things are complex and will come with defaults to make a developers life easier.  Thing is, every single time people go with the defaults, it’s a finger print left by the game engine on a game.  You will often see comments like “Unity games are ugly”, where in reality the end user is picking up on the default renderer, lighting, etc.  The other tell tale sign of a game engine is using assets from it’s collective asset store.  An asset store is a potential boon to developers, especially ones with limited resources.  On the other hand, hearing the same jingling, seeing the same model or texture, etc... will rapidly lead users to find the games feeling very “same-y”.  You would be amazed what our subconscious mind picks up, there is a reason we have Deja vu so often, and no... nothing was changed in the Matrix.

Another reason why end users might wish to be aware of what game engines a game was written in comes down to hardware.  Some engines simply run poorly on some hardware or have higher system requirements, etc.  For example, all CryEngine powered games could be customized and tweaked using the same process and could be expected to run similarly.  This is a very valid reason for consumers to be aware of what engine a game was written in.

Finally, some readers, even less technically inclined readers may in fact want a peek behind the curtain.  I certainly know I eat this kind of stuff up.


So, should journalists stop talking about what game engine a certain game is made with?  Certainly not.  Don’t focus on it, or condemn because of engine used, but discuss it?  For sure!

At the same time any gamer that’s dismissing games outright due to the engine they are created with are doing themselves and the games in question a massive disservice.  Finally, I don’t think game developers should be overly concerned which game engine they go with, so long as it fits their need.  They should however be very aware that these game engines do put their fingerprints all over their games if they aren’t careful!

General


17. July 2017


Even with the release of the newly branded Unity 2017 series, the previous 5.6.x branch is still being maintained.  Today Unity released patch 5.6.2p3.  Other than some changes to logos to match new branding, this patch consists entirely of fixes, including:

Changes
  • Editor: Updated Unity logos in About Window and Update Window to match new branding.
Fixes
  • (917931) - 2D: Fixed an issue where adjusting Collider2D's Offset when Using Tiled Draw Mode and Auto Tiling would result in inconsistent behaviour.
  • (918524) - 2D: Fixed an issue where the Editor becomes unresponsive when switching from OpenGL to Metal with a tiled sprite in the scene.
  • (920360) - Android: Buildpipe - correctly split resources between APK and OBB when building with LZ4.
  • (924523) - Android: Gradle - Removed debuggable from Manifest when creating APK.
  • (924519 Android: Gradle - Make sure unity3d and other files from raw/ are uncompressed in the APK.
  • (none) - Android: Gradle - Handle too many errors; filter out warnings and detect too long error list.
  • (924517) - Android: Gradle - don't explicitly set debuggable attribute when building with Gradle to avoid lint security warning.
  • (924516) - Android: Fixed the NamePhonePad flag.
  • (922898) - Android: Moved GoogleVR initialisation to run on UI Thread thus fixing startup crash.
  • (887824) - Android: Gradle - Support custom library build.gradle files.
  • (918606) - Android: Fixed an issue with enabling Split Application Binary flag in Android player settings would affect other platforms.
  • (919308) - Android: Fixed an issue with alpha texture size in ETC1 texture compression with split alpha.
  • (925444) - Animation: Fixed layer root motion broken on standalone.
  • (914365) - Animation: Fixed a crash in PlayableTraverser::RootByType that was triggered when disabling a GameObject by using OnStateMachineExit.
  • (901588) - Editor: Restored SRGB write state after internal override.
  • (915524) - Editor: Fixed the case of "Generate Lighting" drop down menu being hidden when inspector was resized to minimal width.
  • (none) - GI Progressive Lightmapper: Fixed a crash in light probe rendering occurring when changing or removing probes.
  • (912603) - Graphics: Fixed sRGB flag returning false on the LDR target texture from a HDR to LDR image effect in a linear project.
  • (923842) - Graphics: Fixed an issue where overlapping cameras drawing to the same target would not composite correctly
  • (913828) - Graphics: Fixed an issue where a ComputeBuffer applied to a Material Block doesn't take effect when drawing via DrawMesh*Indirect.
  • (918788) - Graphics: Fixed a rare crash/hang which, could happen in very complex scenes, when graphics jobs were enabled.
  • (912723) - Graphics: Fixed a crash triggered by setting the SkinnedMeshRenderer.updateWhenOffscreen flag to true via a script.
  • (923517) - IL2CPP: Fixed an issue with setting enum type fields in .NET 4x with relfection using an integer value.
  • (894273) - iOS: Fixed an issue where iOS screen info was retrieved for every request instead of being cached
  • (880426) - Linux: Added an additional fix for uninitialized screen dimensions(/mouse input) at startup with some window managers.
  • (924516) - UI: For Name content type, use NamePhonePad touch screen keyboard type.

The patch is available for download for Windows and Mac OS here.

GameDev News


13. July 2017


Babylon.JS 3.0 has just been released.  BabylonJS is an open source WebGL powered 3D game engine.  If you are interested in learning more about BabylonJS I reviewed an earlier version available here as well as a more recent tutorial series available here.  The 3.0 release brings a number of new features to the game engine including WebGL 2 support, WebVR 1.1 support, glTF 2.0 support and more.  Perhaps most interestingly, this release also introduces the Babylon.UI extension for creating user interfaces.


Details from Microsoft’s developer blog:

Support for WebGL 2

WebGL 2 is a great step forward for 3D developers as it allows more control over the GPU. The support for WebGL 2 is completely transparent with Babylon.js 3.0. This means that the engine will automatically use WebGL 2 if available, and it will fall back to WebGL 1 if not. Mode details can be found here.

Support for WebVR 1.1

With a single line of code, you can now unleash the power of virtual reality directly in your browser. Babylon.js 3.0 supports all VR devices, including the new Windows Mixed Reality headsets. Babylon.js can also transparently use WebVR 1.0 if your device does not support the latest version of the specification (Gear VR for instance). It also supports using device orientation events to provide virtual reality on mobile.

You can visit the Build 2017 website to watch a complete session about Babylon.js and WebVR.

You can find the Sponza demo here.

Support for glTF 2.0

glTF is a file format for GL APIs. With Babylon.js 3.0, we added complete support for loading glTF 2.0 files (including physically based rendering materials).

This version was ratified recently by Khronos group. glTF will help the 3D ecosystem to enable all new ways to create, share and consume 3D.

Improved physically based rendering (PBR)

The PBRMaterial used to render physically based objects was completely rewritten. It is now more accurate and better aligned with GLTF2.0 specifications. This material can be used to simulate real life lighting and provide photorealistic scenes.

You can find a live demo here.

Introducing Babylon.GUI

The Babylon.js GUI library is an extension you can use to generate interactive user interface. It relies on hardware acceleration to produce a fast and light way to deal with user interaction.

The Babylon.GUI extension can be helpful with VR scenarios when you cannot display HTML elements. It can also be used to project your UI in 3D. In this case, the UI will be textured on a 3D object but will remain functional.

Support for morph targets

Morph targets are a great way to animate objects by using morphing between different targets. This technique is widely used to animate character heads, for instance.

You can find a technical demo here.

Support for live textures using WebCam

You can now create project webcam content to any textures in your world. This could be used to simulate mixed reality experience or apply some fun effects like in this ASCII art demo.


BabylonJS is available here and on Github.

GameDev News


12. July 2017


The Godot Game Engine has just received Python support via the new GDNative interface.  Unfortunately the project is Linux only at this moment, so MacOS users will have to jump through some additional hoops, while Windows users are simply out of luck.


Details from the Godot blog:

All core features of Godot are expected to work fine:

  • Builtins (e.g. Vector2)
  • Object classes (e.g. Node)
  • Signals
  • Variable export
  • RPC synchronization

On top of that, mixing GDScript and Python code inside a project should work fine, have a look at the Pong example to see how you can convert one by one your existing GDScript code to Python fairly easily.

This release ships a recent build of Godot 3.0-alpha (yes, it's a beta based on an alpha...) and CPython 3.6.1 with the standard library and pip, ready to work with the Python ecosystem in its full glory (can't wait to see people experimenting game AI with Pytorch!).

The project is Linux-only so far, however you should be able to compile it from the sources if you are on macOS (let us know if you do so). Binaries for all platforms will eventually be provided when Godot 3.0 gets stable.

As always, keep in mind this is a beta and you are expected to encounter issues and maybe crashes. If so, make sure to report them on the project's bug tracker ;-)


The project Github page is available here.

GameDev News


11. July 2017


A new version, 1.2.108, has been released for the Defold game engine.  The Defold game engine is a cross platform, Lua powered, free (as in beer) mobile focused game engine.  If you are interested in learning more about the Defold engine, we have a complete tutorial series available here.


This new release brings a few new features including new texture formats, native extensions are finally available on Win32 and support for the newest iOS and OS/X versions.


Full details of the release:

  • DEF-2746 - Added: Add 16-bit RGB/A and Luminosity + Alpha support to engine
  • DEF-2796 - Added: WebP lossy/lossless support for 16-bit RGB/A and Luminosity + Alpha
  • DEF-2731 - Added: Added Win32 support in Native Extensions
  • DEF-2778 - Added: Added support for iPhoneOS 10.3 and MacOSX 10.12
  • DEF-2690 - Fixed: Bump max spine scene count for GUI scenes
  • DEF-2716 - Fixed: Minor fix for ColladaUtil if scene only has bones in the visual scenes entry.
  • DEF-1954 - Fixed: WebP lossy compression with HIGH compression level gave visual errors

GameDev News


GFS On YouTube

See More Tutorials on DevGa.me!

Month List