Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
2. April 2020


The Defold game engine is a free cross platform 2D focused game engine from King, we previously covered here and here as well as a video tutorial here.  The Defold team recently released an update on the future roadmap of the Defold game engine.

Details from the Defold blog broken down by engine category:

iOS

We will continue to keep the iOS platform support up to date with the latest iOS versions and requirements. Specific iOS tasks in no particular order:

Metal

Apple has announced that OpenGL will be deprecated on iOS and macOS, but no date has been announced. We have worked during 2019 to add a new Vulkan based graphics backend. This work is nearing completion and it will allow us to use MoltenVK on iOS and macOS. MoltenVK is a Vulkan Portability implementation. It layers a subset of the high-performance, industry-standard Vulkan graphics and compute API over Apple’s Metal graphics framework, enabling Vulkan applications to run on iOS and macOS. We have worked together with members of the Khronos Group to benchmark our implementation and have received only a few points of improvement.

Sign in with Apple

Apple will require that apps that authenticate or set up user accounts must support Sign in with Apple (SIWA). The deadline is June 30, 2020. We will release SIWA support through a native extension in Q2 of 2020. The extension has been developed at King and has already been tested in production.

Storyboard launch screens

Apple will require that apps use Xcode storyboards as the app’s launch screen. The deadline is June 30, 2020. We will automatically create a launch screen storyboard from the launch images set in game.project.

Android

We will continue to keep the Android platform support up to date with the latest Android requirements. We are collaborating with the Android and Google Play partnership teams to identify important tasks. The top four tasks in order of priority are:

Billing

Google Play Billing is a service that lets you sell digital content on Android. We will add support for the new Billing API via the existing IAP extension.

Google Play Game Services

We will continue to improve on the existing Google Play Game Services extension to ensure that it supports all of the latest features of Google Play Game Services.

Android App Bundles

Android App Bundle is a publishing format that includes all your app’s compiled code and resources, and defers APK generation and signing to Google Play. Google Play uses your app bundle to generate and serve optimized APKs for each device configuration, so only the code and resources that are needed for a specific device are downloaded to run your app. We will initially add support for basic bundling of applications using Android App Bundles and then expand upon the feature as needed.

Google Play Instant

Google Play Instant enables native games to launch on devices running Android 5.0 (API level 21) or higher without being installed. By allowing users to run an instant game, known as providing an instant experience, you improve your game’s discovery, which helps drive more active users or installations.

HTML5

We will focus on increased performance and reduced application size on HTML5. We will when possible update to newer versions of Emscripten and WebAssembly to achieve this.

Desktop

On desktop our only identified focus area is to add the ability to run the engine loop while the window is in the background.

Editor

We will mainly focus on performance and stability improvements in the editor. In terms of new features we have identified the following (in no particular order):

Improved 3D support

In 2019 we added support for perspective cameras and made some improvements to how collision shapes were visualised. These changes made it easier to work with and place 3D models in a collection, but there are still many improvements to be made to scene navigation when working in a 3D.

Auto-tiling

While we did some minor improvements to the tilemap system in 2019 (better tile palette and interleaved layers) we have so far left out auto-tiling. Auto-tiling can really speed up tilemap editing and it is the next big feature to add for the tilemap editor.

Editor extensions

We plan to expand the existing system for editor scripts to allow for more complex operations and we will look at how to customize the UI and/or add new UI widgets using editor scripts.

GUI layouts and templates

The system with GUI layouts and templates where one or both involve value overrides is fairly complex and hard to work with from a code maintenance perspective. We plan to review the system and possibly simplify it.

Engine

In 2019 we made several changes to improve editor stability. Two examples of this were reduced ANRs on Android and a standardized application loop on iOS. In 2020 we will continue to identify and fix stability issues in the engine. Besides stability improvements we will also work on the following features (in no particular order):

Sound threading

Sound playback is currently done on the main thread together with the rest of the game loop. This can become a problem if loading large resources while playing sound, resulting in playback stutter. The solution is to do sound playback on a separate thread to avoid stutter when loading content.

Physics decoupling

Physics is currently running at the same rate as the rest of the game loop. We will try to decouple the physics simulation from the game loop by running the simulation on a separate thread and optionally with a different number of updates per second.

Spine as an extension

We will look into the possibility of using the official Spine runtime as an extension and a replacement for the existing custom made native Spine support. This will allow the use of newer versions of Spine, something that currently is not possible with the existing and custom Spine runtime.

Physics as an extension

We will look into the possibility of moving the Box2D and Bullet3D physics engines to a native extension. This will allow the community to update or replace the physics simulation with an update version or completely different implementation.

Live update

We’re very happy to see that the live update functionality is used in several different scenarios (from Android Expansion Files to Steam DLCs). We have with the help of the community identified several improvements and we plan to deliver the most critical improvements in 2020.

Mesh component

The custom mesh component will be released in Q2 of 2020.

