Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1027564 Posts in 41226 Topics- by 32839 Members - Latest Member: alKaszL

July 28, 2014, 10:27:14 AM
  Show Posts
Pages: 1 2 [3] 4 5 ... 88
31  Developer / Technical / Re: How to develop unmaintainable software on: October 21, 2013, 08:46:05 AM
These pieces are, to me, just as vital to the game as its music, graphics, or play design.  They are part of the product that I want to ship.

okay, but then in the framework of "what is the best for me to become more efficient at producing software" you are definitely acting in an irrational way, don't be surprised if you have to explicitly state your point of view.
The original post/article/thing is talking about actual code written as a tool, if you write (part of) your code for your own entertainment his assumptions are still valid.

No, this is wrong.  I've provided several examples from real world projects where 'reinventing the wheel' is the ideal, and quite often the only rational choice.  Now, maybe it's because I come from a critical systems-type background where third-party code is an unacceptable risk, but these types of situations are not uncommon in other areas as well.

It's about short vs. long-term thinking.  Learning to do something yourself provides long-term benefits that don't come from relying on other people's work.
32  Developer / Technical / Re: How to develop unmaintainable software on: October 21, 2013, 08:14:29 AM
- that it'd take several weeks to do, time which would be better spent adding cool stuff to your game
- that writing one would be operationally identical to copying and pasting one, that there is no advantage to a game to having written it yourself

You know what, I think I finally have this figured out.

Your points all stem from an incorrect assumption, namely that everyone has the same goals.

You see, my goal is not just to write Game A.  My goal is to write Game A that uses my own image loader, gamepad code, etc....

Not doing this work does not save me any time.  It changes the project.  I am now working on something different, something that I do not want to write.

