Which programming language did you choose and why?

[Bad Sector]

I was talking about a different kind of polygons, which have 1,000s of coordinates themselves (CAD). But this doesn't matter for this topic.

Ah i see. I was indeed thinking about polygons in the game sense.

But if you don't believe me you can try to compile this in Qt and see which is faster, the OpenGL or the Qt rendering
https://doc.qt.io/qt-5/qtwidgets-graphicsview-chip-example.html

Well, i certainly believe you that it'd be slow... QGraphicsView is stupidly slow, i used it recently in a tool at my last work (largely written by others, i wouldn't use Qt myself in the first place) and i think it'd be both easier and faster if we did all the drawing manually :-P.

 

[vlzvl]

But if you don't believe me you can try to compile this in Qt and see which is faster, the OpenGL or the Qt rendering
https://doc.qt.io/qt-5/qtwidgets-graphicsview-chip-example.html

I might be missing something here but isn't Qt already using OpenGL internally?
How it can be faster than OpenGL then.
Just asking, do not know about Qt in any way.

 

[The Avatar]

Scripting in Unity seems to be like a game that allows you to change every aspect, as long as you are able to, but not a real programming tool. At least many people use it like that, that's why so many games look the same.

I never got into it tutorials because the concept looked so restrictive and lame, and when I saw how crap the games run I never tried again. For example Kerbal Space program, when the scene had loaded it still took several seconds until the game accepted mouse and keyboard input.

Also with any tool this type where most functionality is already inbuilt into the objects, you end up spending an awful lot of time just with trial and error because you don't know when something will actually work. This totally sucks, just like working with HTML, CSS, XAML and such stuff.

I have some issues with modern Unity, but the engine itself is fine. The truth is that sometimes you really need to dig down and make your own systems instead of using the built-in ones that Unity provides. For example, Unity has a pathfinding and navmesh system, which works okay, but I needed to make a customized A* system that fit the specific needs of my turn-based game better- so I didn't use the built-in system. This really goes for any game engine which seeks to provide generic solutions to fit a wide variety of different game types and genres on different platforms.

As for performance, it's almost guaranteed to be the developers fault for not profiling the game enough, or understanding how to optimize.

 

[Rincewind]

I respect your experiences with Unity, of course (and my experience with it is exactly zero!), but what about these titles:

Shadow Tactics: Blades of the Shogun
Inside
Pillars of Eternity 1-2
Firewatch
Kairo
Tyranny
Tacoma
Pathfinder: Kingmaker
Gris
Ghost of a Tale
Return of the Obra Dinn
Pathologic 2
Wasteland 2
Might and Magic X: Legacy
Endless Legend
Endless Space

I have played about half of these myself and they are wildly different games, if no one told me they were made with Unity I'd never guess. So the argument that it's not really customisable doesn't hold water at all, in my opinion. Maybe really small 1-person indie operations keep re-using some stock assets or something, but that doesn't really tell you anything about the possibilities and the quality of the engine. Or you're only referring to the scripting? Most likely these games use a combination of scripting and their own lower level stuff, that's true.

Shadow Tactics was a particularly impressive and unique RTS stealth game and apparently they've even used the pathfinding algo that comes with Unity (check out the linked article). Similarly Pathfinder, Pillars, WL2, MMX and the Endless games, they're wildly different and pretty much the AAA-tier of the non-AAA segment, if I'm making sense.

So, without having any experience with Unity myself but having lots of experience with writing my own libraries, it's just huge amount of grunt work and there's always a risk that after spending much time on it you'll just end up with a half-assed homegrown version of what 10-50+ other devs have come up with and polished over 5-10 years. Of course, sometimes it's just interesting work or you just might say, yeah fuck it, I'll write my own anyway because it's fun or I just want to learn etc. You can't always be rational, after all But approaching it purely from an effort/benefit ratio, Unity seems to be a very practical choice for a lot of non-AAA games, if nothing else. I don't think I'd even try writing my own engine unless I had some extremely specific needs that are just impossible to achieve with it. One thing that comes to mind is streaming a large open-world without loading-screens (like most Piranha Bytes games), but apparently the guys iimplemented something like that in Firewatch:

https://www.youtube.com/watch?v=hTqmk1Zs_1I&feature=emb_logo

I'd be curious about the experienced game dev folks' opinion on this.

 

[Rincewind]

If you want to write professional C++ applications with minimal effort, there's probably nothing better.

Quite a few people would disagree with that statement. Especially the minimal effort part

 

[Rincewind]

Well, i certainly believe you that it'd be slow... QGraphicsView is stupidly slow, i used it recently in a tool at my last work (largely written by others, i wouldn't use Qt myself in the first place) and i think it'd be both easier and faster if we did all the drawing manually :-P.

