Classes are 5400 lines long and this is a good thing

Why are you bullying a game developer for making easily readable and uncompressed code for his game?

Other urls found in this thread:

github.com/NoelFB/Celeste/blob/master/Source/Player.cs
github.com/NoelFB/Celeste/blob/master/Source/PlayerComments.md
twitter.com/SFWRedditVideos

Because you're a faggot and you should fuck off back where you came from

My whole rendering pipeline isn't even this long.
The gamedev must be retarded if his player class is this long.
Well, what can you expect from an indie-pixel-shitter.

5400 is not that long.

Come back after you reach the line limit of a VB6 class.

Who cares. That game doesn't do anything unique or remotely complex.

You could find more interesting shit on github.

>Why are you bullying
They didn't say 'No bully pls' in the tweet

>5.4k lines
>long

My sides.

That's pretty normal in my experience.

For a single class?

>classes

You could go full Javatar Abstraction Astronaut and start decomposing it into 20 different classes. You'll just end up having to open 20 different files to understand and/or debug the mess.

I'd say it's beyond the limit of being manageable if you don't use folding. With properly implemented folding, it's not scary at all.

>5400 LOC

bitch please
call me when you hit 20 000+

i've seen some shit

>You'll just end up having to open 20 different files to understand and/or debug the mess
Breaking a large class down into smaller components is always much easier to manage.

There's almost no reason to ever have a single class be over 3k lines long.

This is about normal for a modern platformer, especially ones with a lot of different moves and powerups like celeste, the physics and movement are so tightly coupled that it doesn't make sense to try and split things up.

Splitting the edge cases up into different files doesn't make the complexity go away. It just makes it more confusing to follow what the code is actually doing.

>Splitting the edge cases
Not edge cases. Utility methods, Debugging, Actions. There's no reason those all need to be in the same file.

Use a namespace/inherit off base classes.

>5400 is not that long
Sure, but the point is, it shouldn't all be in one class. If you are REALLY doing this OOB shit, for fuck's sake, use interfaces, use inheritance. I'm sure many of the functionalities of that class could be easilly extracted into a very readable parent classes.

But I guess that's just too much work. Better manage 5.4k lines of code in a single class.

What the fuck is an "action" and why would you split debugging off elsewhere when the best type of debugging information is a simple print statement?

>inherit
I beg your pardon.

>the best type of debugging information is a simple print statement
man if you don't have a fucking clue what you are talking about then you should probably just keep your mouth shut.

I don't use inheritance. I use composition if there is code which will be used more than once. I just interfaces sometimes, but they're mostly sugar that a tagged union can accomplish anyway. Otherwise, it all goes in large functions and large classes. There is NO reason to prematurely break functions and classes into components if they are only being used once. If LATER you see some potential code reuse, then you generalize it out. Long functions are easier to reason about than jumping around between multiple functions.

Look in the code, there is nothing to put in utility methods and there is nothing to inherit from, it's a big ass fucking state machine. You could put the states in different objects but why? Just so you can incur more GC overhead?

Can you link it? I actually want to see how much of that is actual code and how much is helper code/boilerplate.

then show me your fucking idea of amazing debugging code, show me the debugging code that this developer should spin off to its own dedicated class for no reason; don't be an obstinate cunt.

How come people constantly complain about garbage collected languages with random collection cycles and their performance, but they're used a lot for videogames which need to be predictable for inputs? (Java, C#, Python, et al.)

Is it true that GC doesn't make a meaningful impact?

github.com/NoelFB/Celeste/blob/master/Source/Player.cs

Also see this for the dev's comments on what people were complaining about
github.com/NoelFB/Celeste/blob/master/Source/PlayerComments.md

GC doesn't make an impact if you write your code correctly. However doing so is about as much work as just doing it in a non GC language

Games written in languages with automatic GC often have to resort to hacks to get GC to run exactly when they want it to.

