What's the best alternative to C++ if I want to make gamus?

I agree with your philosophy that doing something, anything, is better than doing nothing. On the other hand, if I were to give advice to someone who doesn't know anything about programming, I would argue that understanding things at lower levels is better than not. When programming a game engine, you will encounter problems that can only be solved by understanding what's going on under the hood. I would definitely avoid languages that prevented you from being able to develop dexterity with memory management, or anything that prevented you from interacting with the processor in a meaningful way.

unironically go. Your code will be ugly as sin, but it will just werk.

if it's like a 2d game that doesn't need performance, i'd recommend javascript. it's easy to write and easy to deliver. javascript has gotten a lot better since ES6, it's not the same shitty language anymore, promise!

gc will fuck you up and you will get indeterministic performance problems once you have done all the work and it's time to release.

C#/Mono

>using C over C++ when doing anything that doesn't involve ABI's

Don't even bother getting into programming, NPC.

Take a look here:
humblebundle.com/books/game-development-books

>Beginning C++ Game Programming
Looking to get this myself for that one, worth a shot?

Attached: wonder.jpg (298x298, 16K)

How retarded is this post. C has no oop so worthless in game design. The other 2 nothing serious has ever been made from them

Are you fucking daft? JS's lack of type safety makes it unironically one of the hardest languages to use _correctly_. Just because you can maybe, kinda get something to run without a compiler poo-pooing on you doesn't mean the language is easy. Getting to runtime is not a useful measure of how accessible a language is.

At the very least recommend Typescript, you NPC.

>He thinks you have to use C for anything to do with ABIs
I wrote a kernel and userspace libraries in C++. The only time extern "c" was needed was at syscall entry points and any other functions that had to be called from assembly (very little).

If you're too dumb to use c++ for games than you'll never be able to do it in c

This is the correct answer.

you must really suck at programming if dynamic typing is that much of a problem for you. most people would agree that it makes programming faster and easier. that's why it exists.

I think so. Can't really go wrong with C++ for game programming.(Plus the skills you develop are applicable to many, many other fields, so if games don't work out you've developed a marketable skill) In keeping with what said, just do stuff. Do anything, fail over and over again, and don't give up. You may encounter problems that take weeks to solve, but that's normal, and part of the learning process.

I just ran into this issue today with my Java project. I've got a highly concurrent simulation, and I was stress testing it with 2,500 AI units interacting with each other in the field. I use immutable data where I can 'cause they're great for defending against race conditions, but because you have to replace them each time you update them I wound up shitting a gigabyte of trash per second. I had to change a big chunk of my design so I could do mutable calculations that would resolve to immutable objects at the end, which cut it down to about 50 megabytes of trash per second.

Simply because of how much work the units are doing I'm not sure I can do much better than that.

lua

fun fact: in clojure everything is immutable by default, and it has a very efficient method of handling that where it doesn't copy the entire object every time you change it (only appends your changes).

The real reason static typing is superior is performance and optimisations.

dont use C for games unless you absolutely want to kill yourself.

that does help, but the performance gains are minimal and only matter in certain applications.

i'd say the biggest advantage of static typing is that you can easily refactor code, and the IDE can easily suggest all methods available to an object, their parameters, etc. that's just not possible with dynamic typing. these things help immensely with large projects. if you're gonna be building a large piece of software, you should use static typing.

>but the performance gains are minimal
Wrong

>he uses OOP for game design
no real developers do this

The best games ever written didn't use OOP. Discuss.

Meant for

>muh POOP

Retard

No, forget fucking cpp, google search unity and then start from there.

Don't come back.

/thread

Sure, your 50 line script doesn't strictly need static analysis to work well, but you're not going to stop there. You're going to take what you've made and keep building on it because you've got all these ideas of cute, sophisticated things you can do, and you're not going to realize that you're tightening the noose around your neck as you introduce far more complexity than your language was ever designed to support. You'll wind up with a sloppy mess that needs an obscene amount of duct tape to keep together, and all of it will be a shitty, runtime approximation of what static analysis would have given you if you hadn't accepted so much technical debt by choosing a terrible language.

Dynamic typing is popular these days because dumbasses like you are too shortsighted to see the issues it causes in large projects.

dynamic typing gets really fun once you start adding contributors

Fuck cris come back to your thread
>>/vg/agdg/

C programmer here. I'm making a 3D game from scratch, so I have something to add.

I ditched C++ in favor of C so I could learn lower-level programming without inadvertently mixing in higher-level ideas. C definitely has its limitations, but it's workable. Most of what I have discovered that I want from C is quality of life improvements, but I've found that working at a lower lever is not in and of itself an impediment to my progress.

Some things that I've run into:
I love the idea of fixed point math, but ditched it because I haven't found a decent way to use it in the absence of operator overloading.
I hate header files. So goddamn much. I avoid them unless I run into problems with stacking dependencies in the order I need to, in which case I group my structs farther up the chain. All my includes are in my main file, and all the .c files assume they're being used in the proper context.
Memory management was a huge pain until I learned about allocating a huge block up front, then using mini-allocators that work in the context of whatever data I'm operating on.

Those are the big ones that come to mind. For a single programmer working by himself, I haven't found C to be that big of a problem.

Static typing is so much more than just a tool to help you refactor your code. It's primary purpose is to prevent bugs, and it's REALLY good at it because so many bugs can be converted into typing errors that static analysis will catch long before you reach runtime. It's one of the greatest tools a programmer can learn how to use.

99% of games use OOP

>and only matter in certain applications.
like video games

