Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon

14. June 2017

This is a brand new series being launched on YouTube and GameFromScratch and is somewhat different in scope.  The aim is to essentially make the same game several times in different game engines.  We are creating a simple bowling game in various different 3D game engines.  In fact, we are creating this bowling game which we completed earlier using the PlayCanvas game engine.

For each game engine in the series we will implement basically the exact same game, along with a step by step text version, plus a video of the process.  This should be useful for a number of reasons.  First it enables you to directly compare the workflow between different game engines.  Second, it shows... perhaps not best practices, but how to get started creating a full featured, if extremely limited, 3D game with physics, scenes, model importing an more.

At this point in time I have begun implementing it in a number of different engines, including:

    • PlayCanvas
    • Atomic Game Engine
    • Godot 2.x
    • Unity
    • Unreal Engine

Depending on the popularity of the series I am willing to implement the game in other engines as well with a few caveats.  The engines need to support all the required features ( level editor, 3d model importing, physics, etc ) required to make the game.  So while I could implement such a title in a code focused API such as Ogre or LibGDX, it’s completely outside of the scope of what I am trying to accomplish here.  I also need to have access to the game engine, either through public domain, free trial, etc.  This currently rules out some engines such as Leadwerks and Shiva unfortunately. 

Beyond the engines listed above, I’d love to hear what other engines you would like to see covered? 

GameDev News

14. June 2017

Godot 3.0 is a massive update for the Godot game engine that is actively underdevelopment and anxiously anticipated.  Today they posted an update describing the newest functionality that will be appearing in Godot 3.0.  The blog post goes into a great deal of detail, but here is the TL;DR version:

  • GDNative – native language bindings rewritten C++, as well as RUST and D bindings addedGodot
  • Customizable themes and general UI improvements
  • WebGL 2.0 and WebAssembly support
  • C# (Mono) support
  • AR/VR Support development work using OpenVR
  • “Freelook” 3D scene navigation for WASD type scene control in Godot
  • Script editor enhancements
  • MFI controller support
  • Various fixes and improvements

So this of course leads to the most obvious question... when are we going to see Godot 3.0?  Well...

Godot 3.0 is coming along pretty nicely, and though its development is taking longer than we initially planned back in Fall 2016, it's all for the better. The many compatibility changes that we had the opportunity to make over the last 9 months will make Godot 3.0 more consistent and easy to use.

Still, as we often repeat it to newcomers, please continue using Godot 2.1.x until the 3.0 branch is ready - we speak a lot of compatibility changes but the workflow stays very similar, and the vast majority of what you will learn using Godot 2.1.x will be reusable 1:1 in the future branch. It will be the same engine, just better.

Okay, but when do we get the alpha build?

When it's ready™. There has been a lot of progress on many blocking bugs lately, which we track in a dedicated issue. We expect to be ready for an alpha release in ca. 2 weeks, so stay tuned :)

By then we will consider 3.0 feature complete, and we should stop breaking compatibility every other day. Count likely two months of testing and bugfixing and we should be ready to release the stable version, probably some time in August.

I have checked out in progress builds for Windows a few times in the last few weeks, and for me it’s been pretty much unplayable due to some OpenGL bugs, so hopefully the alphas become a bit more stable and I can get some hands on time soon.

GameDev News

12. June 2017

In their most recent release of 3ds Max, version 2018.1, Autodesk have launched a new VR focused feature with the name 3ds Max Interactive.  This is essentially a version of their Stingray Game engine, tuned for pre-visualization and VR work, instead of for games.  If you are interested in learning more about the Stingray game engine powering this feature, we featured it in the Closer Look game engine series last year.  You canimage learn more about the new VR functionality in 3ds Max on their home page.

Additionally, Autodesk have released a first look blog post discussing the new functionality.  One thing that is interesting to note from that discussion is, although this could be used for games, it’s actually intended for the visualization market.  Comments from the blog post:

Why add VR tools to Max when there are a lot of broadly adopted game engines out there? And why now? 

Here’s how we see it: when you’re trying to learn a new skill, it’s way easier to tackle if you have a familiar point of reference. Same deal here. We see the best path for arch viz VR as starting with the familiar language of Max, then easing into the less familiar territory and terminology of virtual reality – which is where Max Interactive comes in. It’s far less intimidating than being dropped in the middle of an unfamiliar game engine designed for game developers and trying to work your way back, or settling for an unknown set of 3D tools retrofit onto a VR game engine.

Could you use Max Interactive to build a VR game?

That’s a matter of “could” versus “should.” Sure, you could use Max and Max Interactive to build a game because the tools aren’t that different today. But over time, you’ll see Max Interactive evolve and adapt to the specific demands of design visualization in VR and AR. Meanwhile, game developers have already established their open workflows and pipelines based on Max and real-time engines like Unity and Unreal. We’re not trying to upend that. They’re just not optimized for architectural visualization workflows.

GameDev News

6. June 2017

Now that VR is here (and somewhat disappointing), the new hotness is AR, augmented reality.  Essentially AR is a blending of real world data, generally a live feed from a devices camera, with programmatic overlays.  Apple have jumped into the AR realm with the release of ARKit, an SDK for iOS devices running the upcoming iOS 11 operating system.  ARKit requires the devices to be running an A9 or A10 processor, either on iPad or iPhone devices.

In Apples’ own words, ARKit is:

iOS 11 introduces ARKit, a new framework that allows you to easily create unparalleled augmented reality experiences for iPhone and iPad. By blending digital objects and information with the environment around you, ARKit takes apps beyond the screen, freeing them to interact with the real world in entirely new ways.

ARKit can also be integrated in existing engines such as Unreal Engine or Unity.  A Unity plugin for ARKit is currently available here while Unreal support ARKit in the current Github build of the engine.  Unreal Engine and ARKit functionality was demonstrated in an example called Wingnut, demonstrated below.

The ARKit developer homepage is available here.

GameDev News

5. June 2017

Khronos Group, the consortium behind the OpenGL/Vulkan series of SDKS have just released the 2.0 specification for glTF.  glTF is an attempt to create a runtime friendly data format for 3D models with modern feature support.  Intended to replace such formats as COLLADA or FBX with a file format with modern features but streamlined for realtime usage.  It is a mix of JSON descriptor coupled with a binary format and various supported textures.  The 2.0 version aims to modernize the format, adding support for PBR (Physically Based Rendering) textures.

From the release announcement:

The release of glTF 2.0 delivers a significant upgrade to glTF 1.0, an extensible, runtime neutral, open standard format for real-time delivery of 3D assets, which describes full scenes with compact transmission and fast load time. In response to major functionality requests from the developer community using glTF 1.0, the release of glTF 2.0 adds Physically Based Rendering (PBR) for portable, consistent description of materials. In glTF 1.0, a material was defined with a GLSL shader, which suited WebGL, but was problematic when importing a glTF model into a Direct3D or Metal application. Through using PBR, visually arresting glTF 2.0 models are now consistently portable to any rendering API. A PBR material is defined by a few concise parameters that can be used to generate shaders for any rendering API. glTF 2.0 defines a simple to implement, but powerful, PBR model that provides high-quality materials, and yet, is scalable to suit the capabilities of different classes of platform and device.

For Blender users, there is a glTF exporter in the works available here.

GameDev News

Month List

Popular Comments