next »

[RandyGaul]

How to be an asshole: When someone talks about a programming problem they're trying to solve, if it looks remotely similar to something that already exists, immediately jump into the conversation and say "don't reinvent the wheel". Make no effort to actually understand the problem that's being solved; assume the programmer has no idea what they're doing and insist they should be using your favorite existing implementation and that it will obviously fit their needs perfectly.

(sorry, had to let off a bit of steam)

Ah yeah I get that a lot

Sometimes I even get the "don't expect to be spoonfed answers" thing when I ask questions, but really the question I'm asking is very specific and well thought out...

Bleh.

[Will Vale]

Also when the premature optimisation misquote is trotted out for the umpteenth time

[TheLastBanana]

Or when you're discussing a problem you're having with library X, and the only response you get is from some guy who says "library X is shit, just use library Y."

[Prads]

"don't reinvent the wheel"

I hate that phrase with a passion!

[InfiniteStateMachine]

Did a massive upgrade to a microsoft-library project. I'm a little out of date with MS technology so I had to learn NuGet.

The main issue is that so many versions of microsft libraries are tied to a IDE. So to upgrade from MVC3 and EF4 to MVC5 and EF6 required going from VS2010 to VS2012.

The problem is that VS2012 doesn't support XNA. I managed to fix that with some config file changes.

All in all took about 6 hours.


NuGet is actually really nice one you learn it. Even the MS project file system isn't so bad once I got used to it. It's like CMAKE, you hate it while you learn it but once you get it going it really saves time. It's just that initial learning wall that makes you grumpy.

[Noogai03]

"don't reinvent the wheel"

I hate that phrase with a passion!

"hey, can anyone help me implement basic collision for my cave story clone?" "don't reinvent the wheel, use box2d"
 

[RandyGaul]

"don't reinvent the wheel"

I hate that phrase with a passion!

"hey, can anyone help me implement basic collision for my cave story clone?" "don't reinvent the wheel, use box2d"
 

Remaking Box2D got me a job

So you can smack dem naysayers

[epcc]

On the other hand, I've noticed that there's a phase a lot of people go through when they just have started programming, when they feel that using other peoples libraries is somehow demeaning/for noobs and they try to write everything by themselves.
I had that phase and spent months trying to write my own physics engine. Finally I realized that chipmunk physics did everything I wanted to implement, only way faster and without glitches and that there's nothing wrong with building on other peoples stuff. I learned a lot about physics and collision detection at least.

The problem is that for the whole time I believed I was working on a game while actually I was trying to understand math that at the time was way above my level. When learning stuff, it's clever to do it step-by-step. Learning 2d physics without understanding vectors and matrices thoroughly is inefficient.

So, when someone asks help with something that's way over their head, instead of giving them the answer they were looking for, it's usually better to point them towards more basic stuff they should learn first, or recommend libraries that do exactly they are trying to do, so they could go forward with whatever their big plan was.
Giving them the answer will likely result in another topic a couple of days later with a next problem.

Now, doing that without sounding condescending and actually making them see the futility of their attempt is the hard part.

One another thing is that while I learned a lot about physics while trying to write this engine, messing around with third-party libraries has taught me a lot more. Seeing how other people structure their libraries helped me to actually write projects with more than a thousand lines without becoming a huge mess. I also developed a much better understanding on how the compiler actually puts everything together.

I've seen a top-down racing game that had totally awful physics while everything else could have been great. The creator was more artist than a coder and instead of using a physics library he insisted on hacking his own. Since collisions are a big part of a demolition racing game, this didn't get very far.

There are loads of reasons to write things from scratch, but there's so many people who do it for the wrong reasons and so they waste their time and end up with a worse final product.

In conclusion:
I think "don't reinvent the wheel" is a perfectly valid advice in lots of cases and I don't think it's overused. I do obviously agree that it's important to read and understand the question (ideally also the askers background) before answering it.

[Fallsburg]

I'll also say that reinventing the wheel is perfectly fine, IF you want to reinvent the wheel.  But if your goal is to make a car, then you probably don't need to reinvent the wheel.

i.e.
If your goal is to recreate the functionality of Box2D, go for it.  However, if you just want to make a 2D physics game, then you probably don't need to rewrite Box2D.

[Noogai03]

wanting to write a physics engine earlier on in programming is basically masochism 

[riksteri]

I think I have just recently reached a phase where instead of "I'll just use this random library I found" for every thing I instead go "Does using this save enough effort to be worth a new dependency?"

I used to just use a library for everything, even when I just needed one aspect of a really big and feature-complete library. Now I try to avoid introducing new libraries for tiny features that I can roll out myself with a little bit of brain workout and reasonable amount of time, even if it means reinventing the wheel.

I'm not completely sure if I've really hit the golden middle of moderation, or if I end up adjusting my position further to some direction in the future.

[Rusk]

I think in every project you should be trying to reinvent something. Just not more than one thing.

This is pretty cool btw: http://en.wikipedia.org/wiki/Mecanum_wheel.

[Garthy]

Re "don't reinvent the wheel": It's solid general advice. The trick however is determining whether you are really reinventing the wheel or trying to force a set of wheels onto an airplane in order to make it fly.

Similarly for premature optimisation. Also solid general advice. This one is better though because the exception is built right into it: By talking about the optimisation being premature, we are also acknowledging that there will be a point at which the optimisation is appropriate.

And naturally, when people blindly fall back on general advice when the specific scenario presented isn't actually the general case, there is going to be some frustration.

I think in every project you should be trying to reinvent something. Just not more than one thing.

