Why is programming games so difficult now?

Install Gentoo

>nodev rant: the post

download libtcod and make a roguelike
No gay gussied up fisher price gamemaker programs required.

>just learn the framework, lol

They try to do so much stuff that it ends up being impossible to do exactly what you want to do without ending up with a ton of bloat. How come a simple 2d mario-like game ends up being more than 100mb?

Attached: 1538700650762.jpg (399x384, 19K)

But not anything modern. Before this clusterfuck of frameworks appeared you could easily program something that could be compiled for both Linux and Windows with the proper abstraction layers. BlitzMax could compile the same code for Windows, Linux and MacOS and it was dead simple. it was garbage collected, object oriented, you could have modules written in C/C++. It was orders of magnitude faster than Game Maker, which was popular at its time.

>too many features for my pong clone, lol
ah so you're a Jow Forums "coder" and not an engineer

>uses a game engine
>complains about streamlining
Just make a game from scratch then autist.

>using premade game """frameworks"""
>not just iteratively building your own tech
you're not gonna make it

just stop
everything you want to do is just as simple as it was back then, it's even simpler now because engines have a ton of features that you can use right away, but you complain instead of looking for new tools and learning them

Well... why would I need "dependencies" for a Pong clone, in first place?

With what? There's nothing without a million dependencies that I can use that is not 10 years old by now

Attached: Game Dev in 2010.png (1853x870, 111K)

>why would I need "dependencies" for a Pong clone, in first place?
>window drawing and graphics are *magic*

>But not anything modern
GoldSrc/Source pipelines have always been a clusterfuck, I've heard similar things about Unreal Engine games. "Big" engines were always like that.

>With what?
OpenGL / Vulkan.
Plus SDL if you don't want to waste time on configuring input handling.

While your post is quite retarded I think there's a real point beneath all the drivel. I myself have serious issues into getting used to all these development platforms because it would take me quite a while to 100% understand the flow of the program. What order do these things happen, what affects what and most of these platforms require you to do some dirty hacks around some simple things. It's just so much easier to write code and know EXACTLY what is happening and where the problems might lie.
Now, everything I said above is also pretty irrelevant from the viewpoint of being productive. There's just no real point in coding stuff from scratch (even if you use libraries for graphics and input and so on) because it's just too slow, the tools these days are too good to pass up. That's just the reality, get used to it. I know it took me a while

>that username
this has to be bait

write games for consoles in assembly
thats THE solution

Because most code nowadays is written by incompetent freetard codemonkeys
I've ended up writing my own UI framework and basic game engine

Xamarin has been bought by Microsoft
It's that way on purpose and they additionally made MonoDevelop much worse than it was

is it open source?

>it's even simpler now because engines have a ton of features that you can use right away
It's less simple now precisely because of the new "features". I don't want sprites with arbitrary rotation and scaling.

Why isn't there a modern day solution that isn't an arbitrary clusterfuck of bloated frameworks?

Attached: it should be this simple.png (1191x708, 41K)

Yes, but it's not public since I haven't registered the domain name yet

>window drawing and graphics are *magic*

In the good old days you could just use POKE's to write directly to video ram, or declare a pointer to the right address and do the same thing. You could create an interrupt handler to read key down/up events and that was basically all the hard work. Even in the days of TurboC and TurboPascal it was easier to make things than it is today.

And what do I use for compiler/IDE? Not some old 32 bit IDE like DevC++, I presume

fucking retard noob autist you dont know shit
graphics has always been retarded on PC, all the way back in DOS era as well.
If you want control for your autist pong game you write a software renderer in C or assembly with syscalls for the final blitting.

What's your problem with SDL?

>Not using C
>Not using SDL2
>Not using VSCode
>Not using C# targeting .NET Core to manage cross-platform builds programmatically
>Not using jenkins to automate build and testing concerns
>Not having a large enough team to manage the project
>Not having enough skill to even get started

Its a fuckload of work either way, but the above approach is much more flexible, gratifying and "out of your way" if you have the balls to attack it. You really need to go to the bottom of the abstraction tree to make it the way you want. SDL2 is merely a scaffold of functionality to get you started quickly on network/input/audio/graphics. Consider it a gift from Valve. Eventually, you could replace this library with your own functionality and wind up with a 100% custom, pure C game.

I lost interest in programming around 2009 to 2010, so I'm out of the loop but not a complete retard

>*teleports behind you*
>heh nothin personnel kid

Attached: 2_mojangjpg.jpg (1200x1200, 103K)

Because it's rubbish

Attached: why is sdl bad.png (638x127, 11K)

For games particularly, things are easier now than they used to be I think. The problem that annoys me is that you still can't easily make mechanics that games had in 1990 even with these new engines - instead you get some buggy half-working mess.

