Tag: news

Posted on by — Leave a comment

Unreal Engine 4.26 Water Simulation

Previously expected in Unreal Engine 4.26 Preview 1, the new experimental water simulation system from Fortnite has finally shipped in Unreal Engine 4.26 preview 3. The new water simulation system enables you to quick create realistic and highly configurable water simulations, including oceans, lakes and rivers. Of course the key word is experimental, this is a feature that is nowhere near ready for prime time.

You can see a quick preview of the water system in action in the video below. Given the fact that there currently exists no documentation and it seems several of the features are currently broken, the video by no means showcases all of the new fluid simulation systems capabilities. Currently the only information available on how to use the new system come in the 2 1/2 Epic Games livestream available here. While early on, the new system does seem incredibly promising. For now however, the UIWS, or Unified Interactive Water System from the September monthly UE4 giveaway is most likely a better choice.

[youtube https://www.youtube.com/watch?v=TTHcyOykGeQ?feature=oembed&w=1500&h=844]
Posted on by — Leave a comment

systemd-resolved: introduction to split DNS

Fedora 33 switches the default DNS resolver to systemd-resolved. In simple terms, this means that systemd-resolved will run as a daemon. All programs wanting to translate domain names to network addresses will talk to it. This replaces the current default lookup mechanism where each program individually talks to remote servers and there is no shared cache.

If necessary, systemd-resolved will contact remote DNS servers. systemd-resolved is a “stub resolver”—it doesn’t resolve all names itself (by starting at the root of the DNS hierarchy and going down label by label), but forwards the queries to a remote server.

A single daemon handling name lookups provides significant benefits. The daemon caches answers, which speeds answers for frequently used names. The daemon remembers which servers are non-responsive, while previously each program would have to figure this out on its own after a timeout. Individual programs only talk to the daemon over a local transport and are more isolated from the network. The daemon supports fancy rules which specify which name servers should be used for which domain names—in fact, the rest of this article is about those rules.

Split DNS

Consider the scenario of a machine that is connected to two semi-trusted networks (wifi and ethernet), and also has a VPN connection to your employer. Each of those three connections has its own network interface in the kernel. And there are multiple name servers: one from a DHCP lease from the wifi hotspot, two specified by the VPN and controlled by your employer, plus some additional manually-configured name servers. Routing is the process of deciding which servers to ask for a given domain name. Do not mistake this with the process of deciding where to send network packets, which is called routing too.

The network interface is king in systemd-resolved. systemd-resolved first picks one or more interfaces which are appropriate for a given name, and then queries one of the name servers attached to that interface. This is known as “split DNS”.

There are two flavors of domains attached to a network interface: routing domains and search domains. They both specify that the given domain and any subdomains are appropriate for that interface. Search domains have the additional function that single-label names are suffixed with that search domain before being resolved. For example, a lookup for “server” is treated as a lookup for “server.example.com” if the search domain is “example.com.” In systemd-resolved config files, routing domains are prefixed with the tilde (~) character.

Specific example

Now consider a specific example: your VPN interface tun0 has a search domain private.company.com and a routing domain ~company.com. If you ask for mail.private.company.com, it is matched by both domains, so this name would be routed to tun0.

A request for www.company.com is matched by the second domain and would also go to tun0. If you ask for www, (in other words, if you specify a single-label name without any dots), the difference between routing and search domains comes into play. systemd-resolved attempts to combine the single-label name with the search domain and tries to resolve www.private.company.com on tun0.

If you have multiple interfaces with search domains, single-label names are suffixed with all search domains and resolved in parallel. For multi-label names, no suffixing is done; search and routing domains are are used to route the name to the appropriate interface. The longest match wins. When there are multiple matches of the same length on different interfaces, they are resolved in parallel.

A special case is when an interface has a routing domain ~. (a tilde for a routing domain and a dot for the root DNS label). Such an interface always matches any names, but with the shortest possible length. Any interface with a matching search or routing domain has higher priority, but the interface with ~. is used for all other names. Finally, if no routing or search domains matched, the name is routed to all interfaces that have at least one name server attached.

Lookup routing in systemd-resolved

Domain routing

This seems fairly complex, partially because of the historic names which are confusing. In actual practice it’s not as complicated as it seems.

To introspect a running system, use the resolvectl domain command. For example:

$ resolvectl domain
Global:
Link 4 (wlp4s0): ~.
Link 18 (hub0): 
Link 26 (tun0): redhat.com

You can see that www would resolve as www.redhat.com. over tun0. Anything ending with redhat.com resolves over tun0. Everything else would resolve over wlp4s0 (the wireless interface). In particular, a multi-label name like www.foobar would resolve over wlp4s0, and most likely fail because there is no foobar top-level domain (yet).

Server routing

Now that you know which interface or interfaces should be queried, the server or servers to query are easy to determine. Each interface has one or more name servers configured. systemd-resolved will send queries to the first of those. If the server is offline and the request times out or if the server sends a syntactically-invalid answer (which shouldn’t happen with “normal” queries, but often becomes an issue when DNSSEC is enabled), systemd-resolved switches to the next server on the list. It will use that second server as long as it keeps responding. All servers are used in a round-robin rotation.

To introspect a running system, use the resolvectl dns command:

$ resolvectl dns
Global:
Link 4 (wlp4s0): 192.168.1.1 8.8.4.4 8.8.8.8
Link 18 (hub0):
Link 26 (tun0): 10.45.248.15 10.38.5.26

When combined with the previous listing, you know that for www.redhat.com, systemd-resolved will query 10.45.248.15, and—if it doesn’t respond—10.38.5.26. For www.google.com, systemd-resolved will query 192.168.1.1 or the two Google servers 8.8.4.4 and 8.8.8.8.

Differences from nss-dns

Before going further detail, you may ask how this differs from the previous default implementation (nss-dns). With nss-dns there is just one global list of up to three name servers and a global list of search domains (specified as nameserver and search in /etc/resolv.conf).

Each name to query is sent to the first name server. If it doesn’t respond, the same query is sent to the second name server, and so on. systemd-resolved implements split-DNS and remembers which servers are currently considered active.

For single-label names, the query is performed with each of the the search domains suffixed. This is the same with systemd-resolved. For multi-label names, a query for the unsuffixed name is performed first, and if that fails, a query for the name suffixed by each of the search domains in turn is performed. systemd-resolved doesn’t do that last step; it only suffixes single-label names.

A second difference is that with nss-dns, this module is loaded into each process. The process itself communicates with remote servers and implements the full DNS stack internally. With systemd-resolved, the nss-resolve module is loaded into the process, but it only forwards the query to systemd-resolved over a local transport (D-Bus) and doesn’t do any work itself. The systemd-resolved process is heavily sandboxed using systemd service features.

The third difference is that with systemd-resolved all state is dynamic and can be queried and updated using D-Bus calls. This allows very strong integration with other daemons or graphical interfaces.

Configuring systemd-resolved

So far, this article talked about servers and the routing of domains without explaining how to configure them. systemd-resolved has a configuration file (/etc/systemd/resolv.conf) where you specify name servers with DNS= and routing or search domains with Domains= (routing domains with ~, search domains without). This corresponds to the Global: lists in the two listings above.

In this article’s examples, both lists are empty. Most of the time configuration is attached to specific interfaces, and “global” configuration is not very useful. Interfaces come and go and it isn’t terribly smart to contact servers on an interface which is down. As soon as you create a VPN connection, you want to use the servers configured for that connection to resolve names, and as soon as the connection goes down, you want to stop.

How does then systemd-resolved acquire the configuration for each interface? This happens dynamically, with the network management service pushing this configuration over D-Bus into systemd-resolved. The default in Fedora is NetworkManager and it has very good integration with systemd-resolved. Alternatives like systemd’s own systemd-networkd implement similar functionality. But the interface is open and other programs can do the appropriate D-Bus calls.

Alternatively, resolvectl can be used for this (it is just a wrapper around the D-Bus API). Finally, resolvconf provides similar functionality in a form compatible with a tool in Debian with the same name.

Scenario: Local connection more trusted than VPN

The important thing is that in the common scenario, systemd-resolved follows the configuration specified by other tools, in particular NetworkManager. So to understand how systemd-resolved names, you need to see what NetworkManager tells it to do. Normally NM will tell systemd-resolved to use the name servers and search domains received in a DHCP lease on some interface. For example, look at the source of configuration for the two listings shown above:

There are two connections: “Parkinson” wifi and “Brno (BRQ)” VPN. In the first panel DNS:Automatic is enabled, which means that the DNS server received as part of the DHCP lease (192.168.1.1) is passed to systemd-resolved. Additionally. 8.8.4.4 and 8.8.8.8 are listed as alternative name servers. This configuration is useful if you want to resolve the names of other machines in the local network, which 192.168.1.1 provides. Unfortunately the hotspot DNS server occasionally gets stuck, and the other two servers provide backup when that happens.

The second panel is similar, but doesn’t provide any special configuration. NetworkManager combines routing domains for a given connection from DHCP, SLAAC RDNSS, and VPN, and finally manual configuration and forward this to systemd-resolved. This is the source of the search domain redhat.com in the listing above.

There is an important difference between the two interfaces though: in the second panel, “Use this connection only for resources on its network” is checked. This tells NetworkManager to tell systemd-resolved to only use this interface for names under the search domain received as part of the lease (Link 26 (tun0): redhat.com in the first listing above). In the first panel, this checkbox is unchecked, and NetworkManager tells systemd-resolved to use this interface for all other names (Link 4 (wlp4s0): ~.). This effectively means that the wireless connection is more trusted.

Scenario: VPN more trusted than local network

In a different scenario, a VPN would be more trusted than the local network and the domain routing configuration reversed. If a VPN without “Use this connection only for resources on its network” is active, NetworkManager tells systemd-resolved to attach the default routing domain to this interface. After unchecking the checkbox and restarting the VPN connection:

$ resolvectl domain
Global:
Link 4 (wlp4s0):
Link 18 (hub0):
Link 28 (tun0): ~. redhat.com
$ resolvectl dns
Global:
Link 4 (wlp4s0):
Link 18 (hub0):
Link 28 (tun0): 10.45.248.15 10.38.5.26

Now all domain names are routed to the VPN. The network management daemon controls systemd-resolved and the user controls the network management daemon.

Additional systemd-resolved functionality

As mentioned before, systemd-resolved provides a common name lookup mechanism for all programs running on the machine. Right now the effect is limited: shared resolver and cache and split DNS (the lookup routing logic described above). systemd-resolved provides additional resolution mechanisms beyond the traditional unicast DNS. These are the local resolution protocols MulticastDNS and LLMNR, and an additional remote transport DNS-over-TLS.

Fedora 33 does not enable MulticastDNS and DNS-over-TLS in systemd-resolved. MulticastDNS is implemented by nss-mdns4_minimal and Avahi. Future Fedora releases may enable these as the upstream project improves support.

Implementing this all in a single daemon which has runtime state allows smart behaviour: DNS-over-TLS may be enabled in opportunistic mode, with automatic fallback to classic DNS if the remote server does not support it. Without the daemon which can contain complex logic and runtime state this would be much harder. When enabled, those additional features will apply to all programs on the system.

There is more to systemd-resolved: in particular LLMNR and DNSSEC, which only received brief mention here. A future article will explore those subjects.

Posted on by — Leave a comment

Cocos Creator 3.0 Tech Preview Released

The free Cocos Creator game engine just got a heavy duty upgrade today, with the release of Cocos Creator 3D technical preview. This release adds an all new 3D game engine to Cocos Creator, which was previously a 2D only game engine. The new underlying 3D engine has a complete PBR based rendering workflow based on real world lighting and camera models, with a modular design with support for terrain and physics out of the box.

Details from the Cocos Blog:

The technology behind games has grown exponentially since the birth of video games. Today with the creation of cloud computing, 5G networks, and faster mobile computers, the revolution to bring better 3D titles to your hands has become overwhelmingly apparent to game developers.

The Cocos engine started as a 2D game engine. In Cocos2d-x, we built the best open-source 2D engine in the world. We also tried to build 3D features upon the 2D-oriented architecture. But due to the lack of an editor and the challenge of growth on 3D features, it wasn’t very successful. That’s why we were determined to build an excellent editor tool: Cocos Creator. It was initially for 2D game development. But since 2017, we have already started to build a pure 3D engine for this tool. To push ourselves to give developers the best 3D development tool, we have re-designed the whole engine architecture and updated the editor’s core. On October 15th, 2019, we released Cocos Creator 3D, a dedicated experimental branch of China’s product. With a whole year’s effort, we have greatly improved the 3D engine architecture. We are finally merging the experimental 3D branch into the main Cocos Creator product to forge the awesome Cocos Creator 3.0, released later this year.

You can download Cocos Creator 3.0 preview for Windows and Mac now. Do be aware however there are a few caveats, especially for existing Cocos Creator developers:

  1. Projects built in Cocos Creator 1.X – 2.X will not work with this demo.
  2. Only 3D projects are available in this demo. Some 2D features like Spine, Tiled map, etc. are absent in this demo, but they will be included in the official 3.0 version.
  3. All projects built in the demo are exportable to 3.0 when it is released. So go crazy!
  4. We only recommend using TypeScript for future Cocos Creator 3.0 projects.

If you are interested in learning about Cocos Creator in general we have a tutorial series available on DevGa.me. You can see the new Cocos Creator 3.0 tech preview in action in the video below. A good place to start is the Cocos examples project available on GitHub. If you want to test Cocos Creator 3.0 using the same model as in the video, that model is available for free here on Sketchfab.

[youtube https://www.youtube.com/watch?v=1z42BdkMT3E?feature=oembed&w=1500&h=844]
Posted on by — Leave a comment

Godot 4 Sneak Peek: Particle Systems

Recently discussed on the Godot website, several new features have been added to the Godot 4 GPU accelerated particle systems. New features include:

  • support for sub-emitters
  • new collision systems
    • box and sphere colliders
    • height map colliders for outdoor maps
    • SDF colliders for internal meshes
  • new particle attractors

While we are going to have to wait until Godot 4 to get our hands-on the new Godot 4 in a production environment, we can check out the new GPUParticles3D node in action by building from the nightly source. That is exactly what we did in the video below, check it out for a preview and a mini tutorial on using particles in Godot 4.

[youtube https://www.youtube.com/watch?v=X8wNi6MX9mc?feature=oembed&w=1500&h=844]
Posted on by — Leave a comment

Web of Trust, Part 1: Concept

Every day we rely on technologies who nobody can fully understand. Since well before the industrial revolution, complex and challenging tasks required an approach that broke out the different parts into smaller scale tasks. Each resulting in specialized knowledge used in some parts of our lives, leaving other parts to trust in skills that others had learned. This shared knowledge approach also applies to software. Even the most avid readers of this magazine, will likely not compile and validate every piece of code they run. This is simply because the world of computers is itself also too big for one person to grasp.

Still, even though it is nearly impossible to understand everything that happens within your PC when you are using it, that does not leave you blind and unprotected. FLOSS software shares trust, giving protection to all users, even if individual users can’t grasp all parts in the system. This multi-part article will discuss how this ‘Web of Trust’ works and how you can get involved.

But first we’ll have to take a step back and discuss the basic concepts, before we can delve into the details and the web. Also, a note before we start, security is not just about viruses and malware. Security also includes your privacy, your economic stability and your technological independence.

One-Way System

By their design, computers can only work and function in the most rudimentary ways of logic: True or false. And or Or. This (boolean logic) is not readily accessible to humans, therefore we must do something special. We write applications in a code that we can (reasonably) comprehend (human readable). Once completed, we turn this human readable code into a code that the computer can comprehend (machine code).

The step of conversion is called compilation and/or building, and it’s a one-way process. Compiled code (machine code) is not really understandable by humans, and it takes special tools to study in detail. You can understand small chunks, but on the whole, an entire application becomes a black box.

This subtle difference shifts power. Power, in this case being the influence of one person over another person. The person who has written the human-readable version of the application and then releases it as compiled code to use by others, knows all about what the code does, while the end user knows a very limited scope. When using (software) in compiled form, it is impossible to know for certain what an application is intended to do, unless the original human readable code can be viewed.

The Nature of Power

Spearheaded by Richard Stallman, this shift of power became a point of concern. This discussion started in the 1980s, for this was the time that computers left the world of academia and research, and entered the world of commerce and consumers. Suddenly, that power became a source of control and exploitation.

One way to combat this imbalance of power, was with the concept of FLOSS software. FLOSS Software is built on 4-Freedoms, which gives you a wide array of other ‘affiliated’ rights and guarantees. In essence, FLOSS software uses copyright-licensing as a form of moral contract, that forces software developers not to leverage the one-way power against their users. The principle way of doing this, is with the the GNU General Public Licenses, which Richard Stallman created and has since been promoting.

One of those guarantees, is that you can see the code that should be running on your device. When you get a device using FLOSS software, then the manufacturer should provide you the code that the device is using, as well as all instructions that you need to compile that code yourself. Then you can replace the code on the device with the version you can compile yourself. Even better, if you compare the version you have with the version on the device, you can see if the device manufacturer tried to cheat you or other customers.

This is where the web of Trust comes back into the picture. The Web of Trust implies that even if the vast majority of people can’t validate the workings of a device, that others can do so on their behalf. Journalists, security analysts and hobbyists, can do the work that others might be unable to do. And if they find something, they have the power to share their findings.

Security by Blind Trust

This is of course, if the application and all components underneath it, are FLOSS. Proprietary software, or even software which is merely Open Source, has compiled versions that nobody can recreate and validate. Thus, you can never truly know if that software is secure. It might have a backdoor, it might sell your personal data, or it might be pushing a closed ecosystem to create a vendor-lock. With closed-source software, your security is as good as the company making the software is trustworthy.

For companies and developers, this actually creates another snare. While you might still care about your users and their security, you’re a liability: If a criminal can get to your official builds or supply-chain, then there is no way for anybody to discover that afterwards. An increasing number of attacks do not target users directly, but instead try to get in, by exploiting the trust the companies/developers have carefully grown.

You should also not underestimate pressure from outside: Governments can ask you to ignore a vulnerability, or they might even demand cooperation. Investment firms or shareholders, may also insist that you create a vendor-lock for future use. The blind trust that you demand of your users, can be used against you.

Security by a Web of Trust

If you are a user, FLOSS software is good because others can warn you when they find suspicious elements. You can use any FLOSS device with minimal economic risk, and there are many FLOSS developers who care for your privacy. Even if the details are beyond you, there are rules in place to facilitate trust.

If you are a tinkerer, FLOSS is good because with a little extra work, you can check the promises of others. You can warn people when something goes wrong, and you can validate the warnings of others. You’re also able to check individual parts in a larger picture. The libraries used by FLOSS applications, are also open for review: It’s “Trust all the way down”.

For companies and developers, FLOSS is also a great reassurance that your trust can’t be easily subverted. If malicious actors wish to attack your users, then any irregularity can quickly be spotted. Last but not least, since you also stand to defend your customers economic well-being and privacy, you can use that as an important selling point to customers who care about their own security.

Fedora’s case

Fedora embraces the concept of FLOSS and it stands strong to defend it. There are comprehensive legal guidelines, and Fedora’s principles are directly referencing the 4-Freedoms: Freedom, Friends, Features, and First

Fedora's Foundation logo, with Freedom highlighted. Illustrative.

To this end, entire systems have been set up to facilitate this kind of security. Fedora works completely in the open, and any user can check the official servers. Koji is the name of the Fedora Buildsystem, and you can see every application and it’s build logs there. For added security, there is also Bohdi, which orchestrates the deployment of an application. Multiple people must approve it, before the application can become available.

This creates the Web of Trust on which you can rely. Every package in the repository goes through the same process, and at every point somebody can intervene. There are also escalation systems in place to report issues, so that issues can quickly be tackled when they occur. Individual contributors also know that they can be reviewed at every time, which itself is already enough of a precaution to dissuade mischievous thoughts.

You don’t have to trust Fedora (implicitly), you can get something better; trust in users like you.

Posted on by — Leave a comment

Oculus Quest 2 Game Development Options

October 13th is the official launch date of the Oculus Quest 2, and with millions of Quests now in gamer’s hands, some are no doubt going to want to figure you how to develop games for them. This is a quick overview of the various different technical options and tools for developing games on the Oculus Quest 2.

The very first thing you are going to want to do is visit the Oculus Quest Developer Portal, the central repository and jumping off point for Oculus VR development. You are also eventually going to have to register to get your developer keys, which are required to deploy your completed game onto a headset. We will cover this in a later tutorial. For now let’s look at some of the options available for Quest 2 game development.

Native Development

Oculus release a set of low level C++ development tools for creating your own game or application basically from scratch. Native development is ultimately Android NDK development and requires Android Studio to be installed, as well as the Oculus Mobile SDK. There are a number of C++ code samples to get you started. Only take this option if you are an experienced coder and want to work at a very low level.

Unity Game Engine

The Unity game engine is perhaps the most commonly used game engine for VR development today. The Quest 2 is fully supported and you get a huge amount of starter content and tutorials to get you going. Oculus have getting started with Unity guides available here.

Unreal Engine

After the Unity game engine, Unreal is probably the next most commonly used game engines for VR development. Like Unity, Oculus have getting started materials for Unreal Engine available as well. If you are having trouble deciding between Unreal and Unity, check out this video comparing the two.

Godot Engine

The open source Godot game engine is another option for Oculus Quest development. There is a Oculus Mobile plugin available here as well as the Quest specific Quest Toolkit for Godot, which ships with tons of examples to get you up and started.

Other Engines

CryEngine can be used for Quest 2 development, as evidence by The Climb. Unfortunately CryEngine mobile and VR support is only available in a private beta currently. Additionally the Lumberyard game engine supports VR development, but currently only desktop platforms. You can run Rift and Vive games on the Quest, but using Lumberyard you can’t currently do native development.

WebVR

One of the easiest and quickest to get up and running is creating browser based VR games that can be run on the Quest 2. Here one of the easiest options is A-Frame where you can create 3D worlds using simple HTML-esque markup. Three.JS is the technology A-Frame is built upon and is another option, while the higher level PlayCanvas game engine has VR support as well.

You can learn more about the Oculus Quest 2 and the development options available in the video below.

[youtube https://www.youtube.com/watch?v=3vM3CaqC_rY?feature=oembed&w=1500&h=844]
Posted on by — Leave a comment

Unity Launch Game Growth Publishing Program

Unity have just launched a new interesting publishing program for indie game developers that have or are creating free to play mobile games. Essentially Unity are offering to fund the promotional costs of selected games and provide monetization, growth and ad placement support over the lifetime of the game. Of course this comes at a cost and that cost is a 50/50 revenue split, with a scenario described on the Unity blog:

We want to be clear about the terms up front so you can decide if Game Growth is the right program for you. Let’s break down the revenue sharing with an example:

1- An indie developer has a mobile game that makes $3,000/month. They apply to the Game Growth program. Unity spends $100,000/month to acquire new users to the game, retains those users with dedicated live operations support, and grows the game to $130,000/month in revenue.*

2- Unity would first recoup their $100,000 in monthly user acquisition costs, leaving $30,000 in monthly revenue. So the developer and Unity would share that $30,000 equally, giving $15,000 to the developer and $15,000 to Unity.*

*This model would continue throughout the partnership. We’re using this fictitious example to illustrate the revenue sharing model only. The exact investment/revenue amounts will not always be consistent month over month.

One major advantage to this approach over a traditional publisher agreement is you retain all control over your company and your games IP with minimal commitment requirements. If you are interested in applying you can do so in the Unity Dashboard.

In addition to the Unity Growth program, there is also an asset giveaway going on right now. You can get the POLYGON Prototype Pack for free using the code ‘SYNTYSALE2020’, available until October 20th. Additionally Synty assets are currently on sale for 50% off. Both of the above links contain an affiliate code that pays GFS a small commission if you buy anything. You can learn more about the new Unity publishing programming and the assets in the video below.

[youtube https://www.youtube.com/watch?v=9UjDd-bu5qg?feature=oembed&w=1500&h=844]
Posted on by — Leave a comment

Roblox Going Public

Roblox, the popular programmable sandbox video game, have just announced their intentions to go public, seeking an initial valuation of 8 Billion dollars. After their most recent round of venture capital, Roblox is currently valued at half that, with a 4B$ valuation.

Interestingly according to Reuters Roblox may go public in a very non-conventional way.

Roblox is weighing whether to go public through a traditional initial public offering or a direct listing, the sources said, cautioning that the plans are subject to market conditions.

The sources requested anonymity as the plans are private. Roblox declined to comment.

In a direct listing, no new shares are sold and underwriting banks do not weigh in on the pricing, unlike in an IPO.

By not selling new shares, companies do not dilute the ownership stakes of existing shareholders and the public listing allows current investors to sell shares easily.

Direct listings are relatively rare. Workplace software maker Asana Inc and data analytics company Palantir Technologies on Wednesday became only the third and fourth companies to go public on the New York Stock Exchange through a direct listing.

So why is this of interest to game developers? Game developers are making a lot of money on the Roblox “platform”, with 2020 earnings expected to reach about 1/4 Billion dollars according to MarketWatch:

Roblox announced in July that it had more than 150 million monthly active users on its platform, which topped the latest numbers from a similar game, “Minecraft.” Microsoft Corp.’s  Xbox division announced in May that 126 million people were playing that title each month.

Roblox also offers tools for developers and said in July that its developer community was on pace to earn $250 million in 2020, up from $110 million in 2019.

Games on the Roblox platform include “Adopt Me!,” a virtual-pet title that had over 10 billion plays as of late July, and “Piggy,” which launched in January and had nearly 5 billion visits in just over six months from its launch date.

If you are interested in learning more about Roblox’s developer program, the developer portal is available here. You can learn more about the Roblox IPO in the video below.

[youtube https://www.youtube.com/watch?v=9S9VV-NNmXc?feature=oembed&w=1500&h=844]
Posted on by — Leave a comment

Game Development in the Go Programming Language

Go is an open source programming language developed and supported by Google, by a who’s who of computer language designers. It is often used in large scale server projects at companies such as Google, Dropbox, Paypal, Twitch and Netflix. Today we are going to look at the game development frameworks and libraries available for making games using Go. We have previously created similar guides for languages such as C#, C++, Python, Lua, Codeless, Haxe and JavaScript.

2D Game Frameworks in Go:

Go Bindings:

3D Game Engines:

You can learn more about these frameworks and the Go programming language in the video below (or watch on Odysee).

[youtube https://www.youtube.com/watch?v=AwffASO9Ik8?feature=oembed&w=1500&h=844]
Posted on by — Leave a comment

NVIDIA RTX Voice Hands-On Review

In the age of COVID, with so many people working from home or in out of the ordinary scenarios, we may not necessarily have a ton of control over our environment. This means noise cancellation is perhaps more important than it has ever been. We are not immune to the effects and the audio quality of GFS videos have certainly suffered in the last few months. Enter RTX Voice.

If you are unaware, RTX Voice is a free plugin from NVIDIA that uses machine learning to filter out background noise. RTX Voice is described as:

NVIDIA RTX Voice is a new plugin that leverages NVIDIA RTX GPUs and their AI capabilities to remove distracting background noise from your broadcasts, voice chats, and remote video conferencing meetings. This allows users to “go live” or join a meeting without having to worry about unwanted sounds like loud keyboard typing or other ambient noise in noisy environments. RTX Voice also suppresses background noise from players in loud environments, making incoming audio easier to understand.

RTX Voice requires an RTX 2060 or higher and works with the vast majority of video capture applications including OBS Studio and Camtasia. The also offer RTX Voice support in their more comprehensive, but also free, Broadcast App.

We decided to put RTX Voice to the test in a simulated real world environment, using a Shure MV51 microphone and a Logitech Pro X headset (affiliate links). The tests were done with RTX Off and On with each device, as well as with background noise including typing and television. You can see (and hear!) the results in the video below (or watch on Odysee).

[youtube https://www.youtube.com/watch?v=Qqo6cfwySYY?feature=oembed&w=1500&h=844]