Does anyone want to find some people, start an open source project, or throw some money at some programmers to make an iOS version of the Dreamseeker client?
If BYOND's main problem is income and lack of players / developers, and income comes from those people, and those people come from platforms (Windows, Mac, Linux, Andriod, iOS)... seems simple.
Flash is dying (dead?), but still viable for Andriod but the iOS market is HUGE.
It makes so much sense to me that I'm baffled this isn't already underway. I'd be willing to invest a little into seeing this get accomplished. Anyone else?
Tom wrote:
The Flash client is very simple (of course it is a limited version of the BYOND UI so that is party responsible). What we've tried to do here is create a server-client protocol that is straightforward (at the cost of some efficiency), unlike what we have for the current Windows client. The idea there is that this protocol could then be used for other clients, such as a universal HTML5 one or an iOS etc. So you really don't think that targeting iOS users (Casual Gamers) with one of the best Casual Gaming systems (BYOND) isn't going to save the project? Micro transactions is your savior. iAD space, dollar for the app, or 2 dollars + per game, Dantom gets a cut. Honestly it seems silly that you think that wouldn't work out in your favor. The entire app store concept is what has helped make Apple a fortune already, and I know a lot of app developers who are millionaires off of a single simple app. Not saying this is going to become a million dollar idea, but you can at least make tens of thousands of dollars after it gains popularity. All it takes is for NEStalgia or Feed on iOS to hit the market and you've got a flock of users coming to your system. It is good to hear the "mobile" protocol is somewhat portable in its design. I would like to hear more details on the cost of efficiency, though. At any rate, I really think a system that has 37.9 million users, 64% of those users playing games http://ansonalex.com/infographics/ mobile-video-game-statistics-2012-infographic/ is a good idea for a gaming creation platform to support. I feel an HTML5 version of the client won't be as strong or as viable as an iOS version which would allow money / income control. | |
Tom wrote:
What we've tried to do here is create a server-client protocol that is straightforward (at the cost of some efficiency), unlike what we have for the current Windows client. The idea there is that this protocol could then be used for other clients, such as a universal HTML5 one or an iOS etc. Out of curiosity, what is the progress of this? | |
We'll release what we have in January. I was really shooting for this year but it didn't happen.
| |
I'd gladly work on an iOS client if I knew what data was getting sent back and forth.
I'm currently employed as an iOS app developer. I program in Objective-C using XCode. I make apps for clients that my company acquires. | |
FIREking-- I don't doubt that Apple is a beast of a market, but it is still well behind Windows for desktop gaming, and shifting BYOND to support true mobile would be another challenge altogether (since keep in mind that the flash protocol is a client-protocol and won't work for the standalone games which dominate mobile currently). I do think it'd be cool if you could play a BYOND game on your iPad though. My point is just that we are struggling to make anything off the current setup and 2 x 0 is still 0. But we have some upcoming things that will hopefully help a bit.
I do believe that a simple networked game-creation system for modern gaming setups would do very well. Even now, so many years after we first started, I don't see anyone who has tackled this as elegantly as BYOND (as platforms like Unity, and even Flash itself don't really embrace the coolest aspect of games, which is multiplayer networking). But, as much as it pains me to admit it, BYOND may not be that system because we have built this on top of an infrastructure that is very old and largely outdated. So at some point we have to just look at it and decide if it's worth porting for the future or if it's better to invest into a better setup (or leave that for another ambitious user to handle). Like I said, a lot moving forward will just depend on the response we get to this next update (which includes the Flash as we have it). | |
I honestly disagree to Tom on this.
Windows users are mainly focused on 3D Games nowadays, iOS users can't play them at all at the moment. So I personally think BYOND would earn a lot of fame if this was available soon. | |
Keep in mind; the way BYOND works it wouldn't be able to pass Apple's App Store requirements due to the fact that it executes outside code (DM).
| |
Nadrew wrote:
Keep in mind; the way BYOND works it wouldn't be able to pass Apple's App Store requirements due to the fact that it executes outside code (DM). Then each game would have to become an app and pass approval. Then the compiled package would be evaluated by the approval department. Dantom gets a percentage of every app sold. | |
FIREking wrote:
Nadrew wrote: This is not trivial, as it means a lot more than Tom mentioned in his post. What he mentioned is the possibility of people building Dream Seeker clients externally. Hosting BYOND worlds locally is a different issue. What would potentially be possible is a generic DS client that can connect to any world. Dantom gets a percentage of every app sold. This is not easy to enforce. Something that would need to be thought out and figured out is how subscriptions would work. Apple has been known in the past to reject applications that provide their own subscription service outside of Apple's. This rule has been relaxed, but it's still something to think about. | |
Nadrew wrote:
Keep in mind; the way BYOND works it wouldn't be able to pass Apple's App Store requirements due to the fact that it executes outside code (DM). I am not to familiar with it but I know Game Maker Studio allows you to use GML and it has separate modules the developer can buy which then somehow converts it to the correct format with the click of a button. It seems to be taking off well with the inclusion of Android and IoS apps. Though I don't think YoYo takes any money from published games, they just charge a hefty price for a license for each module. | |
MaGicBush wrote:
Nadrew wrote: Specifically, the rule is that you can't run scripts as plugins that can be downloaded externally from the app. For example, if you script part of your application in Lua, it's okay, but if you can download scripts externally into your app, that is not okay. If you could host arbitrary worlds on an iOS device, then that would break the rule. | |
Unknown Person wrote:
MaGicBush wrote: Ah well that makes sense :), to bad. | |
Unknown Person wrote:
MaGicBush wrote: I want to be clear that my original concept was only to visit worlds, not host them. A client that "sends and receives packets" to / from a server (ideally hosted on linux somewhere). The client we know as Dreamseeker, and the server we know as DreamDaemon. The client would be dumb, like it is now, but unable to host games, and wouldn't physically download any scripts. | |
That said (and I will make a post on this next month when we get all of our current stuff into public testing)... we are really making next to nothing now and simply porting to new platforms isn't going to solve that problem since most users are still on Windows (that is, if we can't make anything off Windows users, adding in Mac users doesn't really help). So we have some substantial changes that will hopefully affect our finances in a positive manner next year, and that, with the goodwill of the many users here, is what we are going to need to make further updates possible. Barring that, this project has a bleak future and may just end up in the open source, which is probably what a lot of users want anyway (but be careful what you wish for as privately we do a lot of stuff here that keeps the whole system stable and I have some serious doubts that it would work without some central maintaining body).
Anyway, didn't mean to derail. Long story short: porting the newer Flash protocol will be a lot easier than trying to parse the current DS one.