Unity in switching to Godot
This has been a turbulent week for not just for game developers, but also asset creators or tutors. I can't imagine how they must have feel to see often their livelihood being shredded by a series of questionable management decisions.
Everybody keep saying the biggest issue is lost of trust, because that's exactly what it is. Reversing the decisions won't make it go away, the damage is done, because if they did such thing today, what stops them from make even worse things in the future?
That's once again the exact reason I don't like relying on third party libraries. It costs a lot of time and effort, but do you know what else costs a lot of time and effort? Creating stuff on top of suddenly dead product. There are creators currently finishing elaborate tutorials for Unity after months of hard work, but who would want to learn it nowadays?
I have to say, even I spent dozens of hours developing games in Unity, I don't feel like commenting on this from a position of a Unity dev, because I don't consider myself as one.
My take is I'm glad I ultimately decided to greenlight Qard as my engine of choice for further progress on Quly, despite it being inferior to “real” game engines.
I'm really glad many former Unity users are looking for a new home in Godot, because I think the engine is cleverly designed and has really a lot to offer. Godot creators are working day and night to accommodate the endless flow of newcomers and already promised to deliver some lingering big features, like console support or multiplatform C# support.
Let's Qard
…
describe insides how to make game in Qard
Experiences and upgrades during GemTube development
Qard Demos
I had Qard game engine just laying around, with few features implemented here and there, because I didn't really knew how to proceed with various unsolved issues I had in the engine.
I became fed up with the lack of any progress, despite overflowing with ideas and a desire for game development in my own engine. So, just as I always do when testing the capabilities of my new creation, I started crafting projects – in this instance, simple games. Boy, that was probably the most fun I've ever had in this situation!
- *The first* was a simple bouncing ball, that evolved into 1000 colorful bouncing balls.
- *Second demo* was to test (and develop) a simple input system, using just pointer events.
- With the *third demo* I focused on moving animated sprites.
- *Fourth demo* was first shot at UI elements, creating buttons (remember, it meant to code the whole thing: drawing buttons on canvas, handling pointer events and properly response to them).
- *Fifth demo* was once again input, this time keyboard. It may sound easy, but I had to finally decide how to tackle key customization.
- *Sixth demo* added sound and more serious gameplay. This time it was GTA 1 style top-down car driving. I failed to implement handbrake turns, but I'm quite satisfied with everything else.
- *Seventh demo* kept the high standards and it was walking figure using sprite sheets. To make things even more interesting, besides obvious keyboard I also added pointer support, where the figure walked to the position you clicked on. And it had a gun :-)
- *Eighth demo* was tiled top-down world of pseudo-unlimited size, where the engine doesn't draw off-screen, the world is draggable using mouse and tiles could be edited.
- *Ninth demo* was rocket like Asteroids, only without the asteroids.
- I became too cocky, so *tenth demo* was finally an attempt to make rotating 3D cube. I failed as usual.
- *Eleventh demo* was a nod to the first one, but now with collisions. I had to generate just 100 balls to prevent my laptop bursting in flames.
- *Twelfth demo* explored platformer capabilities, generating fast moving multi layered parallax scenery.
- I've been resisting long enough, so *lucky 13* is finally a pong. Both paddles are controlled using the same mouse, with inverted axes to make things more interesting.
- *Fourteenth demo* was kept blank for some reason.
- *Fifteenth demo* was simple mouse drawing.
- *Sixteenth demo* was top-down moving Qule with mouse steering and health bar.
I stopped there, because I encountered some big missing pieces that may change the way games are created in the engine, so basically all the demos would need to be updated.
But because of the fun I had I've decided to do even more simple demos like that in the future, maybe some inspired by Liero or Mini Metro.
As I was hoping for, during the trial and error I used the TDD approach many times – write the intended code for the task and then figured out Qard's inner workings to make the code run.
Because Qard utilizes QetriX way of programming, when working with sound and input I spotted similarities in Qard and was able to unify the code so it could be merged into the Framework as services.
Qard itself has been redesigned as QPage alternative and functions has been distributed into common libraries.
Qard Track Tiles
If I fail at some task I gave myself, I tend to return to it after a while. In the meantime I gained some new ideas, skills and perspectives, so I may succeed this time.
Tiles
Despite my intentions to make Quly in 3D, I still would like to have it as a tiled game. I love OpenTTD and I simply want something like that in Quly as well.
Crafted curved tracks to occupy as few tiles as possible, while keeping fidelity.
The TileGen system will know what tiles can be next to what tile. Of course tiles would need layers, at least for background (surface – grass, concrete, sand, water, dirt...) and foreground (tracks).
Tracks will need some navigation metadata, like directions, type (rail, road, offroad) and I'd like to add stuff like name (streets). I will go with a set of waypoints for each direction on the tile, setting target rotation and position. The intermediate positions and rotations of the travelling Qule will be interpolated from these values.
From foreground and background a rolling sound will be derived, so it can be different when Qule is rolling on asphalt or grass.
Each tile will also need some collisions baked into them, also because I want to create not only exteriors, but interiors as well, probably in zoomed manner.
Another layer would be for sprites – player, NPCs, items, movable or destructible objects, scenery etc.
..in 3d merge them together for better performance
Perspective
During the whole design of the track tiles I kept thinking about perspective of the game.
I quite like isometric graphics (and those tracks in the previous picture looks awesome in “iso”), but I want at least three degrees of slopes, which are in general quite an issue in tile games.
Out of curiosity I tried to convert isometric back to the square form and it doesn't look that bad, but it's still a compromise and slopes looks twice the height.
Isometric hill converted to... whatever-metric that is :-)
There is also a dimetric projection, used by games like Baldur's Gate, Diablo II or StarCraft. Especially the latter has actually been a great inspiration for me, since I always liked StarEdit and it's editor of mission objectives.
Zelda-style (3/4 perspective) is usually the way to go for tile games and I especially like how MiniDayZ looks like and plays. Even I don't like it, it's the most practical solution.
It's possible to use tile engine to create a first person 3D game, similar to Wolf3D, as excellently demonstrated by Xibalba, WebGL game using ImpactJS engine.
Scenes
You probably know it – there's a brilliant idea right from the start, but you didn't see it for years! Scenes is one of such things.
When you define layout i Qedy, you use model.graph to do so. And most of the time you start by defining various screens, using QView or QForm Components.
When switching between those screens, you need to make it visible and hide all the other screens, because you don't know which one is visible at the moment.
At first I created a helper method swap, which first argument was what comp to show and all other arguments were comps to hide. But if you add new screen, you have to modify many swap calls to add the new screen to be hidden as well. I'd like to automat that.
I kinda always liked the idea of iOS's Storyboard editor in Xcode, introduced for iOS 5 in 2011. It's very simple way of visualizing GUI of the whole app with flows between "scenes", which is basically just a View Controller:
Storyboards of iOS app in Xcode (source: kodeco.com)
In Unity3D, "scene" is not just level or piece of a game world, but also Main Menu or different parts of the game. This would fit nicely into the platform ecosystem, as the system could be repurposed from Qedy in Qard as well.
So, when parsing a model, scenes are created from all named components directly in graph.add. And later, when switching scenes in the app, you call scope.scene("scene1") for scene1 to appear.
I'm thinking about automate it even more and allow scene names to appear in path, so to call scene1 you just navigate to /path/to/scene1. But I have to deal with path component mismatches first, as there will be plenty of edge cases.
Debugging in Qard
canvas shadow, custom console, debug info printed on screen, FPS and UPS
Features
I've always wanted to have a "Store", where user chooses what components are needed for the project and they're used as the main building blocks for the project.
InputManager
Pretty much every game engine is using some kind of input manager to translate sensor inputs into game actions, especially because you can use a multitude of input devices and modes.
multiplayer on single device, key mapping to action, scopes (in car, on foot...), player assignment to named actions
keyboard
pointer mouse
controller
mobile - gyro, multitouch...
Qard
Unlike my fellow coworkers from business and project departments, my December is usually less busy, than “classic” months, so I can work on stuff I didn't have time the whole year, like lowering technical debt, testing new ideas, concepts or languages, or starting new side projects.
[2015/01#mravenci-as-qetrix-webapp Few Christmases ago] I recreated a card game “Mravenci” (Ants) for iOS and Android, while testing embedded QetriX WebApp. It worked really well and the game is still quite popular, despite I don't support it any more (because I don't release on Google Play and Apple Store very often, so it's always a hassle – install the current version of IDE, fix what's broken in the current language version, update store pages... while keeping the game free and ad-free).
Mravenci (Ants)
It wasn't my first mobile release of Mravenci, the first one was back in 2008 (of course during Christmas :-) for Windows Mobile on .NET Compact Framework, so it is playable on PC with .NET Framework as well – even to this day.
I obtained permission from the original author to use the graphics and sounds. He even kindly described, how to extract all the assets from Peter, a visual programming tool he used to create the game in.
For the WM game I created a platform “Logicard”, that uses cards definitions in a XML file, so you could customize them to your liking or create a completely new game with similar “Arcomage-esque” mechanics.
And this brings me to Qard. The idea of a game engine (of sort) sprouted once again in my mind, but this time not only for a card game, but rather any sprite or tile based game running in a web browser, using DOM or Canvas.
Qard Logo: Tile-based “Q”
Browsers these days are incredibly powerful, with amazing set of APIs, such as support for game controllers or WebGL. I decided to create a modular engine to include just what the game needs and nothing more to keep the final footprint as small as possible (Mravenci have less than 2 MB on iOS and Android, which is quite unheard of nowadays).
There are some great web-game engines, but you probably already know I like to create such platforms myself and in my way. Also Qard will support QetriX style of coding and components, wherever it would be feasible.
I've decided to retrospectively add a “qard” tag to all related posts I wrote about canvas and game mechanics on this blog in the past, so it will be easily accessible on a single page.
InputManager
There are quite a few ways, how to control a game: Keyboard, Mouse, Touchpad/Trackpad, Trackball, Trackpoint, Gamepad, Joystick, Racing Wheel, Touch, Motion, Gestures and more. Many of them are overlapping, because different players have or use different devices.
Nowadays, when using mouse and keyboard, it's common for a 3D shooter to use WASD and mouse, but two decades ago it was common to use just arrow keys to move and turn, with other keys for strafing, firing and doing stuff.
Therefore game engines often contain a dedicated system to incorporate all of them, with customizable controls on top of that. You basically define “aliases” or “codenames” for all controllable actions and then you set them true, if the corresponding keys were pressed, and to false otherwise.
Modern browsers have support not only for keyboard, mouse and touch, but also for gamepads and various sensors, like accelerometers (motion), gyroscopes, proximity sensors, magnetometers or ambient light sensors.
Every device is firing events, so you only add event listeners for button-pressed and button-released events, and in their handler functions you set appropriate values for appropriate actions. You also need to account for multiple key pressed, so you can't reset everything when button is released.
- document.body.addEventListener("keydown", function (ev) {
- ev.preventDefault();
- input["k_" + ev.code.toLowerCase()] = true;
- inputManager();
- }
- document.body.addEventListener("keyup", function (ev) {
- ev.preventDefault();
- input["k_" + ev.code.toLowerCase()] = false;
- inputManager();
- }
In the example above, input will contain an entry for all pressed and released keys, which will be handled inside inputManager:
- function inputManager() {
- input.action = input.k_space
- || input.p_buttons > 0
- || input.t_touches > 0; input.menu = input.k_escape;
- if (input.handler) input.handler();
- gameLoop(performance.now(), true);
- }
It's very simple implementation, using only “action” and “menu” actions. There's also custom event handler, in case something comes up, that will need a special treatment – like in-game pause menu.
Buttons are one thing, but there are axes as well. They use scale in the interval of <-1; +1>, instead of simple true/false boolean values. Unity cleverly implements virtual 1D and 2D axes, where you dedicate one button for +1 and another button for -1 value of a particular axis.
When pressing two buttons at once, magnitude of the resulting vector is greater than 1, so in practice a game character may move 1.4× faster diagonally. To remedy this issue, 2D virtual axis off normalized value by default, with option to revert to raw data.
Values for virtual axes. Yellow circle is for analog, purple square is for buttons and blue octagon is for normalized input.
You can also apply normalized values on analog axes and use thumbsticks as buttons, to restrict a game character to move in only 8 directions.
When controlling movement using virtual axis, it looks better to gradually increment the value, so there's the “increment” setting, and when you need to gradually decrease the value after releasing a button, there a “gravity” setting.
Game loops in various game Engines
There are many game engines available, each with its own way of implementing the game loop. Here are some examples of major game engines and their approaches to the game loop:
Unity
Unity was first released in 2005 by Unity Technologies. Unity supports several programming languages for scripting, including C#, UnityScript (a variation of JavaScript), and Boo.
- void FixedUpdate() { // Physics calculations here } void Update() { // Game logic and rendering here }
Unreal Engine
Unreal Engine was first released in 1998 by Epic Games. Unreal Engine uses a custom scripting language called UnrealScript, but it has since been deprecated in favor of using C++ or Blueprints, a visual scripting language that allows developers to create game logic without writing code.
- while (running) { ProcessInput(); Tick(); Render(); }
Godot Engine
Godot Engine was first released in 2014 by Juan Linietsky and Ariel Manzur. Godot Engine uses its own scripting language called GDScript, which is similar to Python.
- func _physics_process(delta): // Physics calculations here func _process(delta): // Game logic here func _draw(): // Rendering here
asdf
CryEngine
CryEngine was first released in 2002 by Crytek. CryEngine uses a scripting language called Lua, which is a lightweight and easy-to-learn language often used for game development.
- while (running) { ProcessInput(); TickPhysics(); TickAnimation(); TickGameLogic(); Render(); }
asasdf
Construct
Construct was first released in 2007 by Scirra. Construct uses its own event-based scripting system, which allows developers to create game logic using a visual interface without writing code. However, it also supports JavaScript and TypeScript for more advanced scripting needs.
- function physics_tick() { // Physics calculations here } function game_logic_tick() { // Game logic here } while (running) { physics_tick(); game_logic_tick(); render(); }
asdf
Canvas context2d
ctx.fillRect
ctx.font
ctx.textAlign
ctx.fillText
ctx.arc
WebGL 2D, very difficult to write
Collisions
There are several collision models, with the main ones being box and sphere.
I originally thought sphere-sphere collision would require some sin-cos witchcraft, but it turned out to be the simplest collider of them all. You only need two points and two radii (the plural of "radius"). You can calculate the distance between the two points, which are the centers of the spheres, and if it's shorter or equal to the sum of the radii, then the spheres are colliding.
I didn't know that when I decided to make a sphere a major shape in Quly and now I'm even happier with that decision :-) It still needs quite a few triangles to draw though. But I digress.
The bounding box model is quite easy to compute since you have two X, two Y, and two Z coordinates, and you compare them for both boxes to compute the collision. Easy peasy.
In many cases it will be more favorable to rotate the box, for which it needs much more math.
Unity's Capsule collider is quite similar to the sphere model. The main difference is that it involves two spheres and some math in between for each collider.
With colliders defined, now we need to apply them ingame.
Hit box is a similar thing to a collider, but you can use more trickery there. Like instead of representing enemy using a bounding box, it may be enough to just use a line (if there's no chance to hit him from above or behind). If you're doing a simple 2D shooter, you may even use a point collider, that only moves up and down during jumps. Or the other way around, use line collider for a bullet and point collider for a target.
Raycasting may be slower.