Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
17. January 2020


JetBrains, the makers of programmer tools such as IntelliJ, WebStorm, CLion and Rider, as well as the programming language Kotlin have been working on a font specifically designed for code.  JetBrains Mono is an open source font family consisting of 8 fonts specifically designed with reading and writing code in mind.

Details from the JetBrains blog:

For the most part of our day we, as developers, look at the code. And it is no wonder that we are always on the lookout for the best font to make looking at the text on the screen easier on our eyes. However, the logic in many popular fonts does not always take into account the difference between reading through code and reading a book. Our eyes move along code in a very different way, often having to move vertically as often as they do horizontally, which is opposed to reading a book where they slide along the text always in the same direction.

Therefore, while working on JetBrains Mono we focused, among other things, on the issues that can cause eye fatigue during long sessions of working with code. We have considered things like the size and shape of letters; the amount of space between them, a balance naturally engineered in monospace fonts; unnecessary details and unclear distinctions between symbols, such as I’s and l’s for example; and programming ligatures when developing our font.

Today, we proudly present JetBrains Mono – a new open-source typeface specifically made for developers. Check out what makes JetBrains Mono unique in the big family of monospaced fonts and try it in your favorite code editor. Have a look at JetBrains Mono, your eyes will thank you for it.

More details about Mono are available here.  It is the default font on all 2020 JetBrains IDEs and is available as an option in version 2019.3 and beyond of all JetBrain products.  If you use another IDE you can download the zip here.  Learn more about JetBrains Mono, including how to install and configure in Visual Studio Code in the video below.

Programming GameDev News


10. January 2020


ArmorPaint is an open source competitor to Substance Painter, from the creator of the Armory game engine (tutorial series available here).  It is available for just 16 Euro in binary form, but can also be built from source code.  This guide walks you step by step through the process of building ArmorPaint from source.

There are a few requirements before you can build.  Download and install the following programs if not already installed:

First step, we clone the repository.  Make sure to add the –recursive flag(that’s two ‘-‘ by the way).

Open a command prompt, cd to the directory where you want to install ArmorPaint’s source code and run the command:

git clone –recursive https://github.com/armory3d/armorpaint.git

Depending on your internet speed this could take a minute to several minutes while all of the files are downloaded. 

In Explorer, go the installation directory, then navigate to armorpaint\Kromx\V8\Libraries\win32\release and using 7zip extract v8_monolith.7z to the same directory as the .7z file.

Next in the command prompt run the following commands

(Assuming you are reusing the same CMD that you did the git clone from)

cd armorpaint

node Kromx/make –g direct3d11

cd Kromx

node Kinc/make –g direct3d11

explorer .

If you receive any errors above, the most likely cause is node not being installed.  The final command will now open a Windows Explorer window in the Kromx subdirectory.  Open the build directory and load the file Krom.sln.

image

This will open the project in Visual Studio.  If you haven’t run VS yet,you may have to do some initial installation steps.  Worst case scenario run through the initial install, close and double click Krom.sln again.

First make sure that you are building for x64 and Release mode at the top:

image

In the Solution Explorer, select Krom then hit ALT + ENTER or right click and select Properties.

Then select Debugging, in Command Arguments enter ..\..\build.krom then click Apply.

image

You are now ready to build ArmorPaint.  Select Ctrl + SHIFT + B or select Build->Build Solution.

image

Assuming no errors, are exe should be built.  Now go to the folder armorpaint\Kromx\build\x64\Release and copy the file Krom.exe, then copy to armorpaint\build\krom.  You can now run Krom.exe and you’re good to go. 

image

Step by step instructions are available in the video below.

Art Programming


26. November 2019

.

This is a very common question, so this guide and video is setting out to answer why *I* might choose to use Godot over those other engines. Keep in mind, this isn’t me saying Godot is better or worse than those engines. Additionally, I have a video on Unreal vs Unity in the works, so if you want to decide which of those engines to use, stay tuned for that.

Without further ado, let’s jump in.

Free

Obviously, the lack of a price tag is one of the most obvious features of Godot. Yes, you can start for free with both Unity and Unreal Engine, but both ultimately have a price tag. With Unity, you pay a per seat license fee if you make over 100K a year. With Unreal Engine you pay a fixed 5% royalty after the first $3000 dollars earned. If you’re not making money nor plan to, this obviously doesn’t matter… but the more successful your game is, the better a deal free is!

Open Source

On the topic of free, we also have free as in freedom. Godot is free in both regards, to price tag and license, being licensed under the MIT license. Unity trails in this regard having only select subsets of the code available. Unreal Engine has the source code available and you can completely build the engine from scratch, as well as being able to fix problems yourself by walking through a debug build and applying fixes.

UE4 however is under a more restrictive proprietary license, while Godot is under the incredibly flexible and permissive code license.

Another aspect in Godot’s favor… it’s also by far the smallest code base and very modular in design from a code perspective. This makes it among the easiest engines to contribute code to. The learning curve to understand the source code is a fraction of that to get started contributing to Unreal, while contributing to Unity is frankly impossible without a very expensive negotiated source license.

Language Flexibility

Over the years Unity have *REMOVED* language support. Once there was UnityScript and Boo, a python like language, in addition to C#. Now it’s pretty much just C# and their in development visual scripting language.

Unreal on the other hand has C++ support, with the C++ thanks to Live++ usable very much like a scripting language (although final build times are by far the worst of all 3 engines!), as well as the (IMHO) single best visual programming language available, Blueprints.