I like this.

[J-Snake]

The downside with reusing existing solutions is that they can change your footprint. For those of us who consider games like a painting the following holds true: Imagine you want to create a painting of the human body according to your vision. But then someone tells you "Hey, I know an expert for drawing faces, you should probably delegate this part".

Now if you are creating just "industry work" then reusing tools is key in good software engineering. However if you create something according to your vision, like your personal painting, and want to match it perfectly, then you should do everything that is necessary for it.

In fact while it is claimed advanced tools such as unity enhances dramatically production quality the downside is that the user has more difficulties to judge the competence of the creators on the first sight. And so he is easier trapped in illusions of marketing. A much greater number of games which looks advanced on the first glance turn out to be completely incompetent after playing them.

[Fallsburg]

Re: premature optimization
I think this is a much misused quote. 

Early optimization is often the best idea.  Picking the proper data structure/algorithm/architecture/etc. early in the design process can head off a lot of stress/work/etc. later on.

My view on it is that things like "Oh, I think that this piece of code is slow, I'm going to change it" without examining the underlying problem first is a mistake.

I think in every project you should be trying to reinvent something. Just not more than one thing.

1) For a true beginner, I don't think this is necessarily true.  The kid making her first game should just focus on actually making a game (however derivative it may be) and handling all of the shit that entails.

2) I think that most every project should add something new, but that doesn't necessarily mean writing new code.

[Noogai03]

Having had a horrible time with game physics (a bug that I could not fix despite hours of work, knowing it would still suck when it was finished) I just gave up and started looking for libraries that did all the work for me (like Flixel, for example).

Flixel and Flashpunk both look awesome, but I'm using C#. Really not sure if I should switch language to AS3 or try and find a similar library for C#...
I've used Farseer (box2d fork) loads, but I don't want a full physics engine - I want a basic tile/AABB based collision system for platformers and top-down RPGs...

EDIT: did the EZPlatformer tutorial for Flixel is AS3 and it seems pretty choppy (is this just Flash in general?)

Aaah, gamedev is so frustrating... I've gone from one stumbling block to another. Graphics to start with, then collisions, then data storage, then collisions again... 

EDIT: I found some C#/XNA/MonoGame ports of Flixel, such as flxSharp (here) and X-flixel (here).
Problem is, they're basically undocumented from what I've seen...

EDIT #2: OK, have looked further into these. flxSharp is basically unfinished, with half the code salvaged from another framework and loads of stuff broken (eg collisions do not work, debug info not implemented).
X-flixel gives me errors on compile...

Does anyone know of any C# game frameworks like Flixel/FlashPunk that do lots of work like collision for you?

EDIT 3: MAJOR HAPPY! X-flixel is not broken; looking at the EZPlatformer demo solved the problem. It uses a really weird partial class to start the game...

Now I'm being annoyed by Games For Windows Live, which starts every time I start my program and delays testing substantially... Has anyone had any problems with GFWL and XNA before - I hate GFWL and don't want it in my game...

EDIT 4: fixed this one as well lol, did some digging on MSDN and found the "problem" - gamer services were being initialized by X-flixel. I wonder if ANYONE uses the GFWL overlay in their XNA games, especially since you need XNA Game Studio installed for it to work...

[ThemsAllTook]

Supporting retina displays in my games on Mac OS X is a major pain in the ass. I got it done today, but it was ridiculously unintuitive. Also added support to the website I'm building, which wasn't quite as painful, but apparently the features aren't all implemented yet... It only looks right in Webkit nightlies. I'm calling that good enough, since presumably the features will make their way into production Webkit eventually.

[Blambo]

I'm more of a grumpy shitty rookie programmer but I'm still grumpy anyway.

I'm using GM with a system that attaches a weapon to a top down character, a la Hotline Miami. The weapon object checks in a ten pixel radius for the player object so it can change its state to "held". It works fine except when the player is in the radius of two weapons, where both weapons just attach to it.

I tried making it so that only the nearest weapon to the player becomes "held" when the right mouse button is pressed, which works only when the player is not holding a weapon, in which case throwing a weapon in the vicinity of another immediately reattaches itself, as it changes the state of the weapon immediately after being thrown and thus qualifies for being "held".

I've tried a bunch of convoluted timer systems but most were just bad.

Here's some of the "pickup" code:

Code:

if(state != "held" && (distance_to_object(oPlayerBody)<10)){
        player_id = instance_nearest(x,y,oPlayerBody).player_id;
        if(player_id.r_click){
            with player_id{
                var nearestWeapon
                nearestWeapon=instance_nearest(x,y,parentWeapon);
                    if(mode != "local"){
                        if (lastWeaponHeld = 0){
                            nearestWeapon.state = "held";
                        }
                        else{
                            nearestWeapon.state = "unheld";
                        }
                    }
                    else{
                        if(weaponheld = 0){
                        nearestWeapon.state = "held";
                        }
                    }
                    }
        }
}

The solution is probably really simple and I'm just kinda stupid; could anyone help?

[eigenbom]

You need more states, e.g., "held", "on_ground", "thrown_by_enemy", "thrown_by_player".

[Blambo]

I have one each for "on_ground" and "thrown". Though I want to make it so the player may catch "thrown" weapons, so that required me to add a timer to "thrown" weapons such that they won't be immediately caught by the player when thrown.

I really badly implemented it I guess, and it resulted it weapons getting slingshotted all over the place because for some reason GM's "mouse_check_pressed" bool seems to span a few steps after it's activated, instead of just one step. Or at least that's my guess.