Vulkan

We will release support for Vulkan on all systems where it is supported. On Android it will be used by default on newer devices. On iOS it will be used under the hood to be able to use MoltenVK (see iOS above).

Build server

The Defold build server for native extensions will be open sourced in Q2 of 2020 to allow developers to build locally or set up their own build servers to cut the dependency to the Defold provided build service.

You can learn more about the Defold Game engine roadmap in the video below.  The tutorial mentioned in the video is open source and available here on Github.

GameDev News


14. February 2020


After several years of changing business models and ownership changes, Corona Labs have decided to shut things down.  Thankfully for Corona users they full open sourced the engine and tooling and changed to the MIT license.

Details of the closure process from the Corona Labs site (warning, it’s having trouble right now):

  1. Some of the Corona Labs staff have expressed an interest in continuing to work with Corona as an as-available hobby project, so some engine development will continue. There is a possibility that engineers would seek funding through platforms like Patreon or Github Sponsors to continue work in larger capacity.
  2. Appodeal will continue to fund infrastructure costs and work with the open source staff to keep the Appodeal plugin up to date.
  3. The Corona open source license will change from its current dual license state (Commercial + GPLv3) to a single, much more permissive license: The MIT License will make building the open source version of Corona easier for you and lift distribution restrictions on your apps and games. If you are using the GPL version of Corona, you can continue doing so in your fork.
  4. Corona Labs will remove Splash Screen restrictions and plugin license checks from Native and Simulator builds. All first-party plugins will be open sourced and be available on GitHub. Corona’s “daily” builds will be built using tools available for Open Source projects, and would be available on GitHub releases.
  5. We will change the Corona Simulator to be an offline tool, building for all supported platforms using local storage as a source for plugins.
  6. Marketplace sales will cease. Vendors will be paid what they are owed, and will have to distribute updates for their plugins themselves. Users will be able to download purchased plugins and assets before the store closure. Corona Labs will stop accepting new submissions to the Marketplace on February, 15. 2020. Self-hosted plugins will be turned on for everyone so community plugin developers can continue to provide plugins.
  7. We will migrate the forums and coronalabs.com website content to another platform, since the current setup is tied to an expensive infrastructure. We may need several community members to volunteer to administer the new Forums. We are still working on what the coronalabs.com website access will become.
  8. The community is welcome to spin up discussion forums. Possibilities include using GitHub’s Issues, Reddit’s /r/CoronaSDK page, a Facebook Group, etc. The community Slack will remain.
  9. The Corona Labs maintained social media accounts will remain open, and we will turn them into sources of useful information for developers (i.e., industry news, development and monetization tips, etc.).
  10. All these will not happen overnight. We are working on changes to the parts of the engine, and will release them gradually, moving the build process offline as well as migrating content to different platforms. We will post updates on the progress, as well as send out one more final email with all the details Feel free to follow Corona on Github or get involved in development. Progress will be reflected in this Github Project.

Learn more about the Corona Labs closure in the video below.

GameDev News


27. November 2019


I was just sent a Clockwork GameShell, it’s a build it yourself open source raspberry pi powered handheld computer.  What’s most appealling to me is how heavily focused on indie game developers this device is.  This is not a review of the device but instead a description of the build process (stay tuned for a proper review!).  So let’s take a look at the process from beginning to end and I’ll point out the few snags I encountered on the way.  If you are interested in getting one of your own, they are available on Amazon.

The underlying specs of hardware are as follows:

New ClockworkPi V3.1:Powered by Quad-core Cortex-A7 CPU, MaliGPU, Wi-Fi &Bluetooth, 1GB DDR3 Memory, 16GB MicroSD, HDMI output, GPIOs.

Keypad: Programmable Keypad and powered by an ATmega168P [email protected] with 30Pin Arduino compatibility GPIOs.

Audio: 2 Channel Stereo Speaker

Visual: 2.7-inch [email protected]

Rechargeable Battery: 3.7v, 1200mAh

Lightkey module: 5 independent IO extended keys for shoulder buttons

GameShell Shells: 1 front shell+2 back shells

MicroSD Card: 16GB

OS: ClockworkPi OS,Linux  4.1x

Debug cable: 14PIN GPIOs

Let’s look at what you get and how you assemble it.


The Box


This is a extremely minor point, but I was quite impressed with the packaging the GameShell came in.  Right away it’s generally just a higher quality of packaging and branding than I am accustomed to for these kinds of products, it does have a premium feeling as a result. Click any photo for a much higher resolution version.


IMG_20191127_112001IMG_20191127_112020



The Contents

The inside of the box is several other boxes and a collection of plastic punch out components.  In terms of equipment you need to do this build you are going to want a sharp knife at the very least.  A fine file and pair of side cutters to remove the plastic attachments are also recommended, but I got by with just a knife.


IMG_20191127_112146IMG_20191127_113033

Assembly