I was messing about In the newest godot, and I got the Rondo of Blood style of jumping working decently enough. However, the new sync to physics just freezes the object using it totally so I can't enable it. It isn't like I am doing anything fancy, I am just using move_and_slide. So, moving platforms are still fucky. Okay, what about one-way/through platforms? They don't work well. They cause collisions at bad times, and the corners are all sorts of broken and cause problems like sinking into the ground. Trying to do these features manually is a huge pain and there always ends up being an issue for me at least. Lots of headaches with comparing bounding box edges or trying to use raycasts.

>And what do I use for compiler/IDE?
Holy fuck I'm not going to spoonfeed you, if you have to ask questions like that don't even bother.

Get on my level.

Attached: languages.png (511x536, 36K)

I see. Maybe you should this dream of yours and return to flipping burgers or whatever you can do with that brain of yours

just use SFML and C/C++/Java you dipshit
dont be lazy, build it yourself like you talked about in the start of the post

>some stackoverflow question from a retard who forgot to free something
That's like saying C is bloated because you're too retarded to free the memory you allocated.

Attached: answer.png (699x335, 45K)

love2d my nigga

love2d.org/

Attached: whale.png (96x102, 4K)

Was literally about to post this.

To elaborate since OP seems entirely retarded
-The best IDE is Vim, but since you are a winbaby you should just use Sublime Text
-You use a compiler to compile the C/C++/Java code during development stages, then you build an .exe when finished with the game and want to ship it out (I suggest TinyC Compiler or GCC running through Cygwin)
-SFML isnt the only graphics library, you can also use OpenGL and Vulkan (look into the pros and cons of all of them and pick your poison, just keep in mind that OpenGL is supported across the most platforms)
-If you dont know which language you want to use (given the graphics library you choose supports it), DOOM (original 1993) was written in C (so pick it if you want to use a language that has been around for long enough to be extremely expansive), DOOM (new 2016) was written in C++ (and most of the current triple A games too, so pick C++ if you want the most support), and Minecraft was written in Java (so pick Java if you like simplicity and dont mind verbosity)

>Godot
Yeah no shit. The user experience is terrible and everything is confusing and unorganized. Use game maker like the rest of "I wanna make games where do I start" kids.

Qt is gay
use wxWidgets

Why? Qt is easier to dev for/on more platforms like Wangblows.

Do I need to compile anything from source? Because I have very little desire to do so

Attached: sprite.png (1322x789, 50K)

Based libtcod.

I like it more when the program feels like part of the OS
but i guess everyone has his tastes

>I learned X
>WHY ISN'T EVERYTHING LIKE X

I think we need to teach people how to build better abstractions that aren't just leveraging some magic wand approach like garbage collection. Being able to properly black-box difficult functionality (aka shit you forget to free memory on) and re-use it trivially everywhere is the absolute holy grail when it comes to this stuff. Then, you repeat the fucking process again. And again. And, before you know it, you are calling things like Scene_Finalize() everywhere, and you don't have to constantly think about how that one method invocation results in 5000 lines of C being called. Code that took months to perfect is now being used in hundreds of discrete points in your codebase, leveraging your human effort by orders of magnitude. Getting this right can make you a billionaire, getting it wrong (aka leaky abstractions) can make you a plate of shit spaghetti code.

It's literally never been easier to make a game.

no

lrn2google

Google will return nothing but a bunch of frameworks written by people who look like this

Attached: download.jpg (189x267, 12K)

Is a good idea to read "The C programming language" then hop to some basic book for C++?
I want to try gamedev outside general purpose engines like UE4, Godot and Unity (this one is the one I know well)
Also I want to grasp something about enginedev

Why are all AAA devs putting delay on inputs on all their games these days? Like the only thing I can think is they wanna get gamers ready for stream box consoles

i cant even

what are you writing that in?
does it compile to exe?

Are you talking about delay on consoles like RDR2?

Look, user, if you don't want to learn a massive framework, you can still use simple libraries tailored to game development, like SDL or SFML. They're still out there.

>And what do I use for compiler/IDE?
Compiler: GCC or Clang.
IDE: Your favorite text editor.

>I can't read and/or don't know what tutorials are
ok
>I think that I should be given control over basic rendering functionality on my system even though I have no idea how that system works, and have no idea about the most basic concepts like shading, especially if that functionality is already readily available
ok
>I bitch about problems instead of overcoming them because the world doesn't fit my imagined reality, I reject reality and substitute my own.
ok
>I will complain about a plethora of features available to me even though they make my life easier (try cross compiling for different configurations of hardware, drivers and operating systems and then say the same thing again)

here's the beans, look at WHAT you want to accomplish and not the HOW you want to accomplish it, the moment you step a little bit back and do some design you will instantly be able to do more with these programs.
also if you're complaining about learning an IDE being too difficult I think you should look into social studies, they take sub 70 iq people all the time. Literally takes like 2 hours dude what the fuck

Attached: 1528931609139.png (500x505, 194K)

