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.
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.
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.
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
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.
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.
Steam Game
My younger brother brought to my attention an upcoming game, Skully. It has many things I imagined for Quly.
Rock of Ages 3 doesn't look bad either...
Kula World on PlayStation from 1998
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.
I've been a gamer since we got our first family PC and over the years I had ideas for about 30 games in my “drawer”, 10 of which were quite thought thru (not just name + rough idea) and 5 of them even had a story and everything, so I started making them, but after a while I failed miserably.
My programming skills are enough for apps, but not for games, and having bad experience with strangers developers I didn't search for anybody with these skills. I got my two cents by Ants (Mravenci) remake, which is a card game and doesn't really need a game engine.
I created a primitive Dungeon Master-ish engine for a RPG called Krystal, but it didn't have a potential. I made it as a WinForms app, with game viewport consisting of 17 image holders. 8 larger (60x60) for close-up walls and 9 smaller (20x20) for more distant walls. Controller logic relied on a map, where I checked rotation of the character and his field of view.
The same problem had my adventure, created mostly with HTML and CSS, with just little help from JavaScript. It was more like a tech demo, than a game. On the other hand I had some fun doing dialogues and voices for a few scenes in that game ("Why are you so sad?" "Because graphic artist scamped me").
After a decade of tries and fails in different programming languages (BASIC, Pascal, C++, C#, JavaScript) I decided to make just one game (but finish it), cherry-pick all suitable ideas and good parts from all these games and put them into this single game. Therefore Quly for me is the Ultimate game and therefore it's open world and cross-genre.
I didn't want to use some bloated single-purpose “game maker”, that is nothing like stuff I know and will offer 90 % of features I'll never use, with bad optimization for low end computers.
So I settled for 2D with two modes: top-down view outside, plus side view inside or during missions. I'm still quite happy with this idea and I'll use it in a “lightweight Quly” called Qulyo [Coolio], e.g. for browsers and mobile devices, because it's easier to control.
I thought about a perfect main character and decided to go with a simple sphere. It will be easy to make, with lower polygon count than a person or a creature (although a nice sphere is often quite hi-poly) and it can roll really fast, which can alter as a car ride. NPCs will be spheres too.
I also thought about a name for the game, which will reflect the main character decision. All stuff I do somehow start with "Q" and many, many years ago I felt in love with name of an old Czech game "Koules" (for UNIX, OS/2 and Linux). It's Czenglish plural of “koule”, which means “a sphere” in Czech. I like the fusion of a Czech word with English grammar. After many variations I ended up with “Quly” (and “Qule” for the sphere).
But inside I felt I wanted to make a 3D game. MonoGame was exactly what I wanted and I started to see how complicated making of a 3D game is. It turned out keeping the code small and simple is absolutely impossible. The same problem I had with WebGL (JavaScript API for 3D in web browsers), which was a hot topic at that time.
About two years after my tries with XNA my younger brother showed me Unity. I described my idea of the game to him and it was quite funny, when he put the RollerBall Character into the scene, which was pretty much it :-)
My first tries were OK, but I was lost. I was otherwise engaged at that time, so I decided to continue when Unity 5 is out.
The release happened few months later. My brother gave me a nice jump-start and I started to build a learning version of Quly. I always do it this way, so I'm not afraid to mess it up, because for the real thing I'll start again from scratch.
I really appreciated YouTube tutorials, especially those from Unity team itself. Unfortunately, some of them still used legacy features, which has been often replaced by newer approaches in Unity 5. Later I often followed the tutorial and spent few hours of fiddling and tweaking, but ultimately (and often accidentally) found out it's legacy and therefore not recommended for a new game. Damn!
Now I realized how foolish I was for rejecting pre-made 3D engines. I'll never be good enough to make an optimized game engine by myself. In Unity I simply make a short script, attach it to a GameObject and test it. It's really fast, straight forward and I love it! It allows me to focus on gameplay and game features only, without coding collision detection, physics, vector maths and tons and tons of other stuff I'd have to make e.g. in XNA.
Also I don't feel Unity is pushing anything, it's basically “just” a 3D engine with scripting. If I'd like to make program like Google Earth or 3D draw, instead of a game, I can with no problem. What amazes me are all those built-in functions, which makes coding much quicker. I always wrote tons of util methods, in Unity I have only “playSoundAtPoint” (built-in doesn't work as expected) and then serializable classes, that are not serializable in UnityEngine (like Color or Transform/Vector3).
Also, C# is my favorite programming language and the system of scripts and stuff in Unity really suits me. And cooperation with my favorite 3D software of all times, Trimble SketchUp Make, puts me on cloud nine! :-)
I created a proof-of-concept for Quly. The demo scene contains several scattered items, NPCs and locations just to showcase and demo some stuff for the game:
You can see some of those features in a video created a month ago:
I’ve always wanted to make a computer game. I got my two cents by Mravenci (Ants), but I had many other ideas, especially in my early years of programming (1995+).
In my early programmer years I had a bunch of games in my head and after some time some of them started to be quite thought out. Unfortunately I didn’t have the skills to bring it to life, I tried and failed many times in many programming languages.
When a decade passed by with no signs of completing any of them, I decided to take good parts from all of them and put them into a single game, which I will finish. I thought about a perfect main character and decided to go with a simple sphere. It will be easy to make, with lower polygon count than person or creature (although a nice sphere is often quite hi-poly) and it can roll really fast, which can alter as a car ride.
In 2013 I attended MS Fest in Prague and saw Tomáš Slavíček’s lecture about MonoGame (follow-up of dead XNA), so I gave it a try. It was OK, but still... making 3D game was beyond my skills. I kept it in 2D, but wanted 3D inside. MonoGame was exactly what I wanted and I started to see how complicated making of a 3D game is. Keeping the code small is absolutely impossible. The same problem I had with WebGL, which was a hot topic at that time.
I didn’t want to use some pre-made 3D engine or game makers, because I saw some of them and they felt overcomplicated, with many features I probably won’t use or need and will run slowly on some machines.
During that time I thought about a name for the game. I somehow decided all stuff I do will start with “Q” and I many, many years ago I felt in love with a name of an old Czech game “Koules” (for UNIX, OS/2 and Linux). It’s plural of “koule”, which means “sphere” in Czech. I like the fusion of a Czech word with English grammar. After many variations I ended up with “Quly” (and “Qule” for the spheres).
About two years after my tries with XNA my younger brother showed me Unity. It was quite funny, when I described my idea of the game to him and he loaded the RollerBall demo scene, which was pretty much it :-)
My first tries were OK, but I was quite lost and didn’t really know how to do stuff. I was otherwise engaged at that time, so I decided to continue when Unity 5 is out.
The release happened few months later. I really appreciated YouTube tutorials, especially those from Unity team itself. Unfortunately, some of them still used legacy features, which has been often replaced by newer approaches in Unity 5. Many times I followed a tutorial and spent few hours fiddling and tweaking, but ultimately (and often accidentally) found out it’s the legacy way and therefore not recommended for a new game. Damn!
My brother gave me a nice jump-start and I started to build a “learning” version of Quly. I always do it this way, so in my mind I’m not afraid to mess it up, because for the real thing I’ll start over from scratch.
Thanks to great capabilities of Unity I was able to concentrate on gameplay and features only. Many things are already made, like collisions, physics, vector math and tons and tons of other stuff, so I didn’t need to bother with them (for example in XNA I had to deal with all of them).
I realized how foolish I was for rejecting pre-made 3D engines. I’ll never be good enough to make an optimized game engine by myself! I'm no John Carmack. There’s such vast amount of things it needs to be done and of course done properly.
In Unity I simply make a short script, attach it to a GameObject and test it. It’s really fast, straight forward and I love it! Also, C# is my favorite programming language and the system of scripts and stuff in Unity really suits me. And cooperation with my favorite 3D software of all times, Trimble SketchUp Make, puts me on cloud nine! :-)