Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
10. January 2019


Earlier today Improbable released a blog post stating that due to ToS/EULA changes, it was no longer compatible with Unity and was being shut down.  A number of developers responded to this action, including game developers that used SpatialOS and whose games future was now in question, as well as developers of other game engines and technologies.  The only person without a comment was Unity itself, until now.

Unity have released this response to the entire issue, telling a much different version of the story.

Some key excerpts from the statement:

More than a year ago, we told Improbable in person that they were in violation of our Terms of Service or EULA. Six months ago, we informed Improbable about the violation in writing. Recent actions did not come as a surprise to Improbable; in fact, they’ve known about this for many months.

Two weeks ago we took the action of turning off Improbable’s Unity Editor license keys. This is a unique case — and not a situation we take lightly — but Improbable left us no choice. This was the only course of action to protect the integrity and value of our technology and Unity developers.

We believe that even though Improbable is violating our EULA, game developers should never pay the price for that. We have been clear with Improbable that games currently in production and/or games that are live are unaffected, and we would have expected them to be honest with their community about this information. Unfortunately, this information is misrepresented in Improbable’s blog.

The timeline in the dispute seems to match almost perfectly with Unity’s move into the networking space, as publically announced here.  Fortunately for developers who are currently using SpatialOS technology in their games, Unity insist that they should not be hugely impacted:

We are genuinely disappointed that we have been unable to come to an agreement with Improbable, and their improper use continued until we took the action we did. Despite this fact, we can assure developers that they will be able to continue development while we resolve our dispute. We are committed to ensuring that developers will receive support for any outstanding questions or issues as we work through this problem.

If you are using SpatialOS, please contact us directly at [email protected] or visit support.unity3d.com so we can address your questions and resolve your problems.

Finally some justification for why they updated their EULA/ToS:

From time to time, Unity will update its Terms of Service (TOS) to reflect how we run our business and address questions from our partners and customers. In December, we made clarifications to our Streaming and Cloud Gaming Restrictions because we received requests for clarification as the industry is evolving quickly.

At the core, the Streaming and Cloud Gaming Restrictions terms are still the same as before. We received feedback that the language was ambiguous, so we updated our Terms of Service to be clear on our distribution and streaming restrictions. We will continue to listen to the community and clarify as we can.

Their summary of what the changes mean to game developers:

From a technical standpoint, this is what our clarification on our TOS means: if you want to run your Unity-based game-server, on your own servers, or a cloud provider that provides you instances to run your own server for your game, you are covered by our EULA. We will support you as long as the server is running on a Unity supported platform.

As an example, if you have made a Windows or Linux player build of your game to be an authoritative game server and run that on a server in-house, you can continue to develop, publish or operate your game as usual. If you rent a server or pay for a cloud instance to run the game, you can continue to develop, publish or operate your game as usual.

Finally, and most important/impactfully, what it means for “platforms”:

However, if a third party service wants to run the Unity Runtime in the cloud with their additional SDK, we consider this a platform. In these cases, we require the service to be an approved Unity platform partner. These partnerships enable broad and robust platform support so developers can be successful. We enter into these partnerships all the time. This kind of partnership is what we have continuously worked towards with Improbable.


… so, there you have it.  The truth is probably somewhere in the middle.  Watch the video below for a bit more of my opinion/take on the matter and to share your own.

GameDev News


10. January 2019


Earlier today Improbable released the following statement regarding their cloud based networking service SpatialOS:

Today we must regretfully inform our community of the following developments.

  • Unity’s block of SpatialOS: The game engine provider Unity recently changed (Dec 5) and then clarified directly to us (9 Jan) their terms of service to specifically disallow services like Improbable’s to function with their engine. This was previously freely possible in their terms, as with other major engines.
  • What this means: Unity has clarified to us that this change effectively makes it a breach of terms to operate or create SpatialOS games using Unity, including in development and production games.
  • Ongoing negotiation: Worryingly, this change occurred during an open commercial negotiation with the company to find a way to do more together.
  • Revoked Unity license: In addition, Unity has revoked our ability to continue working with the engine for breaching the newly changed terms of service in an unspecified way.  This will affect our ability to support games.
  • Continuing service for all other engines: Users of all other engines remain completely unaffected and we are working with other engine providers to see if they can help support engine transitions for customers hit by this change.