Yeah, so to the OP, what you're really comparing here is Qt's software renderer against its OpenGL backend if I'm not mistaken. So the results aren't really indicative to what you can do with coding against the OpenGL API directly.

 

[Rincewind]

But more importantly, the graphics API isn't really that important - it is the algorithms that matter most and by far and you can transfer that between graphics APIs easily. Unless you are working on a minimalistic renderer, chances are the code that works with the graphics API will be only a very small part of the renderer's code (and, fwiw, the renderer itself will be a small part of a game engine anyway). So you can use OpenGL and if your renderer needs better CPU performance (if you are GPU bound Vulkan wont help you, the primary reason to use Vulkan is because the driver is too slow for your calls) you can switch. Chances are by that time you'll also have a much better understanding of graphics in general so it'll be easier to learn Vulkan than if you started from zero.

Words of wisdom! (Can't do brofists yet, so I had to quote & reply :D)

 

[Burning Bridges]

If you want to write professional C++ applications with minimal effort, there's probably nothing better.

Quite a few people would disagree with that statement. Especially the minimal effort part

compared with what?

 

[Burning Bridges]

But if you don't believe me you can try to compile this in Qt and see which is faster, the OpenGL or the Qt rendering
https://doc.qt.io/qt-5/qtwidgets-graphicsview-chip-example.html

I might be missing something here but isn't Qt already using OpenGL internally?
How it can be faster than OpenGL then.
Just asking, do not know about Qt in any way.

QGraphicsView can toggle OpenGL at any time. I just found that it does not work great, is actually slower and seems only there to save memory (better usage of the GPU).

Afaik there is now also a Vulkan option but I did not have time to test it.

Native QGraphicsView and QGraphicsScene work well for what I am doing (2D CAD), and the performance is much better than AutoCAD which we are gradually replacing. But we are talking about completely different requirements, because I do not need to build a game but render technical drawings with millions of coordinates. If you want to make games, better stick with something like Unreal 4 or your own engine.

My point was just that with C++ and a good ecosystem around it, you may actually have less work than with lets say C# and the dll hell that ensues. C++ is harder and more confusing in its details, but the overall design is superior to all these late 90s type OO languages with their VM nonsense.

 

[BreadGrill]

I am using Godot. It's an open source engine with a python-like scripting language, but you can also use C# for scripts. I selected Godot through a process of elimination.

Godot appeared to have more of a 2D focus than other engines, which is something I wanted. But it didn't have C# scripting until version 3. You still have to translate a lot of tutorials from Godot script, but it is simple to do if you know C#'s naming conventions. And guess what? When you use a real language with a real IDE like Visual Studio, IntelliSense makes it easy to learn new parts of the API.

I also use Excel as part of the data pipeline. Excel has a lot of useful functions for highlighting and transforming data and Microsoft has created a great C# ecosystem for reading and transforming that data into JSON or similar to import into a game engine.

I like being able to use the same language for the whole project and being able to use advanced language features that scripting languages don't have.

If you want to create 2D games and use C# for everything, I'd recommend FNA/Monogame (open source XNA reimplementations) over Godot. Those were actually designed with C# in mind instead of just duct taping C# support onto an existing engine and its own Python derived scripting language. If you plan on supporting older or lower end systems and have a wider selection of multi-platform support, it's definitely a better option.

It might not be a complete engine in comparison, but there's a lot existing reference for XNA out there to get you started and you can easily implement support for a level editor like Tiled. I used Godot for a while but dropped it after having tons of stuttering issues with both sound and rendering on a lower end system. They recently did implement sprite batching in Godot (only took them 6 years) so it might be a bit better now, but if you read their updates, you can clearly see that they're focusing on 3D over 2D.

Using a framework instead of an existing engine has been better for learning to program in my experience. It feels like the right balance between control and ease of use.

 

[Bad Sector]

FNA is neat, around late 2011/early 2012 i made this to learn XNA for some job - it was made in VS2010 (the most awful version of VS) and only tested under Windows Vista (IIRC). A few years ago i learned about FNA and decided to try and see how compatible it was - and sure enough, i didn't had to change pretty much anything yet it worked under Ubuntu:

I'm not a big fan of C# but i always liked the XNA API: it provides high level enough functionality to be useful, but not to the point where it dictates how you should do things. The only annoyance i had with it was that its vector math library didn't really provide much functionality.

Having said that, i also remember FNA having pretty much zero support for development - you were practically expected to use XNA to develop the game and use FNA for porting. Has the tooling support improved since then (then being around 4-5 years ago)?

 

[Burning Bridges]

Those C# graphics engines are fun but the problem is that Microsoft will eventually let them die. Managed DirectX died long time ago and XNA will go the same route.

There was also a really simple implementation of SDL for C# and you could build 2D games with just few lines.

Games written in C# also have many issues with continuous operation because there is a garbage collector and such.

 

[Bad Sector]

Those C# graphics engines are fun but the problem is that Microsoft will eventually let them die. Managed DirectX died long time ago and XNA will go the same route.

XNA is already technically dead (it needs some very old version of VS to work - at least officially, i think there are workarounds to make it work in newer versions of VS), but we were talking about FNA which is an open source reimplementation of XNA. Microsoft isn't in any position to let that die as they didn't make it (and being open source, all it takes for it to be alive is for someone to work on it).

 

[BreadGrill]

Having said that, i also remember FNA having pretty much zero support for development - you were practically expected to use XNA to develop the game and use FNA for porting. Has the tooling support improved since then (then being around 4-5 years ago)?

You can now use the Monogame pipeline tool together with FNA or just load files directly for sound and graphics, instead of using the old XNA content pipeline.

 

[J1M]

I am using Godot. It's an open source engine with a python-like scripting language, but you can also use C# for scripts. I selected Godot through a process of elimination.

Godot appeared to have more of a 2D focus than other engines, which is something I wanted. But it didn't have C# scripting until version 3. You still have to translate a lot of tutorials from Godot script, but it is simple to do if you know C#'s naming conventions. And guess what? When you use a real language with a real IDE like Visual Studio, IntelliSense makes it easy to learn new parts of the API.

I also use Excel as part of the data pipeline. Excel has a lot of useful functions for highlighting and transforming data and Microsoft has created a great C# ecosystem for reading and transforming that data into JSON or similar to import into a game engine.

I like being able to use the same language for the whole project and being able to use advanced language features that scripting languages don't have.

If you want to create 2D games and use C# for everything, I'd recommend FNA/Monogame (open source XNA reimplementations) over Godot. Those were actually designed with C# in mind instead of just duct taping C# support onto an existing engine and its own Python derived scripting language. If you plan on supporting older or lower end systems and have a wider selection of multi-platform support, it's definitely a better option.

It might not be a complete engine in comparison, but there's a lot existing reference for XNA out there to get you started and you can easily implement support for a level editor like Tiled. I used Godot for a while but dropped it after having tons of stuttering issues with both sound and rendering on a lower end system. They recently did implement sprite batching in Godot (only took them 6 years) so it might be a bit better now, but if you read their updates, you can clearly see that they're focusing on 3D over 2D.

Using a framework instead of an existing engine has been better for learning to program in my experience. It feels like the right balance between control and ease of use.

I am familiar with XNA. It is a great API and I used it to build the skeleton of a game years ago. The reason I went with an engine this time is because my goal is to build a game, not to learn C#.

As good as XNA was, I spent most of my time with it building things like a UI framework, settings pages, draw call ordering, and a rudimentary level editor. Very little on gameplay code.

At the time that's what I was interested in. But now my focus is finishing a game.

I would be happy to use it in the future if I was working with someone that enjoyed building those tools, but I don't want that to be my focus when so much of it is available for free with an engine.

 

[toro]

Just my 2 cents.

https://www.tiobe.com/tiobe-index/

TIOBE Index for May 2020
May Headline: Programming language C is back in the number one spot
Java and C were already very close in April, but this month C surpasses Java again. The last time C was number one was back in 2015. We can only guess why C is number one again. One of the reasons might be the Corona virus. This might sound silly but some programming languages really benefit from this situation. Examples are Python and R in the data sciences area because everybody is searching for an antidote for the virus. But also embedded software languages such as C and C++ are gaining popularity because these are used in software for medical devices. On another note, it is also worth mentioning that Rust is really getting close to the top 20 now (from #27 to #21 within one month). - Paul Jansen CEO TIOBE Software

Basically C is on the rise again because of the embedded industry. God I love this language It's probably the only reason why I'm not completely insane yet.

Forget about C++! It has become a meme language with almost zero productivity which it's both alive and dead at the same time. The worst time investment ever.

That being said: The best start option is not to learn a language but to start using an engine (Unity or Unreal).

However if I would do a game then I would consider these options: 1) SDL2 + C Api, 2) SDL2 + Python or 3) SDL2 + Rust.