For Godot the options are much more robust. First off there is the Python-lite scripting language, GDScript. You can also use C++, although the workflow for gameplay programming may be suboptimal. Additionally, C# support is being added as a first-class language and there is a visual programming language available here as well, although I can’t really think of a reason to use it as it stands now.

Where Godot really shines though is its modularity. GDScript itself is implemented as a module, meaning making other custom scripting languages is a borderline trivial task, as is extending or customizing GDScript. Additionally, there is GDNative/NativeScript it makes it fairly simple to link to external code, without having to jump into the guts of Godot (nor having to compile Godot) or to write performance critical code in C or C++. Finally, you have the ability to create C++ “modules” that have access to all of the C++ classes available in Godot without having to make changes to the underlying codebase.

Ease of Use

This one is obviously subjective, but if you are looking to create a game, especially as a beginner, the learning curve and ease of use with GDScript make this the easiest of the 3 engines to pick up, at least in my opinion. Unreal Engine is frankly fairly appalling for 2D titles, having basically abandoned Paper2D (their 2D API) on the vine. Over the last couple years Unity have really been focusing heavier on dedicated 2D support, but you still must dig through a lot of cruft and overhead to get to the meat of your game.

With Godot you pretty much everything you need for 2D out of the box and the ability to work directly with pixel (or % based) coordinates.

It’s Tiny

Unreal and Unity are multi GB installs and both have a hub or launcher app. Godot… a 50ish MB zip file (plus templates for a couple hundred more MB needed when deploying). Download, unzip and start game development!

You Like it Better?

You may, or you may not like the coding model of Godot. Chances are if you like the Node based approach to game development, you will love Godot. All three game engines (and almost all modern game engines) take a composition-based approach to scene modeling. Godot takes it one step further, making everything nodes, trees of nodes, even scenes are simply nodes. The approach is different enough that users may either love or hate the approach. If you love the approach Godot takes, you will be productive in it. If you don’t like it, you’re probably better served using Unity or Unreal.

Why Not Pick Godot Then?

I am not even going to pretend that Godot is the perfect game engine and ideal in every situation… there are certainly areas where Unity and Unreal have a small to huge advantage. This could be its own entire video, but a quick list include:

  • Performance concerns, especially on large 3D scenes (hopefully resolved with proper culling and the upcoming Vulkan renderer). In 3D, both engines out perform Godot quite often
  • Platforms… Unity and Unreal support every single platform you can imagine, Godot supports most of the common consumer categories and takes longer to get support for devices like AR/VR. Hardware manufacturers work with Unity and Epic from the design stages, while Godot pretty much must wait for hardware to come to market and then for someone to implement it. Another huge difference, and one of the few downsides to open source software, it isn’t compatible with the closed proprietary licenses of console hardware. While Godot has been ported to run on console hardware, it isn’t supported out of the box and probably never will be.
  • Ecosystem. Godot has a vibrant community but can’t hold a candle to the ecosystem around Unreal and especially Unity. There are simply more users, more books, larger asset stores, etc.
  • The resume factor… this is a part of ecosystem continued. It’s easier to get a job with Unity experience or Unreal experience on the resume than Godot. While many people wouldn’t (and really for a full-time hire, shouldn’t) care what engine you use, when people are hunting for employees, they often look for Unity or UE experience specifically. The other side of this coin is the number of people with Unity or UE experience is larger if you are the one doing the hiring.
  • As with many open source projects, it’s still heavily dependent on one or two key developers. If the leads left the project, it would be a massive blow to the future of Godot. Meanwhile there are hundred or thousands of people being paid to develop Unity or Unreal and the departure of any individual member isn’t likely to have a tangible impact.

The Longer Video Version

Programming General


10. November 2019


Every year GitHub release their State of the Octoverse report containing a huge number of insights drawn from datamining the massive number of public and private repositories on GitHub.  One of the most interesting parts of the report is always the most popular programming languages.  This year, the 10 most popular programming languages on GitHub are:

  1. JavaScript
  2. Python
  3. Java
  4. PHP
  5. C#
  6. C++
  7. TypeScript
  8. Shell
  9. C
  10. Ruby


The list was created using the following criteria:

Top 10 primary languages over time, ranked by number of unique contributors to public and private repositories tagged with the appropriate primary language.

Every year Stack Overflow have a similar report, drawn instead from a developer survey.  The language popularity reports are remarkably consistent between the two 2019 reports.

You can learn more about the reports watching the video below.

GameDev News Programming


1. November 2019


The Khronos Group have just released the Vulkan Unified Samples Repository, a single location for the best tutorials and code samples for learning and using the Vulkan API.

Details from the Khronos blog:

Today, The Khronos® Group releases the Vulkan ® Unified Samples Repository, a new central location where anyone can access Khronos-reviewed, high-quality Vulkan code samples in order to make development easier and more streamlined for all abilities. Khronos and its members, in collaboration with external contributors, created the Vulkan Unified Samples Project in response to user demand for more accessible resources and best practices for developing with Vulkan. Within Khronos, the Vulkan Working Group discovered that there were many useful and high-quality samples available already (both from members and external contributors), but they were not all in one central location. Additionally, there was no top-level review of all the samples for interoperability or compatibility. This new repository project was created to solve this challenge by putting resources in one place, ensuring samples are reviewed and maintained by Khronos. They are then organized into a central library available for developers of all abilities to use, learn from, and gain ideas.

The first group of samples includes a generous donation of performance-based samples and best practice documents from Khronos member, Arm.

The repository is hosted entirely on GitHub under the Apache 2.0 source license.  The code samples are located here.

You can learn more in the video below.

GameDev News Programming


AppGameKit Studio

See More Tutorials on DevGa.me!

Month List