The updated Terms of Service section 2.4 from Unity now reads:

2.4 Streaming and Cloud Gaming Restrictions.

You may not directly or indirectly distribute the Unity Software, including the runtime portion of the Unity Software (the “Unity Runtime”), or your Project Content (if it incorporates the Unity Runtime) by means of streaming or broadcasting so that any portion of the Unity Software is primarily executed on or simulated by the cloud or a remote server and transmitted over the Internet or other network to end user devices without a separate license or authorization from Unity. Without limiting the foregoing, you may not use a managed service running on cloud infrastructure (a “Managed Service”) or a specific integration of a binary add-on (for example, a plugin or SDK) or source code to be integrated in the Unity Software or Your Project Content incorporating the Unity Runtime (an “SDK Integration”) to install or execute the Unity Runtime on the cloud or a remote server, unless such use of the Managed Service or SDK Integration has been specifically authorized by Unity.  Additionally, you may not integrate the Unity Runtime with a Managed Service or  SDK Integration and offer that integration to third parties for the purpose of installing or using the Unity Runtime on the cloud or a remote server. For a list of Unity authorized streaming platforms, Managed Services and SDK Integrations, click here.This restriction does not prevent end users from remotely accessing your Project Content from an end user device that is running on another end user device.  You may not use a third party to directly or indirectly distribute or make available, stream, broadcast (through simulation or otherwise) any portion of the Unity Software unless that third party is authorized by Unity to provide such services.


In a nutshell, the new ToS seem to prevent running any portion of the Unity runtime on a cloud based install without prior licensing of the cloud hosting company and Unity directly.  The timing of this is quite interesting following on the heels of a partnership between Unity and Google to provide cloud based networking services.

In the meantime, developers that built their game around Unity and SpatialOS are going through a bit of a rollercoaster ride of emotions right now, such as Spilt Milk Studio:

image

Followed by:

image


Unity have not yet released a public content although their forums are quite… lively.

UPDATE: Tim Sweeney, founder and owner of Epic Games was quick to comment upon Unity’s gaff here and to reassure Unreal Engine developers that this wont happen to them:

image

GameDev News


8. January 2019


Godot 3.1 just became one step closer with the first Beta release, after several prior alpha releases.  Details of the beta release from the Godot blog:

After an alpha phase that took longer than anticipated, we're now ready to enter the beta phase for Godot 3.1, which means that the feature work is finished for this version. From now on, we are in release freeze, which means that new features will no longer be merged, and we will focus solely on fixing release-critical bugs.

This should allow to finish polishing this release quickly and hopefully be ready to publish it by the end of this month. See this GitHub issue for details.

Contrarily to our 3.0.x maintenance releases, which include only thoroughly reviewed and backwards-compatible bug fixes, the 3.1 version includes all the new features (and subsequent bugs!) merged in the master branch since January 2018, and especially all those showcased on our past devblogs. It's been almost a year since the 3.0 release and close to 6,000 commits, so expect a lot of nice things in the final 3.1 version!

While there are no formal release notes available yet, the following change log tracks the majority of changes in the 3.1 release.  Highlights of this release include:

  • OpenGL ES 2 support returns (alongside ES3 support)
  • Visual Shader Editor improvements (video)
  • CSG support (video)
  • 2D and 3D physics improvements, including Softbody and Ragdoll systems
  • 2D mesh and skeletal deformation (video)
  • KinematicBody2D improvements
  • Optional static type support (video)
  • 2D Animation improvements (video)
  • 3D Animation improvements (video)
  • much, much more

The 3.1 beta release downloads are not available on the primary download page and can only be downloaded here for GDScript only builds and here for Mono/C# builds.

GameDev News


8. January 2019


The Panda game engine is a C++/Python based open source game engine form in collaboration between Carnegie Mellon and Disney, previously used to power MMOs such as Toon Town Online and Pirates of the Caribbean.  In addition to the 1.10.0 release they performed a complete facelift, with a new logo and a much nicer overall website.  The major improvements to Panda in 1.10.0 include support for Python 3.x in addition to Python 2.x, improvements to the shader process and underlying OpenGL renderer, cross platform gamepad support, Android port improvements, HarfBuzz text shaping and more.

