Greg_Nearfield
Newcomer
What would make programming easier for you?
What would make programming easier for console developers?
What would make programming easier for console developers?
To any programmers here about....eh...programming...
- Thread starter Greg_Nearfield
- Start date
ShootMyMonkey
Veteran
Well, ERP already brought up managers (although there's a lot more than just the one problem in the way they work), so I'll leave that out.
So to that I'll add...
Tools that behave consistently. It works when it should work, and fails when it should fail.
Languages out there have their problems and little things that make no sense, or are fundamentally bad, but you get used to them, and for every annoyance, you can often find a use for them that makes sense. I don't think it's really possible to make a good programming language that's usable for everything.
Adding to ShootMyMonkey, tools and library's that aren't bugged. There's nothing worse IMO then chasing down a bug in your program only after many wasted hours to find it's a fault (or undocumented feature 
) of the library you're using. And documentation. You can't have too much documentation and examples but these are too often the last thing tool+library developers worry about. What's the point in adding new features when the current features aren't known or understood or work properly? I don't know, but tool and library developers prefer to add features rather than refine existing tools!
) of the library you're using. And documentation. You can't have too much documentation and examples but these are too often the last thing tool+library developers worry about. What's the point in adding new features when the current features aren't known or understood or work properly? I don't know, but tool and library developers prefer to add features rather than refine existing tools!McFly said:A console powerful enough so that the following doesn't really make a difference:
Code:result = result + 1000;
Code:for (i=1; i<=1000; i++){ result = result + 1; }
Fredi
I'll bet you if you compile the above with optimisations on in VC++ that there is no difference both with equate to a load, an immediate add, and possibly a store
Follow up question if I may: how bad is the Not-Invented-Here syndrome in the industry? As an outsider looking in, I'm often dismayed at the number of times an engine is scrapped and re-written or when I hear reports of "We licensed engine X but completely gutted it to make it work for our game."Greg_Nearfield said:
.Sis
ShootMyMonkey
Veteran
About the only saving grace is that you sometimes get a good laugh out of it afterwards. Even if it means screaming at the top of your lungs for a few moments prior. People including myself will typically leave behind some amusing comments after it's all over.
In my experience with licensed engines, I've never NOT had to go through that. More often than not, I tend to see that "licensing engine X" actually means getting the sourcecode to game Y written by that company which created engine X and going from there.
Last edited by a moderator:
Sis said:
Not common enough
It depends on the dev house, the problem with external technology is that while if it meets your requirements out of the box it can be a real win, if it doesn't it can absolutely cripple you.
Middleware is certainly fairly prevalent.
However people need to understand that sharing or reusing code has costs associated with it, and sometimes the reuse costs can be greater than the implementation costs. This is especially true of simple systems. Even then middleware can be a win because it lets you get content started faster.
Now I'm not NIH, but I think it's important to understand that any 3rd party code is going to be designed with a very different mindset and requirements set than something built to solve a particular problem. For a 3rd party engine, Flexibility and extendability will trump simplicity and performance every time, for a custom solution the reverse is true.
A lot of the 2nd gen console phenomenon is because people can rearchitect things between products, performace is about dataflow, and understanding bottlenecks and you can't have the hindsight to build a good design until you've measured your first guess at it.
In no particular order:
- A proper IDE. I'm amazed at how much more productive tools like eclipse can make you. I never would have guessed back when I wrote all of my code in a text editor, but it's really true. In some ways it makes you almost too lazy though. It's like the difference between doing calculus on one of those little solar powered calculators and having a TI-92 at hand.
- stable requirements. It's really true that the cost and time needed to change part of your design increases exponentially as the project progresses. Not to mention that if you make too many changes by the end it's just going to be this huge horrible mutant project that has bits of good code hobbled together with masking tape and bailing wire.
- Time. Trying to rush projects is like trying to cook too fast. Sometimes you just need time to let things come together. On the other hand, sometimes projects need to be killed and put out of their misery too.
Nite_Hawk
- A proper IDE. I'm amazed at how much more productive tools like eclipse can make you. I never would have guessed back when I wrote all of my code in a text editor, but it's really true. In some ways it makes you almost too lazy though. It's like the difference between doing calculus on one of those little solar powered calculators and having a TI-92 at hand.
- stable requirements. It's really true that the cost and time needed to change part of your design increases exponentially as the project progresses. Not to mention that if you make too many changes by the end it's just going to be this huge horrible mutant project that has bits of good code hobbled together with masking tape and bailing wire.
- Time. Trying to rush projects is like trying to cook too fast. Sometimes you just need time to let things come together. On the other hand, sometimes projects need to be killed and put out of their misery too.
Nite_Hawk
zidane1strife
Banned
That's easy, full A.I. solutions on multi-petaflop systems that can get spoken english, and program better than the best of humans.Greg_Nearfield said:
Of course that'd actually be very bad news for many in the field
Greg_Nearfield
Newcomer
zidane1strife said:That's easy, full A.I. solutions on multi-petaflop systems that can get spoken english, and program better than the best of humans.
Of course that'd actually be very bad news for many in the field
Developer:...I lost my job... to my computer
Developer's 60PFLOP Computer:All your career are belong to us.
Team Manager
eveloper go to the restroom down the isle and program that toilet.Developer:....<walks out slowly while glaring at computer>
Not gonna happen, not least because you can't describe true logic (on any anything even but the most simple terms) with vernacular English as it's an inherently ambiguous language, like all human languages. You'd need to structure the language differently over a stronger semantic framework, and then you're in the realm of COBOL and BASIC and other high-end languages. It's hard enough getting humans to understand each other!
The best we could hope for is ultra efficient engines (or powerful computers that can cruise through any engine) and complex high-level languages, that allow an easy-to-grasp pseudo-code level language to be compiled, freeing the devs from worrying about low level implementation and abstract languages and letting them focus on game mechanics. No more worrying about learning symbolic languages and developing rendering engines and animation algorithms, being able to grab any models and chuck them in a scene, and caring only about what those object do and how they interact rather than actually getting them drawn.
That's where middleware plays it's part, but it's far from perfect. You don't need to write your own physics engine these days as there's off the shelf solutions, but then you have to go through the rigmarole of learning to use them, and then run into mind-blowing wierdness that you eventually track down to an undocumented bug in a little used function, or find your test case is the one situation where the solver is unreliable if only someone had cared to tell you earlier!
zidane1strife
Banned
Shifty Geezer said:
Who said we had to come up with the solution, if the h/w's powerful enough and our knowledge of the brain's advanced enough, we should be able to tap into its design and copy/paste our jigga-ma-watta
Human brains aren't logical enough to process unambiguous logic. Hence the numbers of bugs we get in existing software . A computer with a human-like processor will be as fallible. Take for example any story, be it movie or book. I've yet to come across any that doesn't have a few plot-holes and flaws in it's reasoning. And that's usually with the creator spending ages on rewrites too.
Though perhaps a cmputer could be constructed on more logical brains, like mathematicians? Perhaps an Einstein/Hawkings blend? Except now I think of it they've both used flawed logic too...
. A computer with a human-like processor will be as fallible. Take for example any story, be it movie or book. I've yet to come across any that doesn't have a few plot-holes and flaws in it's reasoning. And that's usually with the creator spending ages on rewrites too.Though perhaps a cmputer could be constructed on more logical brains, like mathematicians? Perhaps an Einstein/Hawkings blend? Except now I think of it they've both used flawed logic too...
