The Hotness
Games|People|Company
The Binding of Isaac
Hearthstone: Heroes of Warcraft
Hearts of Iron Anthology
Dungeon Master: Chaos Strikes Back
Race the Sun
DUELYST
Hack 'n' Slash
Shin Megami Tensei: Persona 4
GUN
Rayman
One Finger Death Punch
Wars and Battles
Batman: Arkham Asylum
Final Fantasy VII
Final Fantasy X
Chrono Trigger
Shenmue
Professor Layton and the Curious Village
Fatal Frame
Hearts of Iron III
Hearts of Iron II: Doomsday
King's Quest V: Absence Makes the Heart Go Yonder!
Battlefield: Bad Company 2
Psychonauts
Disgaea: Hour of Darkness
Metal Gear Solid
Alan Wake
The Simpsons: Hit & Run
Super Mario Galaxy 2
The Legend of Zelda: Majora's Mask
Deus Ex
Red Dead Redemption
God of War
Burnout Paradise
The Sims
Metro 2033
Gears of War
Silent Hill: Homecoming
Tom Clancy's Rainbow Six: Vegas
The Witcher
Hearts of Iron III: Semper Fi
Panzer General
Silent Hill: Origins
Portal 2
Wild Arms 5
The Three Musketeers: The Game
Minecraft
Assassin's Creed: Brotherhood
Tom Clancy's H.A.W.X. 2
Fallout: New Vegas
Recommend
10 
 Thumb up
 Hide
90 Posts
1 , 2 , 3 , 4  Next »   | 

Dominion Online» Forums » General

Subject: Discussion concerning iOS Dominion rss

Your Tags: Add tags
Popular Tags: fud [+] [View All]
Matthew Roskam
United States
Birmingham
Alabama
flag msg tools
mbmbmbmbmb
Some thoughts on the upcoming iOS implementation of Dominion;

1) it is really sad that the unofficial version is pulled while we continue to wait ... And wait.... And wait for the official version.

2) we are all very concerned about costs. I think we are all hoping for a reasonably priced "pay per expansion, but play forever" model. Pay per play, or subscription play I think will cause a massive rejection. IOS community hates such business models in general.

3. The choice of HTML5 based code was high risk, and we are already paying for it. In general, the promise of 'writing code once' to run on all platforms, has never worked well in the history of computing. It sacrifices speed, efficiency, and ease of use for being a universal app.

4. I hope everyone understands that the HTML5 interface is why it must have connectivity to the Internet. The game will work on servers on the Internet, which is a very poor solution for iOS. It also explains why the business model will require too much money- because if the servers go away, so does the game. Someone has to pay for the massive bandwidth such a popular game will require- and it will be us. A very poor model for the user, and an expensive maintenance model for the publisher. The burden has to be passed to the consumer (that, again, is you).

5. The publisher was obviously impressed by the pedigree of the presenter, rather than insisting on seeing actual success on mobile computing platforms. Evidently, the contract must be really bad, and some of our very best games will be held hostage for many years to come by a clearly ill advised programming approach, and business model.

6. The community is screaming for offline play, while the programmers continue to claim they will look at it, "if that is what the community really wants". Well, it is pretty obvious that is what we want. Pretending that this fact is not overwhelmingly obvious is insulting. They know they would have to completely change their code to do it- that is why it will not happen anytime soon. The game was doomed the day they wrote the first line of code in HTML 5- at least for iOS, anyway.
13 
 Thumb up
1.00
 tip
 Hide
  • [+] Dice rolls
David desJardins
United States
Burlingame
California
flag msg tools
mbmbmbmbmb
Mwroskam wrote:
I think we are all hoping for a reasonably priced "pay per expansion, but play forever" model.


I'm sure that's not true. A lot of people were complaining about the "pay per expsnsion" model, they would rather just pay a modest monthly fee when they actually are playing the game, and not pay a bunch of cash up front for something they might lose interest in.