Complete details from the release notes:

General

  • Experimental ability to build for Android
  • New input framework to natively support gamepads, joysticks, etc.
  • Multi-threaded render pipeline is a lot more stable now
  • New setuptools-based deployment pipeline
  • Improvements to mouselook smoothness
  • Cache is now at $XDG_CACHE_HOME/panda3d (~/.cache/panda3d), not ~/.panda3d
  • Addition of unit test suite
  • Many improvements to thread safety
  • Many performance improvements
  • Tons of bugfixes
  • Big style cleanup of C++ source code

Python API

  • Complete support for Python 3
  • Support for coroutines and async/await
  • Property interfaces have been added for many settings
  • More flexible handling for keyboard arguments in C++ APIs
  • Python bindings are completely separated out of the C++ libraries.
  • Interrogate binding generator has many improvements.
  • Use of pandac.PandaModules is discouraged, use panda3d.core et al
  • Use of libRocket is discouraged due to lack of Python 3 support
  • Tasks are now sorted in addition order when lacking a sort value
  • Fixes iris/fade transitions for extreme aspect ratios
  • WeakNodePath is now exposed to Python
  • WindowProperties.size(x, y) deprecated; use WindowProperties(size=(x, y))
  • Calling bare run() is deprecated, use base.run() instead
  • downcastTo*() methods have been removed, they were already no-ops

Rendering

  • Add new shader-based terrain rendering method (ShaderTerrainMesh)
  • The default ColorAttrib mode is now T_vertex
  • The ColorAttrib T_off mode now properly disables vertex colors entirely
  • Make handling of color attributes more consistent between renderers
  • Ability to create an OpenGL core profile context; set "gl-version 3 2"
  • Experimental support for reverse-Z rendering for best depth precision
  • sRGB framebuffers supported more widely
  • Support for infinite near/far clip in lens
  • Add some PBR material parameters to material class
  • Addition of more built-in GLSL shader inputs; see manual.
  • Add p3d_FragData[] GLSL output for MRT in GLSL 1.30
  • Add flag enabling vertex shader control over point size
  • Support signed ints and double-precision floats in vertex data with GLSL
  • Support unsigned 11/10/10-bit floating-point textures and vertex data
  • Support for SSBOs via ShaderBuffer class
  • Support OpenGL FBO buffers without any attachments
  • Support passing uint variables to GLSL shader
  • Allow rendering objects with empty vertex data (for vertex pulling)
  • Add LogicOpAttrib, for supporting logical operator blending
  • Improvements to OpenGL ES support
  • Support for geometry with adjacency information
  • Change default alpha blending to improve blending rendered result
  • New method for obtaining native OpenGL texture object
  • Support windowless offscreen rendering on macOS
  • Panda resets OpenGL state better before and after draw callbacks
  • OpenGL renderer better supports debugging tools like apitrace
  • Support fixed-depth billboards, useful for 2D tags that don't change size

Shader generator

  • Significant performance improvements
  • Support for point light shadows
  • Hardware skinning support
  • Changes to match fixed-function pipeline better
  • Fixes for normal vector normalization
  • Support multiple normal maps (uses Reoriented Normal Mapping)
  • Tracks modifications to materials and texture stages automatically

Lighting

  • Allow specifying light color based on color temperature
  • Setting specular color of a light separately is deprecated
  • New GLSL inputs to make implementing lighting in shaders much easier
  • Add representation for sphere light and rectangle light
  • Efficiency improvements for passing light information to shader
  • Interocular distance for shadow cameras now always defaults to 0
  • Add low-level lighting module from RenderPipeline

Textures

  • Support cube map arrays
  • Support buffer textures
  • Many more texture formats supported
  • BC4 and BC5 compression modes supported
  • Proper depth textures supported in DirectX 9 renderer
  • set_ram_image(_as) directly supports buffer protocol
  • TexturePeeker supports more formats and component types

Text

  • Dramatic improvements to text rendering performance
  • Support for HarfBuzz for higher-quality text shaping and kerning
  • Support for right-to-left text
  • Support for signed-distance-field rendering in egg-mkfont