Except for a couple of operations, like taking a square root, fixed point math is just integer math, man. If you need to display your number or use it to draw something to the screen, both of which don't need exact precision, you can just cast your number to a float and divide it by whatever constant you're using to determine where the fixed point is.

For example, suppose I have this byte:

11101001

If I manually divide that value by 10000 I'll get 1110.1001.

Just make sure your simulation always uses the same format, and only convert for services that need to know stuff about the simulation, and you'll be good.

>I hate header files.
So did the people who made C. Originally you didn't even need to declare a function before using it if it returned an int or the return was ignored.

You're right though, C's difficulty and non-scalability is exagerrated. People say video games are more complicated now and need C++, but somehow I doubt they're more complicated than e.g. the Linux kernel.

>not using templates
It's like you actually hate yourself.

>using templates
ditto

That's not even true you fucking retard. Most games these days use entity-comonent design. Go kill yourself you shitstain.

Composition is generally superior to inheritance.

>I like to copy/paste my code multiple times, changing only the types
>I like to write code to generate more code to compile my program
Stay retarded

entity-component is written in OOP paradigm, retarded faggot. It's also useless because most implementations are not even data oriented, kills your cache. Only shit tier engines like Unity use entity-component, and you see the performance. You literally need i7 for a simple pong game, along with 4GB of RAM of course.

>OOP refers to any time classes are used
Jesus fuck, please step away from the keyboard.

>I don't use inheritance in entity-component, therefore it's not OOP, just using some classes bro xD

Entity-component really has nothing to do with OOP

most games these days use entity-component systems implemented in OOP
you have alot of conviction for someone who doesn't know what they're talking about

Attached: 1510101698118.png (1296x1458, 212K)

>shit tier engines like Unity
And Unreal Engine and CryEngine and pretty much any engine worth using.

>UNITY
He calls someone else a retard and then says Unity
This fucking guy

Attached: 1507104169942.png (630x630, 218K)

>implying that inheritance is more data oriented than composition

stay classy, retard

>implying either of them are more "data oriented" than the other

>"retard"
>proceeds to recommend unity

kek

Attached: 1519043563025.jpg (360x360, 17K)

In moderation, sure, they're whatever. But classically OOP is about designing grand taxonomies and building cathedrals in the sky. Data is the last concern because abusing the type system is more important.

not sure what that has to do with what i said
your data is in the same place whether you're using composition or inheritance

>I have semantically identical types
>I like to wait for my program to generate multiple times the same assembly code just to trash everything at link time
>I like having cryptic errors

>reddit spacing
>newfag
>kek
my faggot dector is going off the charts

>cloud services
>IoT connectivity
dropped

>cryptic errors
Confirmed for retard. I'll bet you think stack traces are cryptic too. Just admit that you are a retard. You are literally arguing against something that requires far less typing with zero performance overhead during runtime.

You're about 2 generations behind. Read how hard it was to do hydro thunder because with out oop they had to change the state of everything

Another subset of C++.

if you value a tenth of a second of compile time over producing software you can look at a day later and continue working on it's because you have no intentions of doing so

That's actually the best way to use C++ most of the time.

based and redpilled

This. It's a clean approach and helps keep design simple.

>I wrote my OS in C++ XD
Oh boy, I'm sure it's totally streamlined and not bloated or slow as fuck.

>Classic and well remembered games, made before 2000, either use minimal c++ or c/assembly
>Games made past 2000 that have zero replayability and are cookie cutter pleb shit
>Written entirely in C++ or some other high level language

Attached: 1489217682148.gif (1080x1080, 505K)

JavaScript
the answer these days is always JavaScript

Clet here. What is the point of header files?

The Rust OpenGL libraries suck ass and are poorly documented. I like Rust a lot, but the graphics libraries are exceptionally shitty.

defining macros, structures, typedefs
explicitly showing what functions or extern variables exist in the object file.

>I like Rust a lot
get outta here tranny plebbit is that way ->

oh shit, I should have told op to learn asm for that real low level stuff so he can create games with asm like a champ

OpenGL sucks ass even with C/C++. Most games written directly for GL typically end up making some kind of half-baked abstraction anyway to deal with its braindead state machine and globally selected object API.
Maybe gfx-rs will actually get somewhere in a few years and we can all just use a Vulkan-ish but safe API that calls D3D, Metal, Vulkan or GL depending on what's available.

I don't think the arguments for using relatively low-level languages are defeated by bringing up asm. The point is that you want clean control over the memory and processor, not that you secretly desire a return to primitivism. Why stop at asm? How about accuse everyone of secretly wanting to make everyone design their own processor by hand? This was never the original argument to begin with.

You jest but it's not impossible; and if someone prefers it over other languages, there's nothing stopping them from using it.
>b-but it would take foreeeeeeveeeeerrr
Implying it won't take forever with any other language anyway given how lazy the average person here is, and besides you're just coding c/c++ code in assembly anyway and not actually doing any interaction with hardware. It would only be marginally slower then outright making something in c/c++ (assuming you're not some fucking normie who can't into assembly in the first place).

GML aka Game Maker Language

t. brainlet C poster

You seem a little...upset by something.

Attached: 260.jpg (395x380, 21K)

Just think it's funny that C users think C++ = bloat
What they're really saying is "I don't know how to use C++, so when I use it I bloat it up"

Attached: damn.png (301x614, 296K)

C++ is a bloated spec you fucking retard

Jain, other languages are pajeet-tier.

now who's upset lmao
Seems like you're changing your argument from: "C++ makes bloated/slow programs" to: "C++ spec is bloated"
Maybe it's time to stop posting