Farsight comes clean on issues with 360 platform

[Sean DonCarlos]

Serenseven is correct. (I'm guessing he came to this conclusion from my previous posts). Zen has the advantage of designing the tables to work within thier framework of code, where we have to design the framework to work with the tables.

I did. I used to develop software for a manufacturer of video surveillance systems; one of my jobs was to get third-party devices like card access systems and point-of-sale terminals to communicate with our hardware. Nowhere near as exciting as emulating a pinball table's ROM, but some of the design challenges were similar. From that experience I was able to connect the dots between your previous posts and work out why TPA is designed the way it is, even though that design makes 360 updates horribly inconvenient.

Hopefully I did at least a halfway-decent job explaining it to the non-coding readership here...and hopefully I'm not stepping too close to any "classified" information. Please let me know if I am; I'd hate to see you catch any grief from management because of my interest in TPA's internals.

 

[aagstn]

This is not the first time we have heard from small developers having these issues with Microsoft. I went ahead and bought TPA on PS3 since Sony seems to work with small developers and allows them to patch the game as needed without bankrupting them to do it. I had already bought everything up to pack 3 on the 360 and liked playing with the 360 controller, but I just want to support Farsight and get my DLC in a reasonable time frame.

 

[Jeff Strong]

Serenseven is correct. (I'm guessing he came to this conclusion from my previous posts). Zen has the advantage of designing the tables to work within thier framework of code, where we have to design the framework to work with the tables.

Gameroom has the advantage of all the inputs and outputs are the same for every single Atari game. So emulating it is straightforward. The special features and toys on a pinball table all behave differently.

Rockband has the advantage of just needing a music file plus timings for all the moments where you hit the correct buttons. They don't need to patch cause no executable code is necessary.

It's impossible for me to write the code for every table ahead of time. So a patch is necessary to add new tables. Even if we put the code in DLL form in the DLC, it would require lengthy approvals and submission fees for each DLC. And then instead of being able to say 3 packs with one patch, we would have to do separate certifications for each pack.

The problem is like he said with TOM. Each table has some special toys on it that don't behave the same as toys on another table, so it's really hard to program for that ahead of time without doing the table.

Good info, Mike. I didn't see this before I posted earlier....although, as a coder myself, I still don't understand how Zen can release new tables without adding new code for the table scripting/rulesets? Even for TPA tables that don't use ROMs (Black Hole, Gorgar, etc.), you still have to add new code for the scripting, correct? So how does Zen get away without adding new code when all their tables are 100% scripted? Do they just put all the various table variables for the ruleset in a flat file (XML or something similar) as I suggested earlier, and then their engine does the rest? If so, that's pretty impressive in its own way.... Anyway, thanks again for the info and great communication.

 

[Sean DonCarlos]

Good info, Mike. I didn't see this before I posted earlier....although, as a coder myself, I still don't understand how Zen can release new tables without adding new code for the table scripting/rulesets? Even for TPA tables that don't use ROMs (Black Hole, Gorgar, etc.), you still have to add new code for the scripting, correct? So how does Zen get away without adding new code when all their tables are 100% scripted? Do they just put all the various table variables for the ruleset in a flat file (XML or something similar) as I suggested earlier, and then their engine does the rest? If so, that's pretty impressive in its own way.... Anyway, thanks again for the info and great communication.

I don't want to drown this thread in technical arcana any more than I already have, but the short answer is yes, they could, using the method you described. PM me if you'd like to discuss more in depth.

 

[DJ Clae]

It's too bad these issues weren't better forseen. They could have tempered expectations more. Now we have to wait much longer than expected for new content.

 

[Jeff Strong]

I don't want to drown this thread in technical arcana any more than I already have, but the short answer is yes, they could, using the method you described. PM me if you'd like to discuss more in depth.

It's fine to continue the discussion here as it is relevant to the topic and I think there are others besides myself who are interested in and curious about this. I'd also like to hear more from Mike on it as well. If Zen is able to add new tables that are 100% scripted without adding any new code, then color me impressed. I realize that a lot can be achieved by passing along variables in XML files since I've written my fair share of applications that do exactly that, but nothing as complex as a digital pinball machine, and their tables are getting more and more elaborate and unique as time goes on.

 

[Sean DonCarlos]

OK, if you insist...

I did a very similar thing to make our surveillance systems talk to many different third-party device using many different data formats (some used ASCII, some used raw hexadecimal, others did more bizarre things) and massage the incoming data to and from the standard format used in the rest of the software. There was a set of "filters", one for each third-party device, that contained data that represented the "rules" for talking with that device. These rules were composed of very basic elements, but could be combined in various ways to enable complex processing, like recognizing credit card numbers on cash register printouts and masking the first 12 digits. The engine had the code to interpret the rules in the filter and process the incoming/outgoing data, but it was all very general-case: only those basic elements in the rules had to be implemented, everything else was multiple elements run in sequence.

You could analogously have a "pinball engine" that reads in "rules" composed of basic elements, such as play DMD animation, play sound file, increase the score, illuminate an insert, fire a kickout, maintain a count of how many times a particular object has been hit, test whether a switch is in a given state, etc. The engine has code that corresponds to each of these basic elements and actually performs whatever action is called for. Then you can combine these together to do more complex things, like "when this scoop is lit for jackpot and is hit, play jackpot animation and sound, increase score by 3M, illuminate insert #62 (which might correspond to the relight shot for the jackpot) and set the relight hit counter to 3 (decrement to 0 relights jackpot), pause 2 seconds, then fire kickout". This complex rule can be implemented in terms of the 7 simpler elements above.

The engine just sees the sequence of the 7 simple rules and executes the corresponding code in order, it doesn't know nor needs to know that this is the jackpot sequence. But on some other table where the jackpot is 15M and the animation/sound is different and it only takes 1 shot to a different target with a different insert to relight, you do not need any additional engine code to accomplish that. You just modify your "jackpot rule" with the new values for the new table. Or even on the same table, you can modify all the values and use the rule to implement a simple mode. There's nothing that says it must be used only for jackpots. So you can get a lot of mileage out of just a few basic elements if you code them wisely and make them general-case enough. If you have a wide enough palette of basic elements implemented in your engine, as Zen almost certainly would given they're on their fourth (?) iteration of their pinball game, you probably could accomplish some extremely complex behaviors. Not complex enough to properly emulate a ROM and its environment, instruction set and I/O accurately like TPA does, but enough to implement multiballs and intricate modes and so forth.

Whether this is actually similar to how Zen (or Silverball Studios for that matter) does it, I have absolutely no idea. I don't even play Zen. But it is certainly possible.

 

[Jeff Strong]

Yeah, it seems possible. It also seems like it would be easy to oversimplify something like this on paper, but maybe that's exactly how they're doing it.

One also has to wonder where MS draws the line between code and data. Looking at how elaborate some of Zen's latest tables are, it would appear that some of those variables might need to be highly complex arrays. I wonder if a developer can include anything in a variable or array in a DLC file as long as there are no functions?

It's just too bad that MS is so draconian about these things. Maybe it would be best for Farsight, from a financial standpoint, to go the retail disc route on 360.

 

[DJ Clae]

I thought the reason the new code to support additional tables couldn't be included in the DLC was the size limit. So to get around this they update the core game program instead.

 

[Sean DonCarlos]

I thought the reason the new code to support additional tables couldn't be included in the DLC was the size limit. So to get around this they update the core game program instead.

The new code isn't in the DLC because then each DLC has to go through a certification process, and FarSight has to pay the fee for each one. Instead, FarSight puts the code in a title update so that multiple DLC packs can share one update, reducing cost and the number of certification procedures everyone has to suffer through.

The size limit is what caused problems with the title update last time, as the code for the new tables was larger than 4 MB, which is the "maximum" allowable size for a title update.

 

[Mark W**a]

They've only had one patch on 360 so far, correct? And that was their free on, correct?

 

[Richard B]

They've only had one patch on 360 so far, correct? And that was their free on, correct?

They had a title update and an optional update. Not sure if those are considered separate or part of the update. They weren't released at the same time.

 

[Richard B]

. . . It's too bad these issues weren't better forseen. They could have tempered expectations more. Now we have to wait much longer than expected for new content. . . (DJ Clae)

It's just too bad that MS is so draconian about these things. Maybe it would be best for Farsight, from a financial standpoint, to go the retail disc route on 360.

The easiest solution would be for MS to relax some of these overly-tough standards, or make exceptions for circumstances like these. The rules were likely put in place to prevent a flood of shoddy, heavily-bugged games, but there are unintended consequences for such strict, broad laws.

 

[Sinistar]

The easiest solution would be for MS to relax some of these overly-tough standards, or make exceptions for circumstances like these. The rules were likely put in place to prevent a flood of shoddy, heavily-bugged games, but there are unintended consequences for such strict, broad laws.

No developer support= no one to pay for doing that job , $4,500. per patch equals less patches , higher rate of well developed games on marketplace , and or more money in Microsoft's pockets from developers . Do you see a pattern here ?

Supposedly Gates once said I'd rather pay a lazy man to find the best way to do business , than a smart man , the lazy man will make it cheaper .

 

[Brandon Debes]

Supposedly Gates once said I'd rather pay a lazy man to find the best way to do business , than a smart man , the lazy man will make it cheaper .

You've got both bits of that wrong. Firstly, Hlade's Law, the aphorism to which you are referring, was never uttered by Gates (or Henry Ford, the other person to whom it is often misattributed). And secondly, it states, "If you have a difficult problem, give it to a lazy man; he will find an easy way to do it" It says nothing about smart men or cost.

 

[Mike Reitmeyer]

OK, if you insist...

I did a very similar thing to make our surveillance systems talk to many different third-party device using many different data formats (some used ASCII, some used raw hexadecimal, others did more bizarre things) and massage the incoming data to and from the standard format used in the rest of the software. There was a set of "filters", one for each third-party device, that contained data that represented the "rules" for talking with that device. These rules were composed of very basic elements, but could be combined in various ways to enable complex processing, like recognizing credit card numbers on cash register printouts and masking the first 12 digits. The engine had the code to interpret the rules in the filter and process the incoming/outgoing data, but it was all very general-case: only those basic elements in the rules had to be implemented, everything else was multiple elements run in sequence.

You could analogously have a "pinball engine" that reads in "rules" composed of basic elements, such as play DMD animation, play sound file, increase the score, illuminate an insert, fire a kickout, maintain a count of how many times a particular object has been hit, test whether a switch is in a given state, etc. The engine has code that corresponds to each of these basic elements and actually performs whatever action is called for. Then you can combine these together to do more complex things, like "when this scoop is lit for jackpot and is hit, play jackpot animation and sound, increase score by 3M, illuminate insert #62 (which might correspond to the relight shot for the jackpot) and set the relight hit counter to 3 (decrement to 0 relights jackpot), pause 2 seconds, then fire kickout". This complex rule can be implemented in terms of the 7 simpler elements above.

The engine just sees the sequence of the 7 simple rules and executes the corresponding code in order, it doesn't know nor needs to know that this is the jackpot sequence. But on some other table where the jackpot is 15M and the animation/sound is different and it only takes 1 shot to a different target with a different insert to relight, you do not need any additional engine code to accomplish that. You just modify your "jackpot rule" with the new values for the new table. Or even on the same table, you can modify all the values and use the rule to implement a simple mode. There's nothing that says it must be used only for jackpots. So you can get a lot of mileage out of just a few basic elements if you code them wisely and make them general-case enough. If you have a wide enough palette of basic elements implemented in your engine, as Zen almost certainly would given they're on their fourth (?) iteration of their pinball game, you probably could accomplish some extremely complex behaviors. Not complex enough to properly emulate a ROM and its environment, instruction set and I/O accurately like TPA does, but enough to implement multiballs and intricate modes and so forth.

Whether this is actually similar to how Zen (or Silverball Studios for that matter) does it, I have absolutely no idea. I don't even play Zen. But it is certainly possible.

Making the game data driven is one way to simplify the development. We do that with some of our stuff. Mostly it's the unique table objects and goal detection that's table specific. This is where using code is required.

One way around the certification to add code is to use a scripting language. The problem for us is the tables are too complex to handle with just scripting.

Since Microsoft is Zen's publisher, it's quite possible the submission fees are waived (since it's the publisher who pays them), so patches or putting code in the DLC wouldn't be an issue for them.

 

[Jeff Strong]

Since Microsoft is Zen's publisher, it's quite possible the submission fees are waived (since it's the publisher who pays them), so patches or putting code in the DLC wouldn't be an issue for them.

That would be my guess too.

 

[Sinistar]

You've got both bits of that wrong. Firstly, Hlade's Law, the aphorism to which you are referring, was never uttered by Gates (or Henry Ford, the other person to whom it is often misattributed). And secondly, it states, "If you have a difficult problem, give it to a lazy man; he will find an easy way to do it" It says nothing about smart men or cost.

That's why I did not use quotes , and again it was something I heard secondhand .

 

[Matt McIrvin]

One way around the certification to add code is to use a scripting language. The problem for us is the tables are too complex to handle with just scripting.

Huh. So the definition of "code" here is native executable code rather than just anything Turing-complete?

 

[Mike Reitmeyer]

Huh. So the definition of "code" here is native executable code rather than just anything Turing-complete?

Yes. Scripting would be interpreted code which isn't the same thing as compiled code which would be the native executable code.