Quote:
I hope everyone understands that the HTML5 interface is why it must have connectivity to the Internet.


This is not true either. Your browser can execute Javascript whether it's connected to the internet or not. There's no reason that entire standalone apps can't be written in HTML5 and Javascript. Note that the server portion of Dominion is also written in Javascript.

Quote:
Someone has to pay for the massive bandwidth such a popular game will require- and it will be us.


Not true either. Games like Dominion require negligible bandwidth after the initial download and caching of assets. Sending messages back and forth to the server about what cards you play just doesn't add up to anything significant, even for thousands and thousands of simultaneous users. BGG uses vastly more bandwidth and it's still free. YouTube uses vastly more bandwidth than BGG, and it's still free!

Quote:
The community is screaming for offline play, while the programmers continue to claim they will look at it, "if that is what the community really wants". Well, it is pretty obvious that is what we want.


I don't think the BGG or Isotropic community are very representative of the broader user community they hope to have.

Quote:
They know they would have to completely change their code to do it


Nope. How much Javascript programming have you done, anyway?

There are valid points and issues buried in here, but most of them overstated or misstated due to ignorance.
11 
 Thumb up
1.05
 tip
 Hide
  • [+] Dice rolls
Matthew Roskam
United States
Birmingham
Alabama
flag msg tools
mbmbmbmbmb
David,

Disappointed with your responses. Hoping for a little more respect in the conversation. This is the sort of conversation I was hoping to generate, without the insults. Oh well, that's BGG...

As a former VP of a robotics company, and programmer of database systems, I can assure you I know what I'm talking about when I talk about code. JavaScript is an uncompiled, and inefficient way to do serious coding as opposed to objective C. The card interactions are complex in Dominion, especially with all the expansions. I can understand why they would want those interactions handled server side. But the truth reamins-JavaScript does NOT run as efficiently as objective C on an iPad. Period.

The other part of the design decision is a debate that is very old- does intensive processing of code belong on a client or a server? If I chose to process on a server on the Internet, then I am Internet dependent. Yes, it could be migrated to the client as you suggest, but that would again, be better done in a compiled coding language.

As far as the whole HTML 5 approach, If I am dependent on a browser to interpret code, then I have to have a browser running in the background, to handle the calls correctly. That is a substantial amount of memory, much of it unused by the actual program, and does not offer the flexibility objective C does.

As to what the larger community will tolerate as a business plan, any opinion is as valid as another - the community will answer that for themselves...but I bet I'm right, (if they ever get it rolled out, we will find out!) :-)

I would point out also that, if there is minimal demand on the server, then why did they collapse like a wet taco on opening day? And if you want to use YouTube as an example of "free bandwidth", then I guess we can look forward to advertisements? Or ownership by google?

Just build me a solid game for iOS, please! Like the 'unofficial' one! That way, if something goes away on the Internet, my investment isn't rendered useless!


7 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
David desJardins
United States
Burlingame
California
flag msg tools
mbmbmbmbmb
Personally, I don't like the idea of implementing complex games in HTML5 myself. I'm very skeptical, I don't think it will work well compared to native, compiled implementations. But the fact remains that most of your original statements are wrong. HTML5 games don't require internet connectivity. An online implementation of Dominion doesn't require massive or expensive bandwidth. Running the existing Dominion engine offline in the client's browser doesn't require major code changes. These claims just aren't true. You don't make your argument stronger by founding it on incorrect premises.
2 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Matthew Roskam
United States
Birmingham
Alabama
flag msg tools
mbmbmbmbmb
Test
Well, if it's so simple to change it over to client side then I guess we can expect that at any moment! That is good news!