Audio/video

  • The default unit for audio is now 1 meter for each Panda unit.
  • Native .flac loader
  • Support videos with alpha channel in ffmpeg
  • OpenAL stability improvements, especially on macOS
  • Support loading .opus files with libopusfile
  • Fix various memory leaks

Physics / collisions

  • CollisionTube is renamed to CollisionCapsule.
  • Box-box collision test is improved to work well with the Pusher
  • More box tests for collision system: box-into-plane, box-into-poly
  • Capsule (tube) can be used as "from" shape into plane, sphere, capsule, box
  • Bullet objects are serializable to .bam files.
  • Bullet bindings are now thread safe.
  • Bullet debug drawer is more efficient; no longer inherits GeomNode.
  • Various fixes to bullet vehicle wheel synchronization
  • PhysX bindings are deprecated.

Pipeline / loading

  • Support for Assimp library to load a broad variety of model formats
  • Ability to specify min-lod, max-lod, lod-bias in .egg file
  • Egg file materials support PBR-style material parameterization
  • Support loading more DDS files, including DX10-style ones
  • Add support for OpenEXR and HDR textures
  • Support line/point thickness in bam2egg
  • bam2egg no longer inserts a vestigial ModelNode at the top
  • bam2egg supports depth test, offset, cull bin attributes
  • Accept a .gz file wherever a .pz file is accepted
  • egg-palettize supports mirror and border-color wrap modes
  • More robust checks against memory corruptions when loading bad .bam files
  • Support for Maya 2017 and 2018
  • Support preprocessing GLSL shaders created with Shader.make

Build

  • We now require using MSVC 2015 or 2017 to compile on Windows.
  • At least GCC 4.8 is now required.
  • With GCC/clang, enabling C++11 is now required.
  • Allow building with more recent ffmpeg versions
  • Support for old FFMpeg versions (before 1.1) dropped.
  • The ppremake build system has been removed.
  • Support for OpenSSL versions before 0.9.7 has been dropped.

C++

  • Use of NULL is replaced with nullptr
  • WeakPointerTo now requires use of lock() method for thread safety
  • Mutex et al now satisfy C++11 Lockable constraints
  • Panda headers no longer contain using namespace std;
  • PN_int32 et al have been removed, use stdint.h types instead
  • The need to link with pystub and add Python include dirs is removed.


You can learn more about this release on the Panda developer blog and the source is available on Github on the BSD license.  You can download the Panda SDK here with Linux, Mac and Windows downloads available.

GameDev News


8. January 2019


Back in June of 2018, Microsoft acquired GitHub for an eye watering 7.5 Billion dollars.  This transaction took several months to make it through regulatory approval, with Microsoft finally taking control near the end of 2018.  Yesterday, we saw the first official impact of the ownership change and for end users, it’s a pretty good change.  The free tier of GitHub now offers unlimited private code repos!  This was arguably the biggest reason for many small developers to actually pay for a premium account, so for these developers, they can downgrade to free and save their money.  Now the major limitation between Free and Pro accounts is the number of collaborators in a private repo, with the free tier have a limit of 3, while the pro tier has no such limit.

Details of the new changes from the Github blog:

  • GitHub Free now includes unlimited private repositories. For the first time, developers can use GitHub for their private projects with up to three collaborators per repository for free. Many developers want to use private repos to apply for a job, work on a side project, or try something out in private before releasing it publicly. Starting today, those scenarios, and many more, are possible on GitHub at no cost. Public repositories are still free (of course—no changes there) and include unlimited collaborators.

  • GitHub Enterprise is the new unified product for Enterprise Cloud (formerly GitHub Business Cloud) and Enterprise Server (formerly GitHub Enterprise). Organizations that want the flexibility to use GitHub in a cloud or self-hosted configuration can now access both at one per-seat price. And with GitHub Connect, these products can be securely linked, providing a hybrid option so developers can work seamlessly across both environments.

Pricing for individuals now breaks down as follows:

image

Not a bad first move…

GameDev News


GFS On YouTube

See More Tutorials on DevGa.me!

Month List