Who cares? You're a fat loser on Sup Forums while this dude is making bank

>ctrl-f
>if
>1/601
I'm already afraid.

>My pipeline
Bet you're using concepts you read in a book or somewhere else, made up primarily by someone else.

This.

This user is a fucking idiot. Wasted my time even responding to them.

I'm seeing a lot of if's regarding different parts of physics, for example:

//Falling unducking
if (Speed.Y > 0 && CanUnDuck && Collider != starFlyHitbox && !onGround)
Ducking = false;

//Physics
if (StateMachine.State != StDreamDash && StateMachine.State != StAttract)
MoveH(Speed.X * Engine.DeltaTime, onCollideH);
if (StateMachine.State != StDreamDash && StateMachine.State != StAttract)
MoveV(Speed.Y * Engine.DeltaTime, onCollideV);

//Swimming
if (StateMachine.State == StSwim)

To me it seems like a lot of those could be abstracted out into parent classes. Start with a base class that has all of the necessary attributes, then combine classes like Swimming, Sliding, Jumping, and combine their functionalities in a meta-class. But then again that could lead to insanity caused by order of these operations, so might be worse than it sounds in theory.

I think you have to weight code aesthetics against code practicality. Especially when a lot of people in your team already know the structure of the current mega-class like Player and refactoring it is just gonne make it harder for others to work on the project.

the majority of all code is bound to be branches, how new are you?

still wasting your time then, you fucking mong. insults aren't a substitute for an argument.

>280 lines are just instance attributes
Jesus christ, this is why I never got into game development. Fuck this shit.

>Start with a base class that has all of the necessary attributes, then combine classes like Swimming, Sliding, Jumping, and combine their functionalities in a meta-class.
Stop, for the love of fuck.

Also this is just typical movement code.

And to think back in the day some people coded chess in 672 bytes.

Have you stopped there to type out that response, or have you read my whole post?

I did read the whole post and I think that you should feel ashamed for sharing such a bad idea.

Now that hurts my feelings user...
Or at least it would if I was a game dev, which I'm not so I was mostly speculating.

I still haven't seen any specific criticism other than "it has if statements" or "it's too long". Seems like inexperienced people being jealous and trying to insult the code of those who have accomplished more than them, I used to do it too.

This is not unusual movement code. This code will be immediately familiar to anyone who has read or worked with the player movement code in Quakes 1 through 4, and the MovementComponent in UE 4 (which I seem to recall is larger than 5,400 lines). No one pokes fun at that code because they were written by people with credentials, but when similar code is written by some upstart it's "terrible" and "horrific". Stupid attitude.

There is no reason to do that unless you actually needed another entity to use the same swimming, sliding, jumping, etc behaviors. Splitting it up to ease cognitive load (I assume this is what you meant by "code aesthetics") is pointless because regions in C# are supposed to make big classes easier to navigate due to outlining.

I understand your frustration but think of it like this. In business programming you would probably be thinking a lot about invariants and keeping everything in a sane state, because keeping everything correct is the goal of whatever your shitty enterprise software is.

In a physics simulation (which is what these types of games are) there are such a huge amount of possible states that you cannot even begin to try and validate them at a code level. Indeed the whole point of the game is that when the player violates some constraint, they die and have to start over.

Another (heavily simplified) way to explain this is that in this type of game, it may be perfectly possible for 280 different things to be happening to the player at once. On the same frame, it is perfectly reasonable for

- three enemies to shoot at you which causes an idle animation change
- you hit an ambient object which spawns a particle, you use a powerup
- you duck and turn around and hit the jump button at the same time -
- some other particles come in contact with you
- you're standing on a ledge which changes some animation frames
- etc etc, I won't bore you but if you've played any action games you can probably think of a lot more things that go here

This is ALL ON THE SAME FRAME. All these things need to behave properly together, and it is hard to do that without either tight coupling or with an entity component system that will easily triple the amount of code you need to write, and makes no sense in a platform game scenario where the player's movement code is very specific and typically only gets used in the player entity anyway.