And while it is true that HTML5 can run completely client side, that would be a pretty stupid approach, as you pointed out. You don't write in HTML5 unless you are taking a client server approach, unless your a programmer that doesn't know any other languages. THAT is what I was saying.
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
ŁṲÎS̈
United States
Mesa
Arizona
flag msg tools
F*** it! Do it LIVE!
badge
Didn't know what to spend all this sweet GG on, so I bought the overtext.
mbmbmbmbmb
Mwroskam wrote:

3. The choice of HTML5 based code was high risk, and we are already paying for it. In general, the promise of 'writing code once' to run on all platforms, has never worked well in the history of computing. It sacrifices speed, efficiency, and ease of use for being a universal app.


I'm betting we're typing our BGG posts on different operating systems, and possibly different browsers.

Mwroskam wrote:

4. I hope everyone understands that the HTML5 interface is why it must have connectivity to the Internet. The game will work on servers on the Internet, which is a very poor solution for iOS. It also explains why the business model will require too much money- because if the servers go away, so does the game. Someone has to pay for the massive bandwidth such a popular game will require- and it will be us. A very poor model for the user, and an expensive maintenance model for the publisher. The burden has to be passed to the consumer (that, again, is you).


You want everyone else to understand something that you don't understand?
HTML5 code can easily be wrapped in a package that can be deployed to an app store and run offline. And nothing about objective C allows you to run a multi-player game of Dominion without an internet connection.



Mwroskam wrote:

6. The community is screaming for offline play, while the programmers continue to claim they will look at it, "if that is what the community really wants". Well, it is pretty obvious that is what we want. Pretending that this fact is not overwhelmingly obvious is insulting. They know they would have to completely change their code to do it- that is why it will not happen anytime soon. The game was doomed the day they wrote the first line of code in HTML 5- at least for iOS, anyway.


The community should continue to scream for offline play. They have AI on there servers. It's nothing as good as Keldon's for RftG, but it's fun to play against. Goko should convert it from whatever server side tech they're using into JS and add it to their client code.


1 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
David desJardins
United States
Burlingame
California
flag msg tools
mbmbmbmbmb
Mwroskam wrote:
I would point out also that, if there is minimal demand on the server, then why did they collapse like a wet taco on opening day?


Two reasons, neither of them having to do with the game requiring "massive bandwidth". One was an implementation bug and the other was the initial surge of traffic as clients everywhere try to download the assets at the same time, especially the art. This isn't representative of the traffic needed to play the game, as those assets only get downloaded once and not everyone at once, except at launch. I don't think they handled the launch well, but it says nothing at all about the sustained bandwidth needed to host the game over time.

Quote:
Well, if it's so simple to change it over to client side then I guess we can expect that at any moment!


This is the fallacy of false dichotomy. There are not only two alternatives, "they would have to completely change their code to do it," and, "it's so simple to change it over to client side then I guess we can expect that at any moment". The truth is neither of these.
2 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
David desJardins
United States
Burlingame
California
flag msg tools
mbmbmbmbmb
monteslu wrote:
Goko should convert it from whatever server side tech they're using into JS and add it to their client code.


As I wrote above, the server-side code is already in Javascript.
1 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Matthew Roskam
United States
Birmingham
Alabama
flag msg tools
mbmbmbmbmb
Test
Curious how you know the bandwidth requirements .. Have they published those?

Also, aren't you concerned about dependency on a server that may go away later? I would probably drop as much as $50.00 for the total dominion package (it is my favorite game). But not if I'm depending on a company that has already stumbled so badly out of the gate. Not sure I would support a monthly subscription... Rather hope they fail and we can get a real app!
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
ŁṲÎS̈
United States
Mesa
Arizona
flag msg tools
F*** it! Do it LIVE!
badge
Didn't know what to spend all this sweet GG on, so I bought the overtext.
mbmbmbmbmb
Mwroskam wrote:
Well, if it's so simple to change it over to client side then I guess we can expect that at any moment! That is good news!


Why? It was never a technical problem. They'll do it if the parties involved want to do it.

Mwroskam wrote:

And while it is true that HTML5 can run completely client side, that would be a pretty stupid approach, as you pointed out. You don't write in HTML5 unless you are taking a client server approach, unless your a programmer that doesn't know any other languages. THAT is what I was saying.


Funny, you think that people writing JS on client and server do it because they only know one language? That must mean all the guys at google, microsoft and others that are using Node.js must be total amateurs.

If you're starting a new project does it make sense to read data via SQL into your persistence framework into your server side language, then convert into XML or JSON and then push it to your client? How about reading the same objects out, manipulating them in JS, and sending them back over a websocket without having to translate the objects again.


There is no one right way to do this.
1 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
ŁṲÎS̈
United States
Mesa
Arizona
flag msg tools
F*** it! Do it LIVE!
badge
Didn't know what to spend all this sweet GG on, so I bought the overtext.
mbmbmbmbmb
DaviddesJ wrote:
monteslu wrote:
Goko should convert it from whatever server side tech they're using into JS and add it to their client code.


As I wrote above, the server-side code is already in Javascript.


Awesome!

Did Goko post that somewhere?
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
David desJardins
United States
Burlingame
California
flag msg tools
mbmbmbmbmb
Mwroskam wrote:
Curious how you know the bandwidth requirements .. Have they published those?


It's easy to estimate, but there are also people in the beta (not me) who have observed the actual server traffic themselves. You can easily watch not just how much data is going back and forth, but even what it is. You can send an awful lot of text messages with less bandwidth than a single image.

Quote:
Also, aren't you concerned about dependency on a server that may go away later?


Sure. As I wrote above, I have many concerns about their approach. That doesn't stop me from objecting to false claims, though.
1 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
David desJardins
United States
Burlingame
California
flag msg tools
mbmbmbmbmb
monteslu wrote:
Quote:
As I wrote above, the server-side code is already in Javascript.


Did Goko post that somewhere?


I don't know. I heard it from them directly. I'm not a great source of inside information but this is one fact I do know. They are trying to demonstrate that it's easy to build games for their platform and so they want to enable people to do everything in a single language and programming model. I don't know if that's the best approach, but it's the one they took. It does have the side effect of making it easier for them to run the server code offline as well, if they want.
2 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
ŁṲÎS̈
United States
Mesa
Arizona
flag msg tools
F*** it! Do it LIVE!
badge
Didn't know what to spend all this sweet GG on, so I bought the overtext.
mbmbmbmbmb
DaviddesJ wrote:
monteslu wrote:
Quote:
As I wrote above, the server-side code is already in Javascript.


Did Goko post that somewhere?


I don't know. I heard it from them directly. I'm not a great source of inside information but this is one fact I do know. They are trying to demonstrate that it's easy to build games for their platform and so they want to enable people to do everything in a single language and programming model. I don't know if that's the best approach, but it's the one they took. It does have the side effect of making it easier for them to run the server code offline as well, if they want.


Interesting, they're hitting a different port for their websocket endpoint than the rest of the game and content. And not everything on 80 is static. Was assuming it was something other than node because of that.

I've used various technologies for server push over the years, and nothing has been nearly as easy as node with socket.IO/engine.IO.


 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Matthew Roskam
United States
Birmingham
Alabama
flag msg tools
mbmbmbmbmb
monteslu wrote:


Funny, you think that people writing JS on client and server do it because they only know one language? That must mean all the guys at google, microsoft and others that are using Node.js must be total amateurs.

If you're starting a new project does it make sense to read data via SQL into your persistence framework into your server side language, then convert into XML or JSON and then push it to your client? How about reading the same objects out, manipulating them in JS, and sending them back over a websocket without having to translate the objects again.


There is no one right way to do this.


I didn't say that people who write in JS do so because they cannot write in another language!

A programmer that knows multiple languages chooses the code that is best for the job. I have written JavaScript when it was the best language to use (like on a web page).

