I've tried a few times to start making a game I consider "simple", the basics are:
* Animated character
* Top down view
* Grid based floor
* "Default" RTS/MOBA physics
I've tried both Unreal and Unity but I've always found myself blocked by having to find out how to make something look like water, how to make an animation sync with movement, how to customize movement to something already familiar, etc
This means I can't actually make a game if I first don't make my own pretty much everything
I think that more than game engines, we need game frameworks that provided game designers with presets that present "solved" game mechanics, like water styles, ground tiling, precise character animation for any view angle, character movement, etc
It would be nice if we could have a "democratization" of video game development anytime in my lifetime
I can find the resources on how to do those things, I have a compiled list of tutorials & code with what I wanted, but that still leaves me with a ratio of 80% programming vs 20% game design
It'd be nice to be able to create a character and just attach preset behaviors: walk like Dota, add jump, etc
Then I can focus 80% on game design and 20% on development, this way I can know upfront if my game is worth polishing and customizing those presets
Agree with this. Sounds like you want to prototype game designs more than code/utilize final implementations. The standard advice you'd get in game dev is to use super low production value assets to prototype. People even often "paper prototype" or use other completely non-digital media.
I agree with the sister comment to parent that suggested something like Game Maker. Those tools are simpler and more usable out the box than game engines.
If you want the feeling of completing a simple game as you go, and seeing your (near-)final implementations of elements as you hammer them out -- that's fine as a learning exercise. It will probably be inefficient (as you may change you mind about things later on that you already spent a bunch of time implementing/polishing), but it can be a cool way to learn. However, for that, you may run into what some other comments are saying: you'll have to figure a lot of custom stuff out as you go.
Edit: There's a good series[0] where a game critic / indie game dev makes 12 games in 12 months. He uses Game Maker Studio 2 and the episodes go back and forth between concept/design and execution.
Whiteboxing/Greyboxing/whateverboxing is one of the most important processes that all too many hobbyists don't do, which causes them to burn out on gamedev. They want to _see_ everything working with how it looks in their head, but in reality the game mechanics vs. visuals are very different skillsets that can take a lot of time to master. I would recommend most new gamedevs spend all their time using just default objects in their respective engines. Literally just white/grey shapes that act on user input. If the mechanics feel fun with whiteboxes, they'll feel more fun with actual models/sprites/whatever. But on the flipside, you'll never know if your mechanics are fun if you never make them because you're too busy worrying about water animations.
I have searched in the Unity asset store, and there is either not what I need, or what I need is in several different packages that aren't seamless to use together, or the cost of everything is more than my monthly salary (non US here)
> But I'm guessing in addition to having your dream engine/working environment, you also don't want to pay a dime for it.
Before Unity came out the same could be said about people wanting a more accessible engine, no?
I'm fine with Unity's and Unreal's pricing models, I just want a more creator friendly game editor that isn't Roblox
I think that's just the nature of game dev. CRUD apps seem like they're all basically the same, yet we still hand-code them because there are always weird quirks and edge-cases. This is 10x more true for games (at least, remotely interesting ones). A game engine that supports exactly the kind of game you're wanting to make, out of the box, is not really going to support any other kind of game (or even very novel ones within the same genre). So the "everything" engines have to stick to the very most basic, least-common-denominator features, and even those are sprawling and require compromise.
It is exactly the nature of game dev. Most people fail to understand the level of complexity behind it. I think there's also this false sense that "basic features" in games are both simple to implement and universally applicable.
By example, grab two successful games that are considered to be in the same genre - say, Counter-Strike Global Offensive and Call of Duty - and compare them on a single, "basic" feature like character movement. There are actually massive differences in how they feel and play, and it goes much deeper than just tweaking some settings on a customizable character controller asset.
It's easy to take stuff like this for granted and just assume the implementation is simple. In reality it is much more complex than that, and many of the differences that seem subtle may actually be much greater when it comes to design and programming.
The roots may actually go back further than that. There's a custom map for Starcraft/Brood War which used single hero control and lane pushing mechanics and predates the WC3 DotA maps:
It's a learning curve. You don't need to reinvent all these things, but you do need to learn the tooling.
* Animation sync with movement in unreal is done either by embedding root motion into your animations or just trying to use a blendspace to make movement animation fluidly transition with your speed.
* Movement is customized for basic characters via the character movement controller component.
Visual scripting in Unity or Unreal, combined with asset store packages, can get you very far. A buddy of mine shipped a game on Steam built entirely in PlayMaker. But he had spent five years learning and mastering the tool and the engine. YMMV.
You seriously need to go through a few standard unity tutorials they offer just after installing, it will save you a lot of time and the blocks you've mentioned.
I’m not advocating for Roblox because it’s quite terrible. But. They did make it stupidly simple to make stupid 3D games. If you like getting eaten and slowly have poop stuck to you while falling through the digestive system until you are pooped out…
I have not tried godot yet but it’s something I’m going to get to soon
Godot is coming up mighty quick. I've been favorably impressed. Also, if your concept is 2D, it's way beyond the 3D-centric game engines for that task: might not be the question being asked, but it's worth a thought.
It helps to start with a less complex game and learn the basics of how the engine works. I know in Godot at least (and I assume Unity is miles ahead) there are prefab things to do what you describe but you will need to know how to fit them together.
Another option would be to fork an existing foss RTS game, like Spring, Warzone 2100, BOSwars, etc.
Yes I agree with you. Even with unity/unreal/etc. it’s still a monumental amount of work to have a game. Personally, I have more fun modding a fully functioning game than I do starting from scratch.
Modding is a totally underrated thing right now, but I feel it might become big in the future. Someone just needs to come up with a solution to both keep mods free and incentivize mod authors.
The way I see it, the big boys create games that acts as platforms and users freely create content of their own using these platforms. Bethesda/Microsoft might be in a good position to achieve this, they have good modding communities around their other games, really interested what their next title brings to the table, hope they don't blow it up like the last time they tried to monetize mods.
You also have something like Roblox, where the concepts of game development and modding kinda blend together, so it's definitely a trend to keep an eye on in the future.
You should keep an eye out for S&Box! It's the successor to the popular Garry's Mod.
Garry's Mod is, imo, the sandbox and modding game and I think that S&Box will be even better. It's based on the Source 2 engine, and the main developer Garry has collected a lot of experience with GMod.
While GMod mods are based on Lua, S&Box uses C#, which is an awesome choice, imo. C# is a bit more verbose than Lua, but it probably enables mods of higher quality.
It's not out yet, but some keys get distributed to chosen people. Sadly, I'm not one of those.
There are lots of asset packs for things like that. So you can get stuff done if you don't mind things not looking and not performing exactly the way you want, and don't mind your game having assets that people might recognize from other games!
The Unity marketplace has lots of things like that.
Only drawback is, you run the risk of players being able to identify all the readymades you used. Use too many, and your game will feel like an unoriginal "asset flip".
I would actually suggest that anyone interested in game engines give that channel a look, lots of good stuff over there.
Personally, i rather enjoy seeing new game engines pop up, however i would say that Paradox/Xenko/Stride is about as obscure as the NeoAxis engine (which also uses C# as their development language), even if some of the features seem nice. I'm not entirely sure why Paradox/Xenko/Stride was renamed that many times, though, it kind of hurts its recognizability.
As for the people asking about what engines to use, i think the other comments in this thread have some good arguments. My summary for which engine to choose would be as follows:
- In case you want to develop an FPS game or something in a similar genre AND feel comfortable with writing C++ for the performance intensive parts, consider Unreal (or if you just need something really pretty)
- In case you want to develop a game with an engine that will have most of the functionality that you'd need out of the box, a good asset store for the things that aren't included and if you're comfortable with using C#, consider Unity (UNLESS you need multiplayer, since currently the engine is slowly migrating across technologies and AFAIK they still didn't have a good networking solution)
- In case you want to develop a 2D game of simple to medium complexity, or want to mess around with some basic 3D stuff, consider Godot
- In case you don't necessarily expect to sell your game in the future, but would prefer just to learn bunches, consider writing your own engine, or using SDL/SFML/LWJGL or another solution like that
Of course, others might disagree, but personally i've found that only using the more popular engines makes sense, given the abundance of tutorials, blog posts, examples, assets and even the quality of the documentation, in most cases.
Here's another video by said YouTube channel, called "Choosing A Game Engine in 2021": https://youtu.be/rK6ulQaOpso
In case anyone has any information on what Stride does better than those other engines, or perhaps has a unique perspective on why using it would be a good idea, feel free to respond!
> - In case you don't necessarily expect to sell your game in the future, but would prefer just to learn bunches, consider writing your own engine, or using SDL/SFML/LWJGL or another solution like that
Make that "in case you never want to actually finish your game :)
The greatest pitfall with rolling your own is that you soon be stuck spending 90%+ of your time working on the engine instead of the actual game.
There's just too many moving parts involved and even libraries like SDL only get you so far. I'd VERY strongly recommend against developing your own game engine IF your goal is to actually make and finish a game.
In case it's more about the learning experience and finishing a game is just nice to have, rolling your own engine is fine.
There's a big difference between "writing your own engine" (a bottomless pit of features your game probably doesn't need) vs writing a 2D game with a framework like SFML.
Engines like Unity can be nice, but they can also be clunky and opaque and get in your way, especially if you're doing something outside the norm. It can be simpler to just write the code you need, as you need it. That said, of course you should use an off-the-shelf engine for a 3D game if you ever hope to finish it.
> Make that "in case you never want to actually finish your game :)
I disagree. People overestimate how much of a time sink "writing your own engine" is. Using a generalized engine often suffers from the second system effect, in the end reducing your flexibility while not really saving you that much time.
From his perspective as an experienced developer, it took 3.4x more effort to implement a very basic project versus using a fully featured engine. And that's ignoring the editor part, not to forget.
I'd call a factor of 3.4 quite significant. In more general terms, it's the difference between actually finishing a game in a 3½ months vs a full year. In other words, you could finish 3 projects in the time it takes you to fully handcraft one, with the added advantage of OOTB multi-platform support. So reality seems to disagree with your "not really saving you that much much time" assumption.
It's the small conveniences that add up quickly: exporters/importers for assets, in-game editors, readily available prefabs/blueprints for all kinds of components, stuff like that. Of course it's not rocket surgery to use SDL and a handcrafted engine for a quick little project.
Yet, I've witnessed far more game projects die (especially by beginners) that went the handcrafted all-the-way route versus people using game engines.
Rolling your own is mostly a fixed cost endeavour. Taking 3.4x more time on a week long project isn't that bad when considering that most projects takes years.
And then you have to consider that the guy got 10x the performance on his hand rolled project, getting unity to similar levels of performance would likely take way longer than just using his own engine.
> Yet, I've witnessed far more game projects die (especially by beginners) that went the handcrafted all-the-way route versus people using game engines.
If you don't have the skills required to make your own game engine then you shouldn't do it. You shouldn't learn how to make a game and how to make a game engine at the same time.
I think it depends very much on how much engine you need.
A simple renderer (in 2d or 3d) is a fairly low time investment assuming you are a strong C / C++ programmer.
However every thing you add on top of 'draws stuff to the screen' adds at least the same amount of time again. Physics, animation, editor, UI, audio, streaming, packaging, asset import, networking.
Plus each one of those new systems may require new features from the existing ones in order to work (eg animations will need asset import support, shader support, and renderer support).
Writing a complete engine that works across all major consoles plus Windows and mobile, with all the features designers might need including editing and scripting capability, is a HUGE time sink.
If you intend to sell your game, stick with Unreal or Unity and save yourself a lot of time and hassle.
Yep, overall i agree with you. Of course, there are a few people who actually write their own engines AND finish their games, but they're probably in the minority.
I guess what i tried to say is that if your goal is to make money, then there are lots of ways to save on time and effort, in the case of gamedev that being using existing technologies and solutions, possibly even assets (as long as you don't mix art styles that don't match).
It's much the same as wanting to produce a corporate CRUD web app vs writing a personal blogging engine for a passion project or simply for own amusement. Both can result in finished products, yet the motivations for each would be drastically different.
> Of course, others might disagree, but personally i've found that only using the more popular engines makes sense, given the abundance of tutorials, blog posts, examples, assets and even the quality of the documentation, in most cases.
But then I have to use their languages and abstractions instead my preference, Haskell. Can't throw the baby out with the bathwater!
Well, I guess Haskell makes rolling your own engine just library composition and standard abstraction, so the decision making in that world is definitely not the same as mainstream gamedev.
That is a wonderful channel, I can attest to that. Superb content, and he's focused on one thing - testing, reviewing and recommending game development tools.
Do we not have enough of these fully featured game engines? Game development has become so bloated these days. You need teams of hundreds or even thousands of people to create a full game. In the PS1 era some of the best games were built by a team of a dozen or so people working for 1-2 years. Instead of focusing on graphical fidelity I think we should be focusing on lower development time, gameplay features/diversity, stability/portability and implementation. I have yet to see a proper open world game (Think GTA but you can enter every room in every building) with good draw distances that don't suffer from horrible pop in.
Also how about a game engine where it's easy to build games? The WC3/SC2 world editors are great examples, you can get started and start building stuff from the start. Even though it's an engine made for making RTS maps it's modifiable enough you can create FPS games in WC3 if your willing to put in the effort. https://www.youtube.com/watch?v=gwtteOIksbo
> Game development has become so bloated these days. You need teams of hundreds or even thousands of people to create a full game
Hard disagree. The accessibility and availability of free resources is higher than ever before for solo devs.
AAA games take large teams because they have more content, and a larger diversity of content than older games.
> Instead of focusing on graphical fidelity I think we should be focusing on lower development time, gameplay features/diversity, stability/portability and implementation. I have yet to see a proper open world game (Think GTA but you can enter every room in every building) with good draw distances that don't suffer from horrible pop in.
That's because it's a difficult problem and machines don't have unlimited resources. Draw distances are a graphical fidelity problem, so I also find it ironic that this is your first idea.
> Instead of focusing on graphical fidelity I think we should be focusing on lower development time, gameplay features/diversity, stability/portability and implementation.
> I have yet to see a proper open world game (Think GTA but you can enter every room in every building) with good draw distances that don't suffer from horrible pop in.
I don't think these are compatible. The majority of man-hours are spent creating graphics, not programming features.
> The majority of man-hours are spent creating graphics, not programming features.
Technically, yes but it's not as heavily swayed as you might think. On the four AAA projects I've worked on, it's been roughly 60-40 art to programming/technical design (think level scripters). There is definitely a sizeable amount of the man hours spent by engineers writing C++
Programmers writing C++ to support graphics also goes in the art bucket though. If there is a performance bottleneck on art, or if you need to load/unload art resources since they take tons of memory, or if they are tweaking shaders, then that is still work done to make the art.
You have to do it to support modern game graphics. It is something they could skip if they didn't do modern game graphics. It is a cost of modern game graphics. Doesn't matter if you disagree, this is a fact.
So if you divide it up, how much work is done to support the art and graphics of the game, and how much is done to support the gameplay, you get a much greater ratio art to game than 60/40.
Sounds like you might be interested in Roblox - fully solved out of the box multiplayer, Lua based development, no shader access or particular graphical fidelity concerns. Some of the most successful games of the current era were developed by single teenagers.
Games requiring a lot of custom code are really under rated among indie devs. Most tries to do stuff that are really easy to do, like 2d platformers or shooters or puzzle games, but hard to code games that gives experiences you can't get in other games seems like the easiest way to make a successful game with few people nowadays.
There are still tons of games made by tiny teams, even moreso than at any point in the past probably. The indie dev scene is huge, and some of the best games of the last 5 years have been built by teams is 10 or less.
Actually fully featured game engines like Unity have made it possible for smaller and smaller teams to build bigger and bigger games. Not sure where you're getting your numbers from.
C# is nice to program in, but I remember the unity garbage collector used to give me anxiety, it was a nightmare. Every tiny thing you do you have to second guess because it might allocate behind the scenes and you get these awful performance hiccups if you miss too many of these
How long ago? Compared to 5 years ago C# performance has improved dramatically, and you have more tools available to control memory usage.
That said, if you are trying to make a competitive first person shooter than never dips below 144fps, C# may not be a good choice. But there are popular competitive shooters out there using Unity, like Tarkov. But who knows how much pain they went through to get the performance they needed?
Its really not a big deal. Just preallocate as much as you can behind a load screen, and use pooling on your tight loops. You'd be doing this in any language, anyhow. If you really want to go overboard, C# has Span<T> now, if you want to do your own arena allocation.
At least in Unity, the profiling is fairly well established so its easy to hunt down allocations.
I love Godot but it’s a stretch to describe it as multi-platform when it doesn’t support any of the consoles. Especially when compared to Unity or Unreal.
Unity and Unreal are giant resource-hungry game engines. There are plenty of people making games who only need a fraction of what those two provide. Engines like Stride and Godot -- or any number of other smaller engines -- can be easier to work with if you're resource constrained or looking for something more simple.
It depends on the game. Unreal for example is optimized for large teams, and collaboration between different kinds of professionals (programmers, artists, level designers etc.). If you're doing a one-person project relying on procedural generation and pixel graphics, you might be more productive with a much simpler game engine with a much shorter code-build-run loop
Unity is on the same league as Unreal, with the difference to target developers that rather use C# instead of C++, other than that the complexity is the same.
This subthread was in response to skohan above who said:
> If you're doing a one-person project relying on procedural generation and pixel graphics, you might be more productive with a much simpler game engine with a much shorter code-build-run loop
So I presumed you were saying "Unity is as bad as Unreal in these regards."
Exactly because of that unless there is a whole team of designers, level builders and artists alongside the core devs, there is more ways to spend time than getting a PhD level knowledge on AAA engines capable of producing Hollywood class 3D movies.
I have tried out Godot and many, many other game engines in the past. They aren't there yet. Even as a hobbyist, I find Unity much more easy to use, and even still I'm tempted to learn Unreal simply because it seems more powerful and well architected under the hood.
They are where Unity 3.0 used to be around 10 years ago.
However Unity now is capable of supporting such kind of productions, with the respective increase in learning complexity and development teams scalability,
Because 99% of people using these engines are hobbyists and want to use something that works for them.
I personally prefer Godot, its node structure makes sense with my mental model of the games I tinker with. And it has enough there that if I did decide to ever finish a game, I could. That's all I need.
If the Bugatti is free, why not use it? Unity is very easy to use, and it gets easier over time. They keep making paid features free, and once ECS is mature (in the UI, I know it's production ready), I think it's going to have a huge positive impact.
Same? If helicopters and fuel would be free, I bet everyone would fly one to store. Safety is the only concern here, and it is irrelevant for the topic.
Money, obviously. This engine has a permissive license, MIT.
The question is rather what one can conveniently do with it, in the context of the given game, when compared to a big-name engine.
Possibly, for non-demanding games, smaller engines are a good tradeoff between performance/features and cost. Godot, for example, is free, but AFAIK it doesn't have a very efficient culling (yet)¹, so for smaller games, it may still be worth the savings.
Why use Linux or not Solaris? Wait... Solaris is not really that relevant anymore.
I actually get your point but I don't think you should frame the differences as a sales pitch. Most probably people interested are engineers looking for some innovation. So the question is not "why use this" but instead "why is this interesting"
When Discord was relatively new they had a comparison table with Skype, TeamSpeak and other platforms. As a long-time TeamSpeak user, I found that very helpful at the time, because it helped me understand what Discord wants to be.
With Stride it is kind of similar. I don't expect an open-source engine to have the same set of features as Unreal, but they should tell me what they think they are good at! Especially in comparison to Godot, which is a direct competitor in the open-source landscape.
The page talks a big game, and makes big claims. So honestly I'm a bit sceptical :/
> Apple is extremely friendly to developers targeting the Apple ecosystem.
Yeah, I don't know where the hell you get that!
Do they offer emulators for non-Mac developers to target their ecosystem?
Do they make even simple development onerous if you are on a Mac and do target their system, but have the audacity to want to share the app with someone else not in the same room with you?
You want to make a free app for your business targeting our ecosystem? Pay us bitch! Also, while we're at it, pay us every year from now on! Whoa! You also want to put it on our store, pay some more you fucking pay-pig!
> Plus, unlike Android, they actually provide tons of tooling for game development and graphics programming on iOS.
... read, we are so locked into and starved for hardware options that it is easy to release a few libraries that will work for your app ... for now! Has your business not changed at all and your app doesn't need any special privileges ... but it has been more than a few years .. haha! Go fuck yourself, sincerely Apple!
> Google tells you to clone github repository from Vulkans shaderc.
Apple makes you get into a personal relationship with them. I am not sure that is much better!
They create a narrow space where it's possible to make money developing for their platform, but there's a huge risk that:
a) they will make a decision which makes your product no longer viable, or
b) they will decide to replicate your product as a 1st party offering and render you redundant (e.g. tile)
Adopting open standards like Vulkan would be the single best thing they could do to support games on their platform. Games are extremely high-investment, and having to develop against a second back-end like Metal is a perfect reason not to support a platform.
Apple's friendly to developers as long as they are willing to stay on the reservation, but there is no reward for doing so.
I might be wrong but from what i read on the internet, MacOS don't provide direct access to GPUs, you have to go through the OS GPU API to do your GPU computation.
On Windows and Linux, there is no abstraction, OpenGL and Vulkan access the GPUs directly. I'd say it's safer to go the MacOS way but it's a bother for those who want a unified API
Doom 2016/Eternal shipped with Vulkan and they are two of the best optimized games ever made.
I don't buy that Vulkan is not a first-class choice for graphics. To the extent that it has issues, it's only because of (developer hostile) lack of support from major software vendors.
I spend more on eating out in a week than that yearly Apple developer fee (not ideal, I know). Cost/benefit. At some point you realize you're going to die and that you can essentially buy more productive time by paying money.
Most people starts out as students or similar with basically no budget at all. To them paying fees to just get others to run your program is a huge hindrance, which is why it is developer hostile. It isn't hostile to full time developers who work on established products, no, but it is hostile to the next generation of developers who are just starting out and experimenting with things.
Forcing you to drop everything and do it Apple's way is not friendly.
Forcing you to buy specific hardware and banning virtualization to do builds is not friendly. Cloud builds is a huge pain. You essentially have to rent full macs from MacStadium.
You can compile Windows and Android apps on Macs, Windows, CromeOS and Linux. There's no XCode like restriction and there's not the same OS virtualization restriction that required a hardware purchase.
It's a chicken/egg problem. There are no games on Mac because nobody plays games on Mac, and nobody plays games on Mac because there are no games on Mac.
Only Apple has the power to break this cycle by throwing money at game developers to reduce the financial risk (same way Epic does to get games into the Epic Game Store for instance).
They're kind of trying to do that with Apple Arcade, but from what I've seen they don't really understand the market enough to make an interesting offering.
It's insane to me that they're failing so badly at it: Apple's amazing at building brands, but gaming is huge with people under 30, and it might get harder to sell people a computer you can't run AAA games on.
Google could have eaten iPhone's lunch with gen Z with Stadia if they invested in it properly, but they didn't manage to make it work
It's not a chicken and egg problem. It's Apples fault/intention.
They had really bad support for OpenGL and wanted developers to use Apple's Metal API.
But developers stayed on DirectX (Windows-only) or OpenGL/Vulkan for Linux/Windows/Android crossplatform.
It just wasn't economically viable to develop for Mac.
The importance of cross-platform 3D-APIs for game development is vastly overrated though. The problems of the Mac as gaming platform are much more "holistic" (but yes, in the end it's about the economical viability).
The way I see it, unless you're developing exclusively for Apple platforms, it's not worth the effort to build something with Metal. There are translation layers like MoltenVK that can help, but that still requires a lot of effort for what is likely a very small market segment.
It's not that hard. With SDL2/GLFW and MoltenVK you are 90% of the way to a cross-platform codebase.
That said I can understand why there's not a lot of investment in mac, since Apple's shown to be very developer-hostile as far as games, and the market is pretty small outside of mobile games which are kind of a separate thing.
There's some potential with m-series processors - now there's basically one SOC to target for everything from an iPad to a desktop, so it's sort of like consoles where there's a very consistent hardware target to develop against.
* Animated character * Top down view * Grid based floor * "Default" RTS/MOBA physics
I've tried both Unreal and Unity but I've always found myself blocked by having to find out how to make something look like water, how to make an animation sync with movement, how to customize movement to something already familiar, etc
This means I can't actually make a game if I first don't make my own pretty much everything
I think that more than game engines, we need game frameworks that provided game designers with presets that present "solved" game mechanics, like water styles, ground tiling, precise character animation for any view angle, character movement, etc
It would be nice if we could have a "democratization" of video game development anytime in my lifetime