These pieces are, to me, just as vital to the game as its music, graphics, or play design.  They are part of the product that I want to ship.
33  Developer / Technical / Re: Gamepad HAT switch, how does it work? on: October 21, 2013, 04:43:23 AM
This is probably a dum question, but how do HAT Switches on gamepads work (The D-Pad if you're not familiar)?

Just in case you don't know, the vast majority of d-pads are not hatswitches.  The XBox 360 pad is the only one I'm aware of.  This is part of the reason why that d-pad generally sucks for fighting games.
34  Developer / Technical / Re: How to develop unmaintainable software on: October 21, 2013, 04:41:08 AM
- that it'd take several weeks to do, time which would be better spent adding cool stuff to your game

Image loaders are cool stuff.

- that writing one would be operationally identical to copying and pasting one, that there is no advantage to a game to having written it yourself

No, it is not.

My image loader prepares data in exactly the format I need it in.  This is a very important point that you seem to have missed.  I do a lot of things with image data apart from displaying it (shader tricks, mask generation, etc...).  The performance overhead that would be introduced by having to convert someone else's format into what I need is extremely significant, especially for large images.

also, you are again assuming that everyone codes as fast as you claim you can code. my position earlier was that coding an image loader would take the average programmer 2 weeks

If it takes you 2 weeks to write an image loader, you're either an inexperienced programmer or you're using a terrible image format.

The thing that you don't seem to understand is that image loaders are trivial.  They are not difficult to write. 

These are rules you've defined. Many authorities also say a golden rule is "dont reinvent the wheel".

They're not my rules.  I'm talking about the platform's rules.  Programs got away with a lot of crap back in the 90s (writing wherever the hell they wanted to, etc.) and games seem to be the last ones that are finally getting with the program.

And I loathe the "don't reinvent the wheel" crap.  It's such a terrible metaphor.  Improvements in wheel design are some of the most important technological advancements in history.  The movement from solid to spoked wheels changed civilization.  Reinventing the wheel is good, both literally and figuratively.  That's how you get better wheels.
35  Developer / Technical / Re: How to develop unmaintainable software on: October 19, 2013, 06:36:59 AM
i already said i understood that, and i agree with it when it comes to other things. but specifically when it comes to image loaders, i don't feel that it's a worthwhile use of time to write one.

I and feel that it is worthwhile to write it yourself, for the numerous reasons I've stated.  The only justification you've provided is that you could be using the time for other things, which is a useless tautological statement.  I could literally say that about anything and be correct.  It's a worthless point.

You know what?  The time you're spending doing other things could be spent writing an image loader.  See how that works?  That's not an argument, it's stating the obvious.

The idea that games are somehow "special" is also maddening to me.  Software is software.  Do it right or don't do it at all.

I'm sick of games thinking that they don't have to play by the rules.
36  Developer / Technical / Re: How to develop unmaintainable software on: October 18, 2013, 06:29:29 PM
i can understand how a car works, but that doesn't mean it's easier to build my own car than to understand how it works,

Building a car is not a comparable metaphor.  Henry Ford proved long ago that you can build a car without understanding how it works.  Engineering a car, perhaps.

and it doesn't mean that i don't have control of that car when i drive it if i didn't build it myself

Once again an irrelevant metaphor.  Driving a car is not the same kind of control.  Driving a car is analogous to using a library, not controlling it.  People used to have control over their cars, back when it was easily possible to work on every aspect of them.  Modern cars take a good deal of this control away.

i also don't know why you would have to understand it. for example, back in the 90s when i used to code in qbasic, i wrote my own .gif loading script (never did jpg). but i never actually use that understanding of the .gif format at all today, and i would not again ever write a .gif loading script because others do it much better than i could do it

You know, you are completely missing the point of this whole discussion.  It's not about image loaders.  It's about the fact that there are damn good reasons that people might want to implement things themselves and not use outside libraries.  What part of this are you not understanding?
37  Developer / Technical / Re: How to develop unmaintainable software on: October 18, 2013, 05:53:35 PM
but when the dependencies are open source or when you just copy and paste code i don't think you give up any control at all.

Do you understand all of the code you just imported?  Do you know how it all works?  Do you understand the complete ramifications of your potential changes?  If the answer is no, you don't have control.  If the answer is yes, you've probably spent more time studying NoobLib internals than it would've taken to just write your own stuff.

Wait a minute... why the hell would anyone use jpg in a game?
38  Developer / Technical / Re: How to develop unmaintainable software on: October 18, 2013, 05:21:53 PM
some of that is true, but my point was that everyone on a project still has to use the company's choice for the project's game engine -- you could still alter it to your liking sometimes, but you would not have control over every aspect of it. if you're a programmer for starcraft 2 working for blizzard for example, unless you are specifically in charge of that aspect of it, you can't just change the game's image loading code to your liking, you have to use the code that everyone else working on the game uses.

The team's code is your code.  It scales when working with a team.


so i'd say that programmers working in large teams always have to deal with using code that they didn't write,

The point is not working with code you didn't write, the point is working with code you don't control.  For example, the MTGO servers have no third-party dependencies outside of boost (and I was even nervous about that one) precisely because we need to control the code.  When the servers go down, every minute is a minute we're not making money.  This stuff has to be fixed now.  If the problem lies somewhere in the bowels of NoobLib, we're screwed, and whoever approved the use of NoobLib is probably going to get fired.

so being able to deal with code you didn't write is an important skill for a programmer to have

So?  I've never claimed otherwise and this refutes none of my points.

The fact that I can't seem to get through to you is that dependencies are risk vectors.  A large part of software development is eliminating the risks you can, and minimizing the ones you can't.  Will you be able to eliminate all of your dependencies?  Most likely no, but adding new ones for something as incredibly trivial as an image loader is just irresponsible in my eyes.  I always make an effort to cut out dependencies I don't need, and I'm down to only a select few (OpenAL is next on my list, most likely).

Oh, and NoobLib is a great name, so someone needs to start working on that.
39  Developer / Technical / Re: How to develop unmaintainable software on: October 18, 2013, 04:26:56 AM
yeah but the programmer would be required to use the company's solution, which is often already done, rather than code their own

e.g. you'd have to use the company's already written imaging loading code, you still couldn't write your own

No, not at all.

These sort of internal things get rewritten rather frequently to keep up with changing requirements.  In fact that's exactly what I'm doing at my job right now.

And that is of course assuming it even exists.  Quite often it doesn't and you will be the person doing the initial write.

Every dependency is a liability.  Dependencies are bad, especially for longer term projects.  As previously noted having control over the code in a project is highly valued and is not something to be disregarded, nor is it a 'waste of time'.

There is nothing wrong with applying these principals to smaller, personal projects.  There are concerns beyond finishing something quickly.
40  Developer / Technical / Re: How to develop unmaintainable software on: October 17, 2013, 04:02:07 PM
But I want to remind you for a possible future reference. If you are planning to join a company who is working on big software then be warned. If they see you are reinventing a linked list instead of using the library you will get fired quickly.

I've worked on both the Microsoft Office team and the Magic Online team, and this is not the case.  In fact, in both of those jobs I had to "reinvent" things due to circumstances beyond our control.  In both cases, as well as my current job, the time I spent learning how to actually do things paid off enormously.

In fact, the time I took learning how to actually use the Windows API for my projects rather than relying on libraries like SDL was a major factor in landing my current job.
41  Developer / Technical / Re: How to develop unmaintainable software on: October 16, 2013, 08:07:28 PM
if you are programming just for fun, then of course it's not a waste of time if you enjoy it. but if you have a specific goal, then it's a waste of time in the context of achieving that goal

No it isn't.  Doing things this way is part of achieving the goal.

I choose my projects based on the methods I want to use in constructing them.  For me, the means of production are just as important as the final project.

For example, I have a side project for which I'm trying to express as much of the logic as possible in terms of C++ templates.  Finishing the project is fine, and I hope it will be great, but more important to me is the mastery of new coding techniques.  I'm thinking about the future, and learning how to do things in a way that I haven't done before.  In projects going forward, this techniques will come in handy and make me more productive in the long term.

For me, the code is the product.  This is part of the reason why I open source all of my work.  I'm proud of my code and I want people to see it.
42  Developer / Technical / Re: How to develop unmaintainable software on: October 16, 2013, 07:17:38 PM
it's *still* a time expenditure, you're better off creating another cool level than you are writing your own jpg loading code when you can just copy and paste some code for it or use a library someone else already wrote for it.

You mistake is assuming that writing such a thing is a waste of time.  I enjoy writing things like image loaders.  This is not a waste of time for me.

Quote from: Paul Eres
4000 lines of code, assuming an average of 10 words per line,

What the hell programming language are you using that averages 10 words per line?!  I've written Cobol programs that don't even approach that, and that's the most verbose language I've ever seen (save for Applescript, but we don't talk about that).

Busting out 5-10 lines per minute is not a difficult thing to do.  I'm not even a particularly fast typist, I've had colleagues that could do far more.

I'm going to take a wild guess here, and assume that you don't particularly enjoy programming.  For people like myself that greatly enjoy programming, learning how to do things yourself is its own reward.  It's more valuable to me to implement something that works exactly the way I want it to than to add some completely unneeded dependency to my project, one that forces my code to adapt to the way some other guy decided to do things.
43  Developer / Technical / Re: How to develop unmaintainable software on: October 16, 2013, 05:06:09 AM
yes, it comes from a study that was mentioned in that book. it's an average, but fairly accurate in my experience. lone programmers can certainly do more than that, especially near the start of a project, but when you are talking about big projects and big teams, the average is 10 lines per day.

also that story is irrelevant, because we were talking specifically about a function that is 150 lines long. the reason good programmers are more productive than bad ones isn't that they write more lines of code per day, but that they make those lines do more. but there's a limit to that. you simply can't write an image function to decode jpg's in 10 lines, no matter how good you are

(this is why so many programmers like python -- because it can get more work done in fewer lines, allowing them to be more productive)

but regardless of whether you agree with the specifics or not, whether we are talking 2 wasted weeks or 2 wasted days (at the abnormally high rate of 75 lines of code per day, which few programmers can maintain -- i've never known anyone that fast), writing your own code to load a jpg is still a colossal waste of time, you could spend those 2 weeks or 2 days on game logic, and get the game done much faster

150 lines of code for an image loader is trivial.  If you can't write that in 30 minutes, tops, you just aren't trying very hard.

Hell, I've written well over 1000 lines of code at work just this week so far, and that's in two days.  This is hardly unusual.

I think you're confusing mantainance programming with writing new code.  For a maintenance programmer, yeah, I'll buy 10 lines of code a day because you spend a lot of time trying to figure out where that code goes and how to not break things.  For new code, 10 lines a day will get you fired, plain and simple.
44  Developer / Technical / Re: How to develop unmaintainable software on: October 15, 2013, 03:58:16 PM
As in, you probably don't need 50 external libraries in a 2d platformer, but there's no reason to write a JPEG loader from scratch.

This is kind of what I'm talking about.  Image loaders are firmly in the "write it yourself" category.  My image loader is only 150 lines of code, and that's including comments, full error handling, and compressed image support.  Image loaders are actually really simple, and not worth adding some additional dependency for.
45  Developer / Technical / Re: How to develop unmaintainable software on: October 14, 2013, 03:44:01 PM
I think the advice not to write everything from scratch is kind of sketchy.  It really depends on what you're doing.  I've been involved in several projects that got stuck with discontinued libraries that are so entrenched in the project they've become impossible to remove.  New developers can't find any documentation on these things and keeping them working with newer compiler versions becomes a serious chore.

Windows API wrappers seem to be especially susceptable to this, and I've become very gunshy about using them as a result.
Pages: 1 2 [3] 4 5 ... 88
Theme orange-lt created by panic