If I am writing for iOS, I write in objective C. Just because I could write it in another language doesn't mean I should! Efficiency, speed, and the platform I want to run on should be the consideration. You seem to know what you are talking about. I'm sure you would agree that objective C is more efficient on iOS...
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
David desJardins
United States
Burlingame
California
flag msg tools
mbmbmbmbmb
Mwroskam wrote:
I didn't say that people who write in JS do so because they cannot write in another language!


There must be two Matthew Roskams! The other one wrote: "You don't write in HTML5 unless you are taking a client server approach, unless your a programmer that doesn't know any other languages."
1 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
ŁṲÎS̈
United States
Mesa
Arizona
flag msg tools
F*** it! Do it LIVE!
badge
Didn't know what to spend all this sweet GG on, so I bought the overtext.
mbmbmbmbmb
Mwroskam wrote:
monteslu wrote:


Funny, you think that people writing JS on client and server do it because they only know one language? That must mean all the guys at google, microsoft and others that are using Node.js must be total amateurs.

If you're starting a new project does it make sense to read data via SQL into your persistence framework into your server side language, then convert into XML or JSON and then push it to your client? How about reading the same objects out, manipulating them in JS, and sending them back over a websocket without having to translate the objects again.


There is no one right way to do this.


I didn't say that people who write in JS do so because they cannot write in another language!

A programmer that knows multiple languages chooses the code that is best for the job. I have written JavaScript when it was the best language to use (like on a web page).

If I am writing for iOS, I write in objective C. Just because I could write it in another language doesn't mean I should! Efficiency, speed, and the platform I want to run on should be the consideration. You seem to know what you are talking about. I'm sure you would agree that objective C is more efficient on iOS...


Objective C is definitely more efficient on iOS. That said, I am not really a fan of it. Mostly because i think header files are old school. Though that's a minor quibble.

I think when written properly JS and HTML5 are good enough for things like Dominion. And good enough while being crossplatform is much better than a few more frames/sec in a walled garden.


 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Matthew Roskam
United States
Birmingham
Alabama
flag msg tools
mbmbmbmbmb
The point her is the DESIGN decisions, not whether or not you can write client side code in JavaScript. They chose HTML5 because they wanted to do a web based game, not just an iOS game. They sold it on the idea that HTML5 runs on "any platform", so the client could be an Apple, a windows machine, an IOS device, etc. that is why they wrote it in HTML5. They chose the language that was correct for the approach they wanted to take. I am disagreeing with the approach itself. An Internet dependent game, even when playing against a computer opponent. I was saying they used HTML5 because they had already decided on that approach. They are reported to have had $3 million in seed money for the company. They could have taken any approach they wanted, in any language they wanted.

Think about how great some of the existing iOS apps are. I can play Puerto Rico completely disconnected from the Internet - or TTR- or the old Dominion. If I want to play online, I can do that as well.

There are times you can't get access- like standing in line at the department of motor vehicles...I can guarantee you I would like to play dominion during that agonizing process!

I know JavaScript can run completely locally- I never said it couldn't - but I know a company with $3 million dollars wouldn't do that unless they intended to take a client server approach...or were drunk...
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Matthew Roskam
United States
Birmingham
Alabama
flag msg tools
mbmbmbmbmb
DaviddesJ wrote:
Mwroskam wrote:
I didn't say that people who write in JS do so because they cannot write in another language!


There must be two Matthew Roskams! The other one wrote: "You don't write in HTML5 unless you are taking a client server approach, unless your a programmer that doesn't know any other languages."


Uhmmm.. You really can't see the distinction? JavaScript is for BROWSERS... If you don't intend to use a browser, I don't think it's the best programming language for iOS...can you agree with that?
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
David desJardins
United States
Burlingame
California
flag msg tools
mbmbmbmbmb
Mwroskam wrote:
They chose HTML5 because they wanted to do a web based game, not just an iOS game. They sold it on the idea that HTML5 runs on "any platform", so the client could be an Apple, a windows machine, an IOS device, etc. that is why they wrote it in HTML5.


