I'd argue that 2022.3 is still the best option if you don't want any drama from your tools. Using "old" versions of game engines is generally much safer than the latest. Let someone else figure out if the new model of parachute is any good before you try it.
If the tools are dominating your thinking during development, you've perhaps chosen the wrong ones for the job. There is no shame in using older tools to build games. This isn't like a banking web app. No AAA studio is going to give you extra consideration because you have unity 6 experience vs something slightly older. Valve certainly doesn't seem to give a shit. There's not much reason to chase a higher game engine version number.
If you are a solo/indie studio and you are using a newer version of a tool because it appears to enable something in your game, you are probably not going to do well. The engine does not make the game. It supports the game. Concerns like the "Unity look" are a consequence of the developers and artists doing a poor job, not old or subpar tooling. Environment lighting settings have their own hot key. Breaking out of the aesthetic mold is trivial if you make any attempt to do so.
Valve is nonexistent in the modern gamedev community, Source 2 is used by approximately noone, and overall releasing one game every decade doesn't exactly make Valve a prominent voice in the gamedev community.
However, yes, companies lock their engines at whatever it was when they started their project, and any upgrades comes from internal engineering. Decade long undertakings like the "recent" FF7 remakes are still on UE4 and will stick with that for the third game, because that's what they started with, and at this point the rendering pipeline and workflow is theirs
I was in the audience when DOTS was announced, and a decade later Cities Skylines II showed how ill equipped for prime time it remains (not that the developers were blameless).
Deprecating entire languages (probably the right call long term, oddly enough Godot is keeping GDScript around).
Render pipelines (URP and HDRP to be merged, built in likewise being deprecated).
Most of the things around DOTS.
Most of the things around networking.
The whole package management system (I mean, it’s a nice idea, still counts as churn).
Also multiple approaches to UI and input.
I would say that a lot of the new stuff is built on good ideas but I sometimes wish they’d slow down a bit and ship actually thought out and finished features.
And most of the above already had alternatives previously, this isn’t even getting into wholly new things like Sentis, if you are working on an old project thankfully it will mostly keep working, but if you need to keep up to date with the current mechanisms and practices, there’s a lot of churn.
Maybe not as much as in Godot, but to be honest that other engine is going through a lot of evolution so instability and a feature explosion is to be expected (despite terrain still being a plugin, while Unity’s own terrain implementation is oddly dated and abandoned, while their water system felt like a tech demo and more often than not the asset store is expected to do the heavy lifting), while Unity tries to appeal to everyone and capture headlines it seems. Just look at the marketing around DOTS (and how long it took for it to be usable).
Looking at the past year of Unity updates, since 6.1 or so, it seems that most of the focus is now going to refactoring major parts of the engine to facilitate backporting HDRP's feature set to URP. It's all good work and high time they did some cleanup and committed to a single standardized render pipeline, but it's not exactly moving the needle forward very much yet.
Even in Unity 4, it was like "You can write scripts in C#, or you can also write them in Unityscript or Boo, I suppose..."
In comparison for Godot, GDScript is very often the happy path. Things like web publishing work more seamlessly with GDScript than with C# (and miles more than GDNative/GDExtension). So I don't think it's nearly as likely to get deprecated as Unity's scripting languages.
Godot community is practically all GDScript. If they removed GDScript it'd be more akin to Unity removing C# while keeping Boo.
They do have a pretty nice page talking a bit more about GDScript: https://docs.godotengine.org/en/stable/about/faq.html#what-i...
The obvious additional good from this approach is that you no longer couple everything so tightly with just one scripting language, so in some ways it's a bit easier to introduce bindings for other languages. The downside, however, is that it leads to fragmentation in the community, duplication of effort (suddenly you need the double amount of docs), more difficulty and friction in development with new mechanisms demanding that you take the limitations of both languages in mind, oh and if you dare to write your own language then suddenly you have to support both it, as well as any dev tools for it. For what was and still is a communtiy project without strong financial backing (just look at how much money Unity burns on useless stuff, and how much more the people behind Godot could do with that money), that's quite the gamble.
Maybe if they focused on the core engine more, then deltaV: Rings of Saturn wouldn't have odd performance issues for a 2D game and wouldn't get confused with multi-monitor setups. Maybe Road To Vostok wouldn't crash when loading into the Village map on an Intel Arc GPU, and also start on the wrong monitor same as deltaV. Maybe even demos like "Realistic Jungle Demo" on itch.io wouldn't have all white textures on said Intel Arc GPU. Maybe we'd be two or three whole releases of features ahead by now, if all of the hours spent on GDScript to date would have been spent elsewhere.
On the other hand, there's no guarantee that any of those devs would fix the other issues if their efforts were to be redirected. Similarly, if they didn't try with GDScript, the community would be smaller, due to its ease of prototyping, and being simpler and more approachable for the folks who don't know C# yet, even if it's also unnecessary to the folks who like tools like Rider/Visual Studio or are coming from Unity or engines with scripting in C# or just C++. I'm pretty split on it overall.
Superhot (2016), outer wilds (2020), and limbo (2011) received patches last year. How do the developers of these successful games manage that?
See Satisfactory for how much of a pain it can be to actually go through major versions, and how long it can take a more complex game.
Although, I will say that newer versions have made it a lot less annoying to keep up to date.
Exactly. It's common in game dev industry to keep using the same version of Unity for a project. Sometimes a minor version is updated, and I do mean sometimes, because large projects break for the smalles changes (despite semver).
- do you really need a game engine for making a 3D counter strike game?
- arent there libraries in c++ like raylib, jolt for physics etc?
- if you had to make a CS type game, what libraries do you think would be needed to get it done without touching unity, unreal, godot etc?
In terms of wiring up various libraries, it's more difficult than it might sound initially because they all need to interact together, it's not so simple as just wiring up a few API calls together like you might do to build a web server.
Now of course CS 1.6 is built on the GoldSrc engine, which spawned from the Quake engine. Very different from modern engines, so obviously you can do it without Unity or Unreal or Godot. The question is if you want to, and if the time spent doing so is worth it.
People can and do build on top of Quake, so that could be a reasonable option if that's the feel you want for your game.
There's just so much you don't know until you do, and there's a reason even all those "render engine" libraries have fallen kinda defunct (Ogre, Irlicht, etc). It's hard and distracts from the real goal.
Just grab an engine and get started on the game day 1 with a tool that can guarantee any game can be made with studio-quality tooling and compatibility.
It's the same reason you grab a date time library. It sure seems totally doable to "just handle times" right up until you try.
If making an engine was really that easy, studios wouldn't pay tens of millions to avoid doing it. Godot 3D would be solved by now.
- i was under the opinion that we may have enough libraries in c++ for just about everything from load assets to handling physics to handling graphics , networking, rendering etc
- isn't that the case given 20+ yrs of development on C++
You will also need to figure out client/server side prediction, rollback/reconciliation, lag compensation and make this perform well.
And then you need an anticheat and skill-based matchmaking and ...
For 2D, yeah, making the engine yourself is fast and easy. Can go without a big engine.
Grab SDL or Qt (underrated; gets you a nice menu and HUD layer) for windowing/input, basic event loop, etc.
Write a renderer, e.g. on top of wgpu or bgfx depending on how much scaffolding you want to have to write yourself.
OpenAL Soft for audio.
Jolt or Bullet for physics.
A good scene/world model as the backbone, and ways to efficiently mutate and propagate state. You can pick up an ECS lib for this, or just go custom and hand-wring your data structures, mutation journals, caches, what have you. Your scene model feeds into (and interacts with) collision/physics, audio (listener/sound sources), your renderer for viz, etc..
For gameplay a nice approach is some fundamentals in native code (e.g. triggers and actions) and then a scripting bridge.
The problem is basically that doing a good job requires a substantial amount of experience on several levels of being a dev: Good architectural knowledge (incl. state of the art, historical examples, trade offs), lots of domain-specific techniques (rendering, stepping, etc.), solid systems engineering (good platform/shell abstraction, OS/platform integration bits, debugging/logging/tracing infra), being handg with algorithmic work, performance/optimization-minded work, and so on and so forth. It takes probably at least a solid decade before you can knock this out without tripping up or needing a lot of endurance.
Oh, and on top of all of that don't forget to design an actually fun game.
- I am assuming c++ would be one of the most recommended ways to start
- What is this bit about rendering? and good scene model / world model. Could you kindly elaborate on that a bit?
- For things that require the most amount of knowledge / effort in making a counter strike type game, what do you think would be the top 3 most effort oriented steps / milestones in doing so
It is however built in rust, not c++, don't know if that's a deal breaker?
- basically i am already not familiar with gamedev.
- on top of that i am not familiar with rust
- on top of that it is a new library meaning when I run into issues and I will run into all sorts of issues, I ll have to rely on a small bunch of maintainers with no mainstream support from stackoverflow or AI
- I made this mistake once in my life by choosing nuxt to build a website when I was new to web development instead of making a simple html css js website that I was familiar with
- Never again
The author is a friend of mine. A few weeks ago he mentioned this small game he made years ago was more successful than his ambitious projects. After that conversation he decided to update it and produced this wonderful blog post.
If you haven’t checked out the game yet it’s a lot of fun for the modest price.
Light theme might have a readability edge in daytime / well lit offices. But I'd bet most people using Unity are hobbyists doing it at home in their evening hours, when you want to dial down your blue light for the sake of sleep.
With high quality displays that have good contrast and backlight controls that go "really far down", I prefer light mode UIs nowadays.
But, only a few of my displays can dim enough to make it work in dark(er) rooms. CRTs were great at this, with the brightness control for the raster. LCDs generally aren't, though the fancy "FALD" backlight in my macbook pro does get dark enough to make light mode work well in dim spaces.
I suspect that changes in ambient lighting over time are what drive most people to max out their backlight and use dark mode. It generally works in all conditions.
So I use dark reader on web and get creative with apps that think dark mode is dumb.
Anecdotally, I just find dark mode more comfortable, even during daylight.
If an app doesn't have a light theme, it's very hard for me to use.
I’m guessing hard contacts not helping anymore or not an option? Have a buddy who is maintaining his vision that way.
The more recent frequent breaking changes around URP custom renderer features and render textures haven’t been much fun either, but nothing as bad as losing a working lightmapper and light probes support (the replacement really want ready for actual use) while working on a project highly dependent on baked lighting…
Not saying I agree with everything in that article or Unity doesn't provide hundreds of useful features.
> I tried to boot up Gun Rocket to play it. But it refused. No matter how hard I clicked the game would not open.
> After trying a few times I realize if the ship isn't moving for about 0.5 seconds it explodes. Has that bug existed all this time? Oh bother. I hope not!
Grinds my gears that the game has continued to be listed for sale on Steam with years-old negative reviews pointing out exactly these issues, but the developer still has the gall to act surprised about them.
When Gun Rocket launched, it did ok (maybe $100s). It made me feel great, but nothing life-changing. Most of the money I made was selling the distribution rights to a publisher (low $1000s). Again made me feel good but nothing crazy. They made some changes like a splash screen ad that I did not like. When that contract term was up I focused on removing that garbage. Idk when the explosion bug was introduced, but the point is I was surprised and immensely frustrated when I found it because the history of this game left my care and came back.
I agree that this bug existing for a long time reflects terribly on me. I hope that fixing it late is better than never fixing it.
But Godot has an issue here, "naked" godot games are fine, but the second they use "addons" as shared libs instead of being statically linked into the main exe, it is a disaster as most of them are built for massive mainstream elf(glibc)/linux distros. It seem also godot games tend to use much more nasty third party shared libs. addons/third party shared lib devs are mostly forgetting '-static-libgcc -static-libstdc++' compiling/linking options while generating their shared libs. For addons, they should provide static libs for game devs to link in their main exe.