The guy in OP pic probably should have done that too.

Hmmm, wouldn't this indicate that the objective paradigme of programming doesn't suit game/physics development?

It feels like you need some different way of abstracting these problems out. Either that or there's no way of doing that at all.

shut up functional fag

Looks fine to me, game code is usually long because of all the random conditions. At least this shit is readable.

it's a bunch of "if (midpoint of player is just below surface of water && player velocity Y component is greater than 10) jump up out of the water". it is the most straightforward and concise way to write movement code -- that's the reason all movement code looks like it.

Well that's the point, you can't avoid the ifs, but you could possibly find a clear way of writing it in such way that you could easilly group together code related to different types of physics, like I mentioned before, swimming separately, sliding separately, and so on. But I'm just speculating.

>bet ur not wasting your time re-inventing the wheel when someone's done that before you did, in a way more optimized way, that you can just freely take to make your work that much more efficient and faster
This is you. You're retarded.
Why don't you write your own IDE/text editor? Why aren't you using a self-made OS? Are you telling me you didn't even design your own CPU arch? Fucking mongoloid.

lmao @ people in here arguing it's better to keep it all in one file instead of spread across multiple files

why don't we just keep code for entire programs in one single file ? why does my keyboard need more than 1 key? why do i have to wipe my ass if its only going to get shit on it again later?

There are plenty of constraint-based languages but the problem is that it is hard to reason about performance and correct order of operations with those. In game dev, these things are generally more important.

That is what the regions are for.

>but you could possibly find a clear way of writing it in such way that you could easilly group together code related to different types of physics
already done, the functions aren't just random.

it's all relevant and highly coupled code.

>5000 line class
Our code base has a file called 'functions.php' that has 12000 lines. And on top of that there's 5 more all over the place with similar amounts of code

Actually no.
I am mostly looking at Documentation and listen to talks.

We're in the process of wrapping up an enterprise grade accounting software and the main file (and biggest) that handles most of the common shit barely cracks 1500. It's huge chore trying to do anything in it, even on a 27'' screen, it's too fucking big. I have no clue how you people can bare files with ten times more lines.

easy, through tools like minimap and find it makes it a breeze to navigate around

code folding, regex search, ctags, you don't need much more than that

I know you're not missing the point on accident. Nobody is implying you shouldn't reuse existing things, but you have no right to pretend like just because you rewrote something for the Nth time, that it's somehow yours while acting better than everyone around you.

Go back to /agdg/ you filthy nodev

I am not , but As I said, I am not rewriting existing things, and I don't learn from a book.
I learn about the best practices, and listen to what others are saying about their experience, while actually writing and figuring it out on my own.

nodev?
Also I have never visited agdg and don't see a reason why I should. (nor do I visit Sup Forums)

Indie pixel shitters aren't exactly pushing the limits of anyone's pc, so the GC doesn't matter in their case.

No fucking wonder that game crashed on me so many times.

Yes. OOP is entirely unsuited towards gamedev. Most engines are moving towards ECS.

>To me it seems like a lot of those could be abstracted out into parent classes
This. He's coupled all this shit together. Physics, state changes whatever the fuck these. This is the kind of shit Pajeets write and the regarded.

>using the new averaging system in a game

Shit programmer is shit. Never heard of the game but judging from this player class this guy would be incapable of doing more complex programs. I could write a 2d game in a thousand lines. I just don't have the art skills.

I'm sure you could, buddy :) But seriously, if you think you could, find an artist on deviantart who wants to make video games and partner with him.

>Long functions are easier to reason about than jumping around between multiple functions.

Then wouldn't the best possible way of organizing code be everything in one file with functions defined within the main method and captured by JavaScript-style closures?

Obviously that's ridiculous.