Edit: Rust is a piece of shit.

 

[Jasede]

I find SDL really great and when I tried to make a game with my ex (F in chat...) that's what we used because not only were the tutorials awesome, you also quickly learn good habits and how to bang out a game's logic. It's also a lot more low-level than if you used something like Unity. Which I prefer, but not everyone will.

 

[tiagocc0]

I find SDL really great and when I tried to make a game with my ex (F in chat...) that's what we used because not only were the tutorials awesome, you also quickly learn good habits and how to bang out a game's logic. It's also a lot more low-level than if you used something like Unity. Which I prefer, but not everyone will.

F


I tried several engines but I always end up returning to what I already know.. because of work. Since it is usually very simple 2d games, it works for me, I just need to finish one game now..
Since Qt has QML, which is basically javascript plus css, I made a little editor in game so I can make UI really fast (WARNING, some NSFW words there by the end of the video https://www.youtube.com/watch?v=AOcOvCgTuMU)

It allowed me to make some pretty good UI like these:
https://img.itch.zone/aW1hZ2UvNjUzNTA2LzM1MDg0MzgucG5n/original/z4rC0S.png
https://img.itch.zone/aW1hZ2UvNjUzNTA2LzM1MDg0MzYucG5n/original/hEyM4J.png
NSFW https://img.itch.zone/aW1hZ2UvNjUzNTA2LzM1MTExMTAucG5n/original/bPHtM2.png

I will see if I can add another video showing how fluid they are.

EDIT: NSFW https://www.youtube.com/watch?v=RW3tOFsrGlY

EDIT2: An tileset editor I'm making in game, in the QML editor I made in game, all very simple things.
https://www.youtube.com/watch?v=lluMW_i6DSk

EDIT3: Just one screen I forgot to show on the other video.
https://www.youtube.com/watch?v=7IKdFIP50Ro

 

[CaffeineConquistador]

You have good taste in women, tiagocc0.

 

[tiagocc0]

You have good taste in women, tiagocc0.

T H I C C Orcs are the best

EDIT: Testing dungeon generation https://img.itch.zone/aW1nLzM1Mzg1MTAucG5n/original/4FTGPn.png
Following this tutorial https://www.patreon.com/posts/hatching-in-1pdg-31716880
And his dungeon generator https://watabou.itch.io/one-page-dungeon

 

[overture2112]

Languages are fundamentally tools like any other and so you should use the best tool for the job, or more often, tools.

For example, I recently was working on a project where rule balancing was aided by AI players using a rules-agnostic monte carlo tree search approach (it has to be perfectly rules agnostic lest your biases or incomplete rules prevent it from helping you figure out what's busted or OP). This meant speed was of critical importance so I used Rust. Before I dug into it I actually wrote a small amount of the engine in multiple different languages and compared their performance and how easy it was to write. I can highly recommend doing something similar for your own projects.

On the other hand when I write the majority of my projects (eg. simplistic text adventures and card games) I usually end up just using Python because it's easy to exploit dynamic typing and code generation to implement game logic quickly.

In nearly every case, I separate the game logic and visualization into separate client and server applications. This facilitates writing different pieces in different languages, whichever is best for the job, plus makes multiplayer, debugging, etc far easier.

To give some more concrete answers though: I usually do game logic (ie. server) in Python, Rust, or Haskell and game visualizations (ie. client) in C++ (though usually as C with only a few extra features), C#, or just use an existing game engine like Unity/UE4 but only as a sort of dummy client that simply renders whatever the server tells it to.

 

[GarrisonFjord]

Do you count failed attempts?

C++ should be the language of choice, in theory.

It has all the right intentions:
"No room for a lower level language (except assembly)",
"Don't pay for what you don't use / low-overhead abstractions",
support for all kinds of abstractions (old & new: OOP, generics, functional,).

It is widely available:
Compilers for all kinds of platforms (OS & hardware),
libraries for anything you can imagine (+ can use C libs too),
been around for a long time and is as "mature" as a language can get.

In theory one can choose a subset of the language that suits one's needs.
Trying to learn "all of it" is impossible (esp. since it's a moving target now).

As Stroustroup said:
"Within C++, there is a much smaller and cleaner language struggling to get out"

I think, knowing C++ gives a much better understanding of software & hardware.

That said:
Python's idea of small core language + large collection of libraries,
is what I really want.

 

[Catacombs]

That said:
Python's idea of small core language + large collection of libraries,
is what I really want.

Go is getting closer to that.

 

[GarrisonFjord]

That said:
Python's idea of small core language + large collection of libraries,
is what I really want.

Go is getting closer to that.

Is it?
(I'm literally reading The Go Programming Language right now.)
From what I've seen, Go libraries are in the infancy stage, not even close.

 

[Catacombs]

That said:
Python's idea of small core language + large collection of libraries,
is what I really want.

Go is getting closer to that.

Is it?
(I'm literally reading The Go Programming Language right now.)
From what I've seen, Go libraries are in the infancy stage, not even close.

Go is a small, core language with plenty of libraries to accomplish day-to-day tasks, which (kind of) meets you request.

Now, when it comes to more niche uses, such as machine learning, statistical analysis, or even basic game development, Python remains king.