>love2d.org/
>making a presentation based project in a code first fashion

Attached: wut.jpg (260x261, 21K)

>also if you're complaining about learning an IDE being too difficult I think you should look into social studies
Not OP, but I personally dislike most IDEs myself because they're overly complex. Do you know what I use instead? A fucking text editor.

Blitzmax
Yes it compiles to .exe

Attached: Blitzmax.png (1122x707, 58K)

Wow that's amazing

>lua

This is really nice. I did something like this once. I had a basic graphics engine with some functions that were exported to Lua. I then made a game using it, only once. The source code for the game itself looked like this. It's a decent approach, if you ask me: no framework hell. No dependencies. Nothing.

Attached: lua.png (793x863, 39K)

>he's too retarded to follow the Godot start up guide
>he's too retarded to read the Godot documentation
What's it like to have single digit IQ?

I'm not going to read anything written by someone fed with ONIONS

Attached: 1523035312122.png (1024x1387, 1.28M)

holy fucking shit that looks awful

>no framework hell
Very good
But in this case you created your own hell all by yourself

Looks like the Yandere Simulator source code tbqh

Modern opengl is 10x more complicated than older opengl, vulkan is over 100x more complicated than even that.
Tools in general have been becoming more and more complex as they target large teams of devs, but there has been fewer and fewer attempts to target small or even lone devs. Note that back in the days, videogame developers were mostly very small teams, even on AAA projects of the day, especially compared to today; hence the shift of focus but also the fact that there is no conflict in acknowledging that it has all become so much more complicated.

No worse than the typical python "app"

It was so simple I used windows notepad to write it

I used to implement a crude way of "serialization" based on a binary format, which means whenever I changed the map format or anything in the class fields I lost every map/save state. I did that because it would be faster than implementing a text-based parser or whatever

Attached: Serialization.png (1135x861, 45K)

Modern OpenGL is very simple after you've made a few helper classes for VAO/Buffer/FBO/Texture handling
If you use OpenGL 4.5 with DSA then some parts are even simpler than the old immediate mode stuff

>godot
Just use LOVE

just found this for you OP

8bitworkshop.com/

>.bmx

Attached: _88116001_gettyimages-2177077.jpg (976x549, 56K)

I want to implement save-states like this

Basically there is going to be one save-state space for every map or "scene". Entities can have properties that point to other entities and have children/parents (an inventory, for example), and before I write everything to the save file I generate a "flattened" version of the entity tree to generate ID's (they are going to be something like the name of the scene the entity is in + its place in the list), and so I write that down to the save file. Then, when I load the save state, I'll have a list of properties that I'll have to dereference, and then I pick the correct entity from a flat entity dictionary consisting of the entity and its ID.

So it's a regular text file, but it will have one-time-pad encryption to prevent people from editing it.

Attached: Serialization.png (1272x975, 84K)

It's because games are becoming much more complicated
>programming embedded devices with microcontrollers is easier than programming a simple game
Nothing is stopping you from writing your game in SDL/OpenGL/whatever. Old and simple tools weren't purged from existence, you can still use them.

t. never used opengl

Yes but won't the operating systems stop running them altogether? Like, if I generate a game that is a win32 application... how would I distribute it on Steam, for example?

You have no clue how otp works, retard.

otp is literally the easiest encryption scheme in the world retard

>In 2009 all you had to do was download an IDE/Compiler like BlitzMax or DevC++, type in your code, hit build and run, and there you go, you have an application running in a window. You could then load and draw bitmaps and so on. You could then implement a simple scripting engine by simply including a Lua library and exporting your functions.
You know those programs didn't just disappear. You could do exactly the same thing with them today if you wanted.

And yet you still manage to be so inbred you don't even get it.

That's why I make my own engine and built shit from scratch. Takes longer but it's doable

>Yes but won't the operating systems stop running them altogether?
Use an older operating system to play them.
>Like, if I generate a game that is a win32 application... how would I distribute it on Steam, for example?
Kill yourself.

Just xor every character with a character inside a key. It works for encrypting and for decrypting. I'll make a demo right now.

>So it's a regular text file, but it will have one-time-pad encryption to prevent people from editing it.
lol where you gonna hide the key?

In the executable. Yes you can find it by looking into the binary in hex format, but it's not a nuclear missile launch code, it's just to stop most people from editing the save game file

oh no user called me inbred
i better kill myself
cant deal with this level of banter

Here's the demo

If I remember it right, there's no statistical way to brute force an OTP encrypted text.

Also, something really cool is that I can generate a PNG file with a screenshot and write the savestate after the PNG data, since it ignores everything after the end. That way people can share savestates and they'll know exactly what is going on since it's just a picture

Attached: otp.png (970x705, 45K)

>t. never used opengl
Actually I've written an UI framework and a small engine in OpenGL and I've also made my own OpenGL bindings including said helper classes
In fact I'm using them right now