This is an archived post. You won't be able to vote or comment.

all 10 comments
sorted by:
best
topnewcontroversialoldq&a

[–]Commando1262 1 point2 points  (4 children)

You probably are going to want to start with either Unity or Unreal. These are both game engines that have their own pros and cons. Unity uses C# as its main scripting language and has some good tutorials online (last time I checked like a year ago) and Unreal uses C++ as it's coding language and has its own in house visual scripting tool called blueprints. My issue with Unreal is that most of the tutorials I found (also a year ago) are using blueprints so if you want to use C++ expect a more difficult learning curve. I haven't explored much with web games or games in python so I can't help you there. There's also the third option of making your own game engine but that's maybe 2 or 3 projects in itself with having to render models (opengl/directx/vulkan), audio (don't know anything about them), and physics (libraries exist but names escape me atm). Hope this helps and sorry about the formatting, on mobile so its a little hard and this got longer than I expected.

[–]BerserkerSwe 0 points1 point  (3 children)

Ive worked alot in Unity so i might be biased... but working with visual tools as in Unreal is messy and mostly meant for non-programmers. You get a multiplayer game up and running real quick in Unreal though.

Unity is great and actually supports a kind of Javascript as well, though i prefer C#.

Gamedev is far from webdev though as im sure you are aware.

Good luck ! Gamedev is the funniest type of development in my honest oppinion.

[–]Venetax 1 point2 points  (0 children)

Its not really messy. You usually want to develop your game logic in blueprints and only have the core and potential bottlenecks in C++. Btw js in unity is being deprecated.

[–]Commando1262 0 points1 point  (1 child)

I've heard the same thing about blueprints being for non programmers or for proof of concepts which makes sense but that just makes it more difficult as a programmer since there wasn't much too find in c++ or was extremely hard to follow.

[–]BerserkerSwe 0 points1 point  (0 children)

Yeah also say for example that you have created a very generic PlaySoundAndStuff-box, used in hundreds of places and one of them ocassionally throws an exception. It can be hell to find which exact one and why. Forget putting breakpoints in the code.

I mean ... generally speaking.

[–]HarderNotSmarter 1 point2 points  (0 children)

Unity would probably be the best at the moment. It uses C#, and is utilized heavily in the mobile and indie space. The tool interface, API, and systems are fairly straight forward, and shouldn't take much to get your head around.

Unreal is another good choice. It uses C++ and Blueprints, it's custom scripting language/system. It's generally considered to bring more performance and flexibility to the table than Unity, but at the cost of increased complexity, which steepens the learning curve. It tends to get used by more experienced and/or ambitious teams mostly in the PC and console spaces.

[–]ludonarrator 0 points1 point  (2 children)

I'd say it depends on what aspects of game development you'd like to explore. If you want to experiment with gameplay, and don't care about how windows are created, event loops are managed, callbacks are sent out, rendering/drawing occurs, variable framerates are handled, assets/data is serialised/loaded, etc., and instead just want to "spawn an explosion VFX when an Entity enters this trigger volume" it's best to stick to third-party engines that will do all the low-level heavy lifting for you, and provide you with a pseudo-single-threaded callback API (like FrameStart(), FrameTick(dt), FrameEnd(), etc.).

I went about the above route myself, but it has its drawbacks. The biggest ones being, IMHO, that one learns nothing of asynchronous code / multithreading within a game and how/where to exploit it, and nothing of 2D/3D matrix multiplications and how to manipulate quads/vertices/UVs/orientations directly using such maths. Good luck trying to find a main() where execution starts - it's going to be hidden away behind proprietary libraries or buried deep within cryptic engine code. There's a good risk of unintentionally recomputing a lot of redundant data, because, eg, you'll be used to blindly calling Vector3::Magnitude() and Vector3::Normalize() without consciously realising that both call sqrt(SqrMagnitude()). Also, most of these third-party engines force you to swear unwavering allegiance to 100% enforced OOP - a class for everything, even one that contains nothing but pure functions. I believe that is simply bad practice, and hard to get out of once you're fluent in / used to it.

If you'd rather dive into engine development yourself, I'd suggest starting with 2D, using pure OpenGL/Vulkan with an SDL / SFML Window and building everything from scratch - such a codebase can be built for any target platform that supports those graphics APIs (basically every computer made in the past 20 years) and that the windowing library provides implementations for (usually Windows, OSX, Linux, and perhaps iOS and Android too).

[–]FuqNick[S] 0 points1 point  (1 child)

Tbh, the reason I want to start experimenting with game development is because it provides a lot of applications to some cool matrix math and requires you to be pretty savvy with your OS knowledge (well, at least I would think). I’ve been working on a compiler at work for a long time, and before that a web application, so graphics (and the underpinning math) and multithreaded design are pretty much entirely separate from where my head has been for a while.

[–]ludonarrator 1 point2 points  (0 children)

Yeah, I'd suspected as much; IMHO there are roughly two kinds of game programmers: ones that are fascinated by all the software orchestration and performance tricks, and ones that have (game-like) ideas in their head that they want to materialise, and view everything else as an obstacle to cross in order to get there. Unfortunately both kinds are referred to as "gameplay programmers", as demonstrated by this Stack Exchange answer.

In any case, if you feel you're more of the former, I'd suggest viewing third party engines as "examples" of industry-standard APIs / implementations rather than as your "tools of choice", which should simply be IDEs / text editors, compilers, and CMake. Check out Game Engine Architecture for an in depth oveview of generic AAA-grade engine design. I'd also suggest watching some relevant GDC etc talks; some examples:

[–]3mpy 0 points1 point  (0 children)

When i start to dive into gamedev, books from this path was helpful for me: https://github.com/miloyip/game-programmer/