There's a lot of mindreading here. How do you claim to know what they thought and why they did what they did? I've actually talked to Ted Griggs about exactly this, so if we're having a competition to see who knows better what he thinks and why he's doing what he's doing, I think I have a bit of a leg up on you. From what he told me, the second statement is true but the first statement is not true. Yes, they want to enable people to implement games and run them anywhere. No, that doesn't mean they have to use a client-server model, they just chose that for Dominion because they (and Donald X!) think the most interesting way to play the game is against other people. It's a bit much to castigate them for thinking that solo play isn't the most important feature for Dominion, when the designer of the game feels the same way. Even if you disagree with them, it's hardly a crazy point of view.
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
David desJardins
United States
Burlingame
California
flag msg tools
mbmbmbmbmb
Mwroskam wrote:
If you don't intend to use a browser, I don't think it's the best programming language for iOS...can you agree with that?


I agree that you don't think it's the best programming language for writing standalone applications.

I don't agree that this is a fact or that everyone else agrees with it. Different people have different opinions and choose different languages for different reasons. Not always the reasons you would have or the choices you would make.
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Matthew Roskam
United States
Birmingham
Alabama
flag msg tools
mbmbmbmbmb
I'm not trying to have a competition, I am trying to have a conversation! I know I am not the only person upset that an app forces people to have connectivity, and will eat away at their data allowance, even when they're playing solitaire. I also know that I am not alone in being frustrated over the repeated delays in rollout (we have had two major promise/ pullbacks now).

I hate to see some of the communities best games tied up in such major failures. I think the approach taken has everything to do with these problems. Architectual decisions are far more impactful than any other decision made in programming.

Please tell us what you know from your conversations... We sure aren't getting any info from anywhere else!
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Mike Miller

Columbus
Ohio
msg tools
Columbus, OH's best all '90s rock cover act: facebook.com/oddjobpolicy
badge
I can't believe your head exploded. If your head explodes, you'll never make it on BGG.
mbmbmbmbmb
Mwroskam wrote:
I'm not trying to have a competition, I am trying to have a conversation! I know I am not the only person upset that an app forces people to have connectivity, and will eat away at their data allowance, even when they're playing solitaire. I also know that I am not alone in being frustrated over the repeated delays in rollout (we have had two major promise/ pullbacks now).

I hate to see some of the communities best games tied up in such major failures. I think the approach taken has everything to do with these problems. Architectual decisions are far more impactful than any other decision made in programming.

Please tell us what you know from your conversations... We sure aren't getting any info from anywhere else!


When was the second roll-out? I only remember one failed launch.
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Matthew Roskam
United States
Birmingham
Alabama
flag msg tools
mbmbmbmbmb
Test
They promised roll out was imminent at the time the unofficial app came out, saying it was mere days away, so yeah... This has been a loooong wait.
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
ŁṲÎS̈
United States
Mesa
Arizona
flag msg tools
F*** it! Do it LIVE!
badge
Didn't know what to spend all this sweet GG on, so I bought the overtext.
mbmbmbmbmb
Mwroskam wrote:
I'm not trying to have a competition, I am trying to have a conversation! I know I am not the only person upset that an app forces people to have connectivity, and will eat away at their data allowance, even when they're playing solitaire. I also know that I am not alone in being frustrated over the repeated delays in rollout (we have had two major promise/ pullbacks now).


I also want offline play. We should all tell goko we want offline play. They haven't implemented it, but nothing in there architectural decisions have precluded it.

 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
1 , 2 , 3 , 4  Next »   | 
Front Page | Welcome | Contact | Privacy Policy | Terms of Service | Advertise | Support BGG | Feeds RSS
Geekdo, BoardGameGeek, the Geekdo logo, and the BoardGameGeek logo are trademarks of BoardGameGeek, LLC.