You shouldn't always need to know everything about what's going on in a certain class to reason about the class. People who have any grasp of workflow and tooling can look at two (or more) files side by side. I can't fucking imagine a world where that's less efficient than scrolling up and down a single file to look at every fucking thing going on in a 5000 line class.

real games are done in c++

>armchair devs

as opposed to straight-backed-chair programmers?

Those games are far more complicated than a pixelshit 2D game, they don't have 100 line functions, and they aren't completely unreadable and undocumented.

Modern game development attracts the absolute worst type of programmers.

>how DARE these people critize someone
I fucking hate forums

>Games written in languages with automatic GC often have to resort to hacks to get GC to run exactly when they want it to.
This. The original dev responded to a lot of the
>why was this code structured retardedly
with
>I was structuring the code in a hacky way to avoid GC

>this code
>deeply nested ifs
>callbacks in a fucking game
>state machines implemented as a mix of nested ifs and switches
>extremely high instance size

I haven't seen the game yet and can already tell it's a "retro" pixelshit styled game with simple mechanics. Also the "devs" will never work on a performance critical game in their lives.

If your architectural design ever leads you to have a class greater than 1000 lines, you fucked up somewhere and should consider refactoring. That's a pretty basic and well known all-purpose rule

What's wrong with callbacks in a game?

What if my classes are all

This dude has finished a successful game, you have not.

It's easy to have high coding standards when you don't finish products. As long as the game is not buggy, I don't see the issue.

>What if my classes are all

How is the class 5400 lines long for a 2D platformer? 500 I get. 5000?

Looks like movement and appearance of the character is bundled up in one neat mess


// Hair
{
var windDir = windDirection;
if (ForceStrongWindHair.Length() > 0)
windDir = ForceStrongWindHair;

if (windTimeout > 0 && windDir.X != 0)
{
windHairTimer += Engine.DeltaTime * 8f;

Hair.StepPerSegment = new Vector2(windDir.X * 5f, (float)Math.Sin(windHairTimer));
Hair.StepInFacingPerSegment = 0f;
Hair.StepApproach = 128f;
Hair.StepYSinePerSegment = 0;
}

>What if my classes are all

ITT
>C# is too verbose. Dude use a featureless old language that doesn't abstract compatibility
>5400 is not that much lmao I hurr durr 20K lines of C for prototype
>he could have seperated the class into smaller classes or used inheritance

Because there are a whole bunch of things in that class that should be in other classes.

Refactoring is going to destroy the code.

Celeste is a cool game anyway. reminds me heaps of Metroid Fusion.

>he doesn't know about natural-chair programmers

>real games
that really no trues my scotsman clause

Almost all games with pixelart are bad.

Point them out then.

It makes sense in context, and in that way it's similar to the games mentioned above.

you realize that there are other ways of programming without classes which aren't functional, right?

yes the code is unnecessarily long and while it doesn't stop the developer from making a good game it does show that he isn't a good programmer because for a game as simple as his he could easily divide it among other classes

nigga you get what the fuck he means, he could've just said AAA games but the game industry primarily uses C++ and you can't debate this

So point out what could be split up. Don't say swimming and jumping and so forth can be put in their own class; that's a dumb idea.

It's not unnecessarily long if it can't actually be compacted without reducing functionality. If that's the case, it's just necessarily long. It's not like he's writing code that doesn't do anything, endless inheritance and sprawling boilerplate.

Whatever you guys say, 90% of people on this earth are stupid and have money. I see an opportunity to sell them my 5400 lines class game to make money.
Fast forward 10 years. 90% of people will still be stupid.

>justin bieber earned millions singing retarded songs, so he must be better at writing songs than you

You must be retarded.

you couldn't write better movement code unless you started reducing movement complexity so fuck off m8

Doesn't mean you have to resort to fallacies.

most GC can be avoided fairly easily by being smart and by using pooling. You can also manually trigger garbage collection intelligently to pretty much avoid GC hiccups.