I watched the announcement of the Wii U at E3 2011.
Here is a screenshot of CNET stating the Wii U == an iPad-like controller.
Here is a screenshot of CNET stating the Wii U == an iPad-like controller.
Still no.
It's hard to say they do quality well when you look at NSMB, Wii Sports, just really cash in games.
"doesn't follow industry standards" - i see this banded around lots , and its almost said in a manner that is saying nintendo are doing things wrong cuz they dont follow a supposed industry standard.. whos making these fukking industry standards , and more over whos saying anyone has to follow them. If by industry standard you mean , dont stir up shit and just make a console like all the others , then really what would be the point. I like the fact that Nintendo dont follow the herd , and do their own thing , it really is endearing . Dont bother giving me the business lesson . Its done to death , We have this shit with the plethora of android console/tablets etc , nothing new just same shit in a different latrine , is that what we want of our consoles? or would you prefer innovation , however limited and not up to your standards that innovation may be..
There are not standards as in the sorts of things you go and look up from ISO, IEEE or ANSI or someone like that. Likewise though I love the idea of standards you have both https://xkcd.com/927/ and well similar things are said about standards as there things said about opinions. On the flip side the likes of directX, openGL, processor designs and more. which are less download and read and more aspirational, are decided upon by huge coalitions with input from tech people, coders of all stripes and more besides, also unlike fashion there is a real and demonstrable reason when some would say "double precision floating point is in".
However if you look at broader trends within coding, and Nintendo has long lacked the clout to do anything else here even if it did kind of work for a while, Nintendo have repeatedly gone against the grain give or take the handhelds but then again the only choices tended to be ARM or something in the MIPS family and nobody will fault you for picking ARM for a higher powered portable device.
I like and respect people that learn systems down to the levels where physics starts getting involved, however basically all of computing is a slow march towards pure logical abstraction with the low level stuff being less of a necessity and more of a party trick, this is not a bad thing either. With Nintendo not doing what others do here, and it is not just consoles but general programming too, they then leave their devs to have to work around these issues as we are not quite at the land of pure abstraction or at least games able to be streamed. The question then easily turns to "is it worth it?" and consoles live and die on the support of third parties these days, to that end you never want to have that question asked. Worse still for a lot of things is it also leads to a mindset of "that'll do" which is frequently fatal -- stand tall or don't stand at all, done badly or worse than nothing done at all and other such lines of logic.
That said on "what would be the point?", indeed the sooner we end up at the DVD player model the better as far as I am concerned. However by all means try to give me a fancy controller that will work better/best with your games, and do passably at a baseline/set standard, there are even nice wireless protocols you can buy in for the purpose.
Endearing... yeah, so are stray cats though and I do not really want one of them gumming up the works.
At this point it might just be wiser to cut the Wii U and make something better. At this point even I've started regretting it. I've had it since launch and the system just sits around collecting dust.
Industry standards exist for a reason and as FAST mentions, they are set by huge consortiums working in-cahoots with hardware manufacturers. Groups like Khronos (takes care of OpenGL) make sure that developers are able to squeeze the most out of the hardware offered. The resulting tools of the trade are an industry standard, something software developers take for granted simply because it makes their lives much easier. You can ignore those standards, but you do so at your own peril.
It's not as much a matter of a business lesson as a matter of ease of development. Take Wii U for instance - it doesn't do "DirectX 11", it only offers "equivalent functionality" which is all fine and dandy when you think about exclusives but it quickly becomes a handicap when you think about multiplatform titles in which all of the DirectX code has to be re-written specifically for the Wii U version of the game. This wastes everybody's time, it means extended development times and higher production costs. Hell, come to think of it, even exclusives are affected to an extent because the involved programmers have to re-learn how to perform even the most basic of tasks using platform-specific functionality instead of the well-documented techniques they know and are accustomed with.
Like it or not, industry standards make our lives easier - it's what distinguishes contemporary systems that offer slews of games and applications and pre-industry crash systems where there were dozens of platforms and each offered a handful of software since there was no common standard of coding it and everything had to be made from scratch.
To compound that, many third party developers pointed out long turn around time when asking for technical help from Nintendo. Time is money; with substantially longer development time frame and less potential of profit (from less existing userbase), it is not surprising to see that many developers stay away from Wii U.
This is something I added to my post in an edit - industry standards are well-documented. Releasing broad documentation is in the best interest of the groups responsible for given tools and examples are available at a snap of one's fingers. When you do things custom like Nintendo does, there's only so much help the SDK documentation can give you and there's nobody but Nintendo to contact in case you run into issues.
Except they are.
Say you have a console that sells 5 Million. How big a budget will go towards your new Mario game compared to if the console had sold 25 Million? You think it's likely to be bigger or smaller? Also, though Nintendo are pretty much compelled to release an exclusive Zelda title for each platform, do you think the chances of getting two new Zelda games through the console's lifespan are bigger for the console that sells 5 million, or the console that sells 25 million?
A better performing console will get more, and better funded, games. So it really is important.
What? Isn't 'overall quality' a measurement of 'how good' something is? Or have I missed a subtlety?
Pleng hits the nail right on its head - the bigger the install base the larger the sales potential is. If you only ever sold 5 million systems, you can only sell up to 5 million copies of a game, and that's if you live in Wonderland and 100% of users will buy it, which is never the case. This and this alone automatically cuts down on the potential investments studios would be willing to make while developing a game, especially with exclusive titles. Multiplatform ones don't suffer from this problem as much since they're released across multiple platforms, but even still, there's going to be less effort put into the porting process to the lesser platforms because why bother when it won't be profitable?
Relearn? You mean they never learned it in the first place? And I thought the equivalent value to zero was zero? Surely these incredibly smart programmers you mention are capable of creating a function that will fulfill the requirements of the DirectX and the U's equivalent without whole game code rewriting. That way, they'll still be following the standards, but they'll add sort of a new one. And they're called functions for a reason; there are thousands of them in a game; all they need to do is copy the function that reads the DirectX and make it compatible with whatever the U has. Am I oversimplifying here? And why does it work for exclusives, but not for multi-plats? In my mind: it either works or it doesn't, especially when it comes to computers. They can't afford to be emotional like humans; they operate on true/false. And there's got to be an easier way to make the game work rather than rewriting the whole game code... right? Maybe if they made it directly compatible with the "equivalent functionality" and then ported it to DirectX, it would work. One step backward, two steps forward.
They possibly did not learn in the first place.
Consider a 3d cube.
Perspective exists, I do not want to look at it straight on at it.
The maths to render this is all sorts of complex.
If I make another game where a fight happens in a shipping warehouse I will be eaten alive so I need to make something other than a cube (and sphere and cylinder aka the 3d primitives).
Of course I also need light. Ray tracing and the types of reflection are a pain but you realistically need to know those to build the lesser versions.
Precious few coders know this, and I would not expect many more to learn. Knowing this we have 3d graphics which would still be a pain to work with so we have huge function lists in the forms of directx and opengl. This goes one step further as well and you can even buy in the unreal engine to make your game in.
Oh and I still have textures to cover and how to add those to items, deal with light hitting them and all that such a thing entails. Bonus is you can also improve your textures to make up for things lacking in 3d (see something like Gouraud shading).
Time moves on though and we have new hardware that is capable of doing more (this is quite literally what the higher version numbers of openlgl and directX allow for) so varying here means companies making games have to think about what they are doing and drop quality.
That is possible getting a bit too in depth though. If you build a game you have a choice how to code it and one of those ways might involve using a lot of memory. If it is there though you would be a fool not to use it for a game console (they only run one program at a time after all).
Nintendo comes along and says unlike the PSbox you have a fraction of the memory of the other two (and PC which is borderline unlimited at times) and you get to seriously think if it is worth the hassle.
They say "solid online infrastructure... what fool needs that?" and you look and see most of the big games are huge online affairs.
They say "onboard storage options, not going to happen this time around". Well there goes expansion packs and DLC, rather large money spinners and as a result of the online stuff no real patch support either.
Nintendo wander around with an attitude of "making games for our systems is a honour you plebs barely deserve", others say "tell me if there is something I do to make your life easier"
That is all recent times as well, go back a bit further and you have the "CDs/DVDs are in, tough you are still using cartridges or miniDVD".
Beyond that though the entire indie market is basically a testament that you can make some spectacular games with few resources and not much coding skill/using baseline libraries, a bit further up how many people make spectacular games by buying in the unreal engine. Again this is a good thing -- we do not expect everybody to familiar with the rules of word creation to be able to write a story, indeed too many proper nouns are usually considered bad storytelling.
Sure it is; lines made on the x, y, and z axes and then connecting at a point in space. That's not very hard; what's hard is the detail: making it real, making the images flow together, etc.
Yes, you need to make large wooden crates, a crane perhaps, the characters obviously: all of which have to be made with a 3D object. But these primitive objects are a base from which to start: think about this. Ever since 3D came out, they have used objects like the cube. What has changed? The amount of detail that can be rendered on the cube. Ray tracing: back to the 3D objects. The ray has height, depth, and width: but it doesn't use all the space available in the 3D object from which it was based. But I mention the 3D object because the point of reflection/refraction starts where the coordinates of the object are 0. And since this is a 3D ray, it is composed of many 2D rays. So then there are many coordinates at zero, each with their own points of reflection.
I would expect them to learn. I can take four cubes, a triangle that meets each of their corners, a rectangular cube, and create a house. Then all I have to do is decorate the exterior (and interior once I get around to it) to give it graphics. And apparently the function used to make the U's "DirectX" compatability is a bit different than the other two systems. The industry standard might have it look a certain way, but that doesn't mean you've got to code it a specific way. It's what they call maximizing compatibility; if the function works, but doesn't give you what you need, then there needs to be some adjustment to give it what you need. A good point to start would be at the U's engine and upgrade from there: it's not easy to downgrade and they know this. And here's where their excuses start; they'd be making themselves do something hard, so they just give up. If they were smart, they would start at the easy point and then add details. The U's textures are easier to define because they're not as defined as the other ones. And people bitch and moan about how they're not as defined, forgetting the fact that making textures like that is easy. I suggest a new standard: let the weak go before the strong. I get that 3D graphics are amazing, but is it really worth cutting someone out so they can't enjoy them like other people can? Would you deny me the privilege of looking at a roller coaster because the textures are just too powerful and I could be rendered helpless by them?
I think I covered this section. Things don't lack in 3D; lighting must be used to make an object 3D. Everything in the world has some form of light shining on it: sometimes the light is so dim and nearly colorless that it could be mistaken for darkness.
Indeed. I said earlier that instead of dropping quality (which should be avoided like the plague), just go with the lower power first. There is no harm in making something first and then adding a few more dots and lines to it. If you wanted to go from 28 to 25, which would be a better way: adding 3 or subtracting 3? That's what I thought.
Okay, good; use all the memory available. And if you have a choice of coding it, do it in a way that will make it as compatible as possible with other programs.
Refer to my last comment and the one before that. There are games that are compatible with the GameCube and the Playstation 2, and both have the same textures.
Excuses, excuses. Make the game first, since that is what is most important; then work on all the other shit you mention. Is that so hard? But again, people are impatient and demand that everything be released simultaneously. People could wait for the DLC so the company can focus on getting the online aspect functional; the online aspect is more important to a game than the DLC, right?
Tough charge. I could say the developers walk around with an attitude of "making games for your system is an honor you barely deserve" and others say, "tell me how I can make your life easier". See, the ass kissing doesn't have to be one-sided (although kissing ass isn't a traditional way of making someone's life easier/hard). You rub my back, I'll rub yours. And remember that developers abandoned Nintendo for Sony 20 years ago. The girlfriend broke up with the boy and hasn't spoken to him since.
Cartridges are inferior to compact discs: however, the miniDVD's work just like regular ones, only they're tinier. I have a miniDVD of Rush Hour 2 and it works just as well as the regular DVD.
Triple A games are spectacular games, aren't they? And you have proof that spectacular games can be made with little resources and minimal coding skills? Nothing changes: cars have had redesigns and better power capabilities, but they still work the same way. And, despite them working the same way, some cars have more power than others. But this doesn't stop people from making the cars. Plus they need money for their business, so that's a great motivation for continual production of cars. But the business is a different story: some people buy their cars; others don't. But again, that doesn't stop them from making cars; they want their business to make money. And just like people will buy yearly iterations of iPhones, people will buy yearly iterations of cars. (And Call of Duty...)
These sorts of discussions always seem to get very quote happy and formatting gets to be a mess but oh well. Similarly I am not sure some of my points were as clear as they might have been.
So design for the weakest system and scale up would be your main approach there. I am not sure it works quite as well in the real world, moreover why think when the hardware will take up my slack? If nothing else if the slack will allow me to practice a bit more abstraction then we start getting into the idea of maintainable code, code reuse and whatever else. If nothing else code should probably be more like IT in companies in general -- a cost sink that will possibly make or break your business but realistically does not bring you any funds in by itself.
On cartridges vs discs... at the time raw cost per byte, and even equaling total size was a tricky game, was enough to make scale production take note and the load time issues were hardly insurmountable. Likewise on miniSD vs DVD -- I saw quite a few games quite justifiably use the full dual layer setup, we can quibble over a few hundred megs (relative to the times, say GD-ROM vs CD) but when the alternatives are 8 times bigger then I am not so sure it holds.
Axes are fine, to get anywhere you need to then go parent and child coordinate systems and it does not get easier the deeper you go (and you need to go deeper). I am infinitely for teaching people to instead pass relevant variables to (hardware) functions instead, not necessarily understanding the underlying concepts as they do.
On the reversibility of attitudes. Perhaps, does not seem to shake out that way though and hardware devs seem to be somewhat on the losing side of the equation. It can tip around a bit and you may find a niche somewhere but generally the non hardware devs hold most of the power. What would happen if people called people on bluffs and/or if people went nuclear might be a different discussion though.
Back to the cost sink thing I reckon that probably is where I would consider approaching the lower end but still spectacularly fun to play stuff. How much great stuff has been made in flash/actionscript, lua (stuff like puzzle quest notably uses this), python, java (it kind of underpins android after all). I suppose it is more programming is not game design and game design is not programming, by necessity for many years they were lumped together. In some ways it feels like judging a board game on the creator's ability to use a CAD program and injection moulding or back on the writing a story thing without knowing how to create new words. Perhaps it is not quite at the levels of those things I mentioned, and I will not doubt for a moment many of the better people in those fields could rank as decent in said areas -- watch presentations from the better ones and you will doubtless see such things.
calmwaters I'm not going to quote everything you wrote as it would just become a convoluted mess of quote boxes and on top of that it's all off-topic discussion, but I will address your posts nonetheless.
Adjusting to "equivalent functionality" isn't a matter of CTRL+F and replacing one function name with another - if it was that easy, porting could become a completely automated process. Look at OpenGL - the latest revisions have a completely separate coding language dedicated solely to shading alone (GLSL - OpenGL Shading Language) - imagine having a shading program all compiled and working nicely on two platforms and having to re-code it from scratch for the third platform using a completely different function set which may very well offer the capabilities to render the same effects, but still requires you to start from scratch - that's a lot of work right there. Functions may require different arguments or use different variable types, the behaviour of the final program may differ between versions, they may work in different configurations and it all becomes a rather difficult struggle to get two ports that look and play exactly the same using two different toolsets that offer "equivalent functionality" - not something you want when you're working multiplatform.
The reason why I said "re-learn things" is that coders don't learn obscure Nintendo-specific coding techniques, they learn industry standards. The moment you stray away from that standard in your SDK, the road to triangle extends for all future users of that development kit simply because the coders have to accustom themselves with the new function sets. So yes, you are correct in saying that coders "never learned these things in the first place" - they learned how to do them using industry standard tools. The moment you present them with a completely different set of tools, all of their knowledge becomes completely theoretical because practically they have to learn the new "equivalent" function set first before they can even start coding, and that's a handicap when you have two other platforms that do follow industry standards.
Adjusting to "equivalent functionality" isn't a matter of CTRL+F and replacing one function name with another - if it was that easy, porting could become a completely automated process. Look at OpenGL - the latest revisions have a completely separate coding language dedicated solely to shading alone (GLSL - OpenGL Shading Language) - imagine having a shading program all compiled and working nicely on two platforms and having to re-code it from scratch for the third platform using a completely different function set which may very well offer the capabilities to render the same effects, but still requires you to start from scratch - that's a lot of work right there. Functions may require different arguments or use different variable types, the behaviour of the final program may differ between versions, they may work in different configurations and it all becomes a rather difficult struggle to get two ports that look and play exactly the same using two different toolsets that offer "equivalent functionality" - not something you want when you're working multiplatform.
The reason why I said "re-learn things" is that coders don't learn obscure Nintendo-specific coding techniques, they learn industry standards. The moment you stray away from that standard in your SDK, the road to triangle extends for all future users of that development kit simply because the coders have to accustom themselves with the new function sets. So yes, you are correct in saying that coders "never learned these things in the first place" - they learned how to do them using industry standard tools. The moment you present them with a completely different set of tools, all of their knowledge becomes completely theoretical because practically they have to learn the new "equivalent" function set first before they can even start coding, and that's a handicap when you have two other platforms that do follow industry standards.
Equivalent feature is different though. Equivalent feature means it can achieve similar, if not the same outcome. It does not mean you can just change the name of the function and expect it to work. Often times equivalent features have different requirements that need to be satisfied. There are also cases where they work differently on low level, even though they output the same result. Developers can't just use find and replace, they have to take the time to comb through the entire code and repeatedly test it to debug, all to make sure it works.
And this is the problem, time is money. Developers not only have to spend money on license fee, devkit, and any associated development cost, they also had to invest lengthy time. Time it takes to train staff, to code, to debug, etc. Developers need to make sure time they invested in is worthwhile. Otherwise the time they wasted could've been used on something else productive.
This scenario usually only happens on enhanced port or older release, which only happen if older/weaker version is selling well; enough to justify scale up development. For multi-platform developed simultaneously, it is usually develop for the strongest then scale it down.
Sorry I went so far off topic. Here'll be my last post about this.
Foxi4 Well but like trumpet-205 said, it's not a Ctrl-F function; it has to be done manually, which is indeed a pain. But, in doing things manually, you might find something that the functions have in common and could then possibly set that common ground as a Ctrl-F function. I know it would take hours and days to look through hundreds of functions to find something similar, but they would be getting paid for it. Gosh, it sounds like so much work; maybe it just sounds fun to me. I believe coders should have as much knowledge as possible; learning obscure coding techniques is hard, but it'd be worth the time. So they could learn those and the industry standard coding techniques. And time is money: you've got to commit to learning this stuff; it doesn't come naturally. But once you do learn them, then you will be able to create programs for two types of platforms, which I think is more profitable anyway. About handicaps: Helen Keller was blind, but she didn't let that stop her from living a wonderful life. Beethoven, Stevie Wonder; their works are still remembered today. They overcame their handicaps; all it takes is a little determination (and support). You can turn that theoretical knowledge into real knowledge if you put your mind to the grindstone... uh, yeah: and remember; I'll support you in this endeavour...
Foxi4 Well but like trumpet-205 said, it's not a Ctrl-F function; it has to be done manually, which is indeed a pain. But, in doing things manually, you might find something that the functions have in common and could then possibly set that common ground as a Ctrl-F function. I know it would take hours and days to look through hundreds of functions to find something similar, but they would be getting paid for it. Gosh, it sounds like so much work; maybe it just sounds fun to me. I believe coders should have as much knowledge as possible; learning obscure coding techniques is hard, but it'd be worth the time. So they could learn those and the industry standard coding techniques. And time is money: you've got to commit to learning this stuff; it doesn't come naturally. But once you do learn them, then you will be able to create programs for two types of platforms, which I think is more profitable anyway. About handicaps: Helen Keller was blind, but she didn't let that stop her from living a wonderful life. Beethoven, Stevie Wonder; their works are still remembered today. They overcame their handicaps; all it takes is a little determination (and support). You can turn that theoretical knowledge into real knowledge if you put your mind to the grindstone... uh, yeah: and remember; I'll support you in this endeavour...
Here's the thing - I wholeheartedly agree that learning obscure techniques is great and knowing the hardware you code for in and out is even better, but it doesn't make good business. Extending the development cycle is the last thing you want to do. Think of the recent Watch_Dogs situation for instance - only the Wii U version is delayed and knowing that Ubisoft is actually one of the only big name third-party companies still devoted to releasing Wii U software, I can't help but think this is genuienly due to development difficulties.
Moreover, the techniques coders will use with "equivalent" function sets only apply to the one platform they're used on and nothing else - it's not something they can learn and use elsewhere. The experience will come in handy when developing future games on that platform, sure, but it can't be used on any other, so the "educational" angle of the argument falls flat.
We're not entirely off-topic, we're still talking about the Wii U, but it's best if we return to the topic at hand for now.
Similar threads
-
- Portal
-
- Portal
-
- Portal
- No one is chatting at the moment.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@
Jayro:
Eventhough the New 3DS XL is more powerful, I still feel like the DS Lite was a more polished system. It's a real shame that it never got an XL variant keeping the GBA slot. You'd have to go on AliExpress and buy an ML shell to give a DS phat the unofficial "DS Lite" treatment, and that's the best we'll ever get I'm afraid.+1 -
-
@
SylverReZ:
@Jayro, I don't see whats so special about the DS ML, its just a DS lite in a phat shell. At least the phat model had louder speakers, whereas the lite has a much better screen.+1 -
@
SylverReZ:
They probably said "Hey, why not we combine the two together and make a 'new' DS to sell".
-
-
-
@
Veho:
Nothing special about it other than it's more comfortable than the Lite+1
for people with beefy hands. -
-
-
-