Now it’s time to start putting things together.  The instructions are IKEA style (but thankfully better than most IKEA!) step by step pictographic instructions.  The assembly is module by module.  The primary modules are the screen, the battery, the main system board and the controller as well as the speaker (not shown).

IMG_20191127_121439IMG_20191127_114819

IMG_20191127_115734IMG_20191127_121145

Once these 5 modules are completed, its its time to mount the modules into the backplate and connect the various power wires between the devices.  This is probably the trickiest part with one exception I will discuss in a minute.

IMG_20191127_125731

Finally it’s a matter of attaching the front plate, attaching two thumb screws and praying you did everything right.  And the final completed product!

IMG_20191127_130514

The Gotchas

Assembly was extremely straight forward with only two snags.  The first step is when creating the display module illustrated below.

ScreenStep

Notice the inset diagram shows the cable being bent backwards, while the layer diagram does not show this?  This is vitally important, you do in fact have to bend the display cable 180 degrees.

The second problem is actually around the same issue.  Connecting the display ribbon cable to the main board should be done *BEFORE* you close the case around it, making it insanely difficult connect unless you open it.

The only other issue I ran into is occasionally they mounted the plastic pieces to the plastic frame at less than ideal locations.  For example there was a mount point where the display cable needs to be fed.  I had to make a special point of filing down the excess plastic to keep it from rubbing against or puncturing the fragile ribbon cable.  It would be ideal if pieces were mounted slightly different, but its a small issue.



Now that I have the GameShell built, it’s time to start trying to develop games for it.  Stay tuned for that video in the near future.

General


17. June 2019


The nCine Engine is a C++ powered, open source MIT licensed 2D game engine that has been under development for over 7 years.  It is a lower level code based framework, although it does support Lua scripting out of the box.  The engine also integrates the ImGui framework making creating tools and UIs a breeze.  The nCine engine works on Windows, Linux, Mac and Android.

Highlighted features include:

  • ImGui debug overlay and profilers
  • Lua integration for scripting
  • OPenGL 3.3/OpenGL ES 3.0
  • Spritesheet based animated sprites
  • Scengraph based transformations
  • Particle simulation with affectors
  • Sound and music playback
  • Text rendering with kerning
  • Support for multiple texture formats
  • Profiler graphs and statistics
  • Works on multiple platforms
  • Template containers and algorithms
  • Fully C++11 compliant codebase
  • High precision monotonic timers
  • Atomic counters
  • Thread pool creation, synchronization and affinity assignment
  • Basic math lbrary for vectors, 4x4 matrices and quaternions
  • Logging system with multiple levels and console or file output
  • GLFW 3 or SDL 2 for window and input on PC
  • Joystick support with hot swap and gamepad mappings
  • Android assets support
  • Google Test based unit tests with coverage checked with Gcovr
  • Microbenchmarked with the Google Benchmark support library
  • Doxygen based documentation with Graphviz class diagrams
  • Periodically checked with Cppcheck and Valgrind
  • Periodically linted with clang-format (previously with Artistic Style and Uncrustify)
  • Instrumentation for the Tracy frame profiler

With so many game engines on the market, you may be wondering… why another one?  Well the author explains exactly that right here.  The cCine project is hosted on GitHub and provides a Pong demo to get you started, implemented in both C++ and Lua.

GameDev News Programming


13. March 2019


Just 7 years after doing our Battle of the Lua Game Engines comparison between Gideros, Corona, Love and MOAI, we have finally done a hands-on review of the Gideros game engine.  A lot has changed in 7 years, including the fact that Gideros is now free and open source, available on GitHub.  It is a well documented, cross platform (Windows, Mac, Linux, Pi) 2D game engine capable of targeting all those platforms as well as the most popular mobile platforms including iOS and Android.  One of the biggest strengths of Gideros is it’s Player application, enabling real-time testing over Wi-Fi, vastly improving the testing and deployment phases.

Thankfully you do not have to build Gideros from source, with downloadable installers available here.  In addition to Gideros, I highly recommend you check out ZeroBrane Studio for a superior Lua development experience.

The following video shows Gideros Studio in action:


The code we created in the video above was:

local font = TTFont.new("Roboto.ttf", 64)
local text = TextField.new(font,"Hello Cruel World!")
text:setPosition(application:getContentWidth()/2,application:getContentHeight()/2)

stage:addChild(text)

function mainLoop()
	local x,y,z = text:getPosition()
	text:setPosition(x,y+1)
	text:setTextColor(0xff0000)
end

stage:addEventListener(Event.ENTER_FRAME, mainLoop)
You need to place a font named Roboto.ttf (or any ttf font, just change the parameter in the first line of code if you substitute your own font) in your assets directory for this to run.

If Gideros doesn’t appeal to you, but you are still interested in a Lua based game engine, be sure to check out our Love/Lua tutorial series available here.

Programming


AppGameKit Studio

See More Tutorials on DevGa.me!

Month List