Inside the PlayStation Suite SDK 87
New submitter Serapth writes "Sony recently released the PlayStation Suite SDK to open beta. Using PSS, people are able to write games for various PlayStation certified devices in a C#/Mono based environment. This post takes a look at what's included in the SDK, which, surprisingly, is quite a bit."
Didn't read tfa... (Score:4, Funny)
...but I'm guessing "respect for the customer" was one of the things left out.
Re: (Score:2)
Re: (Score:1)
That's like saying "can't you anti-nazi fanboys just leave hitler alone?"
Seriously, fuck Sony.
And yes, godwin in 3.
Incoherent strategy? (Score:2, Interesting)
I heard Sony was determined to forge a coherent, integrated strategy, but now I see that their phones (some of which are PS certified) are all Android based, but the PSS is mono/dotNet based. What's going on there?
Re: (Score:2, Insightful)
Re:Incoherent strategy? (Score:5, Informative)
and PS3
Nope! PSP Vita only. Well, PSP Vita and "PlayStation phone" devices only. And I guess some Sony tablet thingies.
This is basically Sony trying to compete with iOS and Android as far as I can tell.
Re: (Score:1)
and PS3
Nope! PSP Vita only. Well, PSP Vita and "PlayStation phone" devices only. And I guess some Sony tablet thingies.
This is basically Sony trying to compete with iOS and Android as far as I can tell.
I'd be moderately surprised if PS3 support isn't on the table for "later, as in once we're out of beta".
Not completely surprised, because Sony's been known to make massively boneheaded moves (like I have to remind anyone here about that), but it'd definitely land in the "dumb moves from a profit standpoint" category.
Re:Incoherent strategy? (Score:5, Informative)
Sony's own website makes mention of the supported devices requiring a touch screen, so, that kind of rules out the PS3:
You can develop games and applications that utilize physical buttons and touchscreen by using the integrated development environment (IDE) and simulator for the PC which are both included in the PlayStation(R)Suite SDK. [emphasis mine]
Then again, it's still in beta, and there are currently no requirements on what a game needs to support, so maybe the touchscreen support will be optional and you'll be required to support physical button controls as well, in order to support the PS3.
Plus, the FAQ explicitly says you'll still need a separate contract to develop PS3/PSP "Mini" games, so at present, it really doesn't sound like PS3 support is in the cards.
It seriously sounds like they're doing this solely to go after the cellphone games market. Apparently one of the demo games in the SDK is an Angry Birds clone, to give you an idea of the type of games they appear to be pushing.
Re: (Score:2)
That doesn't say that it requires a touchscreen. Just that it supports one.
Re: (Score:2)
Re: (Score:3)
This seems to be exactly what Microsoft's XNA is for the XBox. Almost to the letter.
XNA uses C#/.NET despite this not being a native language for the XBox. It doesn't expose the full capabilities of the device, so you are relegated to 'arcade-like' games which are nowhere near as complex as a real, on-the-disc game written in a proper lower-level language with hardware optimizations.
Re: (Score:3)
A lot of the top selling iOS/Android games are done with Unity [unity3d.com]; which also uses C#/Mono. Actually the PS Suite SDK looks very similar to Unity in a lot of respects.
(Actually to take it a full loop; Unity pushes to the PS anyway, Rochard and a few others have gone cross-console with Unity)
Re:Incoherent strategy? (Score:4, Interesting)
I had to scratch my head over this one until I realize that it's a kick at Microsoft... blessing the non-Microsoft incarnation of C# and making it, by definition, compatible. Truthfully though, I think Sony would be better served by sticking to the mainstream of what first string game devs are actually using. Not that I really care about the welfare of these two abusers. They make a great pair for a death spiral.
Re: (Score:2)
Re: (Score:1)
Jeez, why is this guy scored -1 flamebait?! This deserves informative/insightful mods! Wish I had some.
Re: (Score:3)
Re: (Score:3)
It's not an organized group. Slashdot works like this country does. If it were a single group then it would be totally fucked because all the bad moderation would be in a single direction. Instead there are multiple groups, and some of them aren't really even groups, just masses of like-minded people (kind of like Anonymous?) There's the faction of people who want to vote to correct bad voting. There's the faction of people who only vote up (or down) humor. There's the troll faction. And then there's severa
Re: (Score:1)
Nothing different from the current state of XNA, really, I expect. In fact, I suspect the reason Sony's using a version of the CLR (probably without the system.windows.* portion of the class tree) is to try and poach developers who are already used to using XNA.
I'm planning on looking at this just to see whether or not it'd be feasible to write code that operates in all of the XNA-supporting environments as well as the PS-certified devices and PS Vita. If it is... well, $200/year for supporting everythin
Re: (Score:1)
Re: (Score:2)
Well nothing exept the utterly absurd price tag that is..... With the returns of app stores for the average developer, its a pretty hard cost to justify.
Re: (Score:1)
Real Answer: No (Score:5, Informative)
Can anyone be a developer?
We can't provide detailed information at this stage, but we are now making the necessary preparations to allow developers to smoothly move through the contract stage. We will post information on this website as it becomes available.
Re: (Score:2)
If you don't even recognize the devices they show (Score:5, Insightful)
Re: (Score:2)
xperia play, sony's tablets, and a bunch of se phones, recognize them all.
general android deployment would be a big plus though, now the biggest selling point is the built in libs and the ability to target vita.
Re: (Score:2)
Oh Sony (Score:2)
There was a time that I worked for a video game publishing company and Sony's testing software had ZERO ZIP ZILTCH documentation. Specifically I worked on the online department. Microsoft had its Network Emulator for Windows Toolkit (NEWT) and Sony had its equivalent. It was backwards, awkward, and for a period time didn't event work (this was also around the time of the Sony network being hacked so we couldn't even release our titles if we wanted to). Figuring out how to hook their software up to our PS3s,
Oh, wow! (Score:5, Informative)
No PS3 support. Only one device (PS Vita) that has a chance to be ever used by anyone.
Windows-only release based on Mono (and loudly proclaimed announcement that not even OSX will be supported [playstation.com]).
Proprietary language controlled by a major competitor (yes, it is proprietary -- C and C++ are open, C# is proprietary).
2D only.
Free (in either meaning of the word) applications and games are not allowed [playstation.com].
Sony reserves the right to prevent anyone from using it after beta.
Everyone who will be allowed by Sony to use it after beta, has to pay Sony.
That's like Nokia and Sony had a baby.
Re: (Score:2)
It looks like it has some 3D support, but absence of an actual 3D game engine still stands out.
Re: (Score:3)
The biggest issue I could level at it is C# is a strange choice though I suspect Sony are thinking that developers are likely to come from the XBox 360 XNA world than from the Java world. So I guess it makes some sense from that perspective but I can't help but think it will severely hamper developers coming from Java or C/C++ or
Re: (Score:2)
So fucking what? There are several 3D game engines out there, use one of those. Or roll your own.
I don't think they have a 2D engine in there either.
Re:Oh, wow! (Score:5, Informative)
2. It's beta, but since it's a branded Mono Develop that means good things. iOS can only be done properly on OSX after all.
3. Yeah that was weird but they might be going for the XNA crowd.
4. There's 3D support, you're completely wrong. From their site [playstation.com]
>Rather than providing only basic samples for explaining each basic API, the SDK also gives you access to samples of games and applications using 2D and 3D graphics.
5. PSSuite will be a platform. Google can prevent anyone from using the Play store, Apple can prevent anyone from using the app store.
6. It will be $99/year, the same price as iOS development.
Looks like it's right in line with the other mobile platforms.
Re: (Score:3)
It looks more like a massively crippled platform with Sony trying to control access to the least-popular Sony-branded devices. Any combination of 2D and 3D game engines for Android would be superior in all possible ways except for Sony name not being attached to it.
Re: (Score:2)
Its because Java, and to an extent Android are horrible platforms for writing any kinds of accelerated 3d graphics.
Not necessarily. Java isn't that bad of a platform for that, and besides, anyone who's serious about it would be using the Native development kit and writing the core of the game in C/C++ anyway.
Because Android runs on multiple different video chipsets, its impossible without a high quality API like directx to create games that run the same on all of them.
Android has OpenGL ES. Meaning you only have the one high quality API you have to target. And on the PC side of things, DirectX doesn't make sure that games run the same on all devices. Compare a game running on a high end, current GPU, and a game running on one that's a few generations out of date. You'll notice a
Re: (Score:2)
So you're just gonna throw out an assertion, with nothing to back it up, and with nothing to dispute his counterpoints?
Re: (Score:2)
1. It's for mobile devices. PS Vita is the current testing platform. When PSSuite launches, it will be available on Playstation Android phones (another whole story).
And yet, there is no good reason why you wouldn't want to run these games on your PS3.
It's beta, but since it's a branded Mono Develop that means good things
Name one. You lost me at "Mono"
PSSuite will be a platform. Google can prevent anyone from using the Play store, Apple can prevent anyone from using the app store.
Google doesn't try to prevent you from making apps for their platform, they only control who can use the store. You have a point with Apple, but "they're no more evil than Apple" is not a good argument 'round these parts.
It will be $99/year, the same price as iOS development.
Let me say it again, slower, FUCK APPLE
Looks like it's right in line with the other mobile platforms.
Sure, except for Android, which is totally different since anyone can download the full source, anyone can download the SDK, and anyon
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
Before you blow a gasket bitching and moaning about the price of Apple development, need I remind you that Microsoft has the exact same costs? So every one of your "Fuck Apple" statements should be a "Fuck Microsoft" statement too?
Maybe you should try to tone down the Android fanboyism a tad. It's not like Android, no. Who cares?
Re: (Score:2)
So every one of your "Fuck Apple" statements should be a "Fuck Microsoft" statement too?
Yes, fuck Microsoft too.
Re: (Score:2)
5. PSSuite will be a platform. Google can prevent anyone from using the Play store, Apple can prevent anyone from using the app store.
But you can add other stores as an alternative to the Play store.
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Java is also proprietary, just less idiosyncratic (what is really an accomplishment for C#, to be more idiosyncratic than even Java).
Re: (Score:2)
C# is proprietary.
If tomorrow Microsoft will decide that C# must implement Qt slot/signal syntax and semantics internally, all C# implementations will have to implement Qt slot/signal syntax and semantics, or they will no longer be considered C#.
If Bjarne Stroustrup will declare the same with C++, Qt developers will support it, everyone else will tell them and Bjarne to go away, and there won't be a giant wave of bloat going through development of all compilers everywhere, blocking all useful work. Despite
Re: (Score:2)
And how exactly is Qt signal/slot system a "giant wave of bloat"? If you look at the code generated by the moc, it's not much different from what you'd do using GSignal, just that there's a tool that does the mundane for you. It's about all you can do without having real compiler support, so you need a LISP runtime, or a JVM or CLR to get it any less bloated.
Re: (Score:2)
And how exactly is Qt signal/slot system a "giant wave of bloat"?
It does not belong in the language standard. There is nothing wrong with it being handled by a preprocessor, it just should not be in the language.
It's about all you can do without having real compiler support, so you need a LISP runtime, or a JVM or CLR to get it any less bloated.
Runtime/libraries, though are handled by the same organizations and included in the same documents, are distinct from the language itself. C running on microcontrollers is not any less C when it uses nonstandard or rudimentary libraries. When libraries contaminate the language design, language becomes an amorphous blob of squishy mess.
Moc vs. Cfront (Score:2)
[Qt's system of signals and slots] does not belong in the language standard. There is nothing wrong with it being handled by a preprocessor, it just should not be in the language.
"Likewise, C++'s system of templates and classes does not belong in the language standard. There is nothing wrong with it being handled by Cfront, it just should not be in the C language." Would you agree with this as well?
Re: (Score:2)
No. C++ contains four distinct and unrelated parts of its language (C, C preprocessor, classes, templates), however they are all parts of the language, not runtine/library. Slots/signals are very much specific to the type of a library that Qt is, so it should not be inside a language. If a general-purpose macro mechanism could be made (C++ already has two, C preprocessor and templates) so slots/signals can be implemented on top of it, that macro mechanism can be allowed in the language.
Qt predates solid template implementations (Score:2)
If a general-purpose macro mechanism could be made (C++ already has two, C preprocessor and templates) so slots/signals can be implemented on top of it, that macro mechanism can be allowed in the language.
When Qt was first created, C++ compilers were defective; templates were not reliable across different brands.
Re: (Score:2)
Right, and Qt added an application-specific mechanism that solved one narrowly defined problem in a very effective but not generalized way. This is why it's not in the language.
Re: (Score:2)
Yeah, "ISO" standard. Just like .docx
Decisions are made by Microsoft, only by Microsoft, and only for the benefit of Microsoft.
Of course, Microsoft is busy trying to subvert C and C++ standards, too, but the key word is "trying". C# is their language to begin with, and they are in full control.
Re: (Score:2)
Yeah, no. Now you're just trending into the angry FUD and conspiracy theory territory.
Re: (Score:2)
Should we go again through Microsoft "open" standards being pushed through various standardization processes against all rules?
Re: (Score:2)
Do you see a difference between a C++ standard committee and Microsoft?
Re: (Score:2)
And then there would be this huge fragmentation of compilers, making it even harder to write portable code. That's not necessarily a good thing.
Re: (Score:2)
Yeah, right, C and C++ are SO FRAGMENTED!
Re: (Score:2)
Who cares about what Microsoft chooses to do in C# v(n+1)? The changes to the language are backwards compatible (an explicit design goal), and you don't have to use the new features if you don't want to. Even disregarding that, obviously, Mono will keep working just fine, and will keep claiming support for C# v(n) - just not for v(n+1). If you want portability across platforms, you'll code to v(n).
This really isn't any different from Java, or a dozen other proprietary languages out there. Which doesn't stop
Re: (Score:2)
Re: (Score:2)
When was last time anyone but Microsoft was allowed to change anything in C# language standard?
Re: (Score:2)
When they don't bother, but play lip-service to the fact it's arguable by restating their position ("yes, it is proprietary"), it's a red flag for intellectual dishonesty.
I am just sick and tired of closed things being called "open" just because there is no way to enforce proper use of the word. In 90's, I think, at least 80% of data formats, protocols and infrastructure products had names "OpenSomething" despite being completely closed in all possible ways. In 2000s a great shift happened -- companies who do that, placed some actual effort into creating the impression of "open standard" while keeping things as proprietary as ever.
Re: (Score:2)
Compared to what you normally have to pay for the privilege of developing on any of the game platforms this is a nice and easy deal to work with.
Given t
Re: (Score:2)
Everyone who will be allowed by Sony to use it after beta, has to pay Sony.
This isn't any different than most of the other programs. You pay the same amount to Microsoft and Apple for developing on their devices.
Support will be key (Score:5, Informative)
Re: (Score:2)
I think part of the problem it seems that SCE(J) writes the dev documentation, and they suck. The language issue doesn't help either.
Let me give a couple of PS2 LInux kit examples. The Kit's distro is a Red Hat variant, but NOT a mainline Red Hat, but a funky crazy Japanese variant. called Kondara.
1. At first Sony said that you would need a VGA monitor to do the install, but could then set it after installation to use the PS2's DTV or NTSC modes if desired. Some people actually did a blind install. But