New to pinball?

I am guessing they are under staffed for the job at hand

Metallica should have been updated as a ton missing. ST is very early days.

Why? Because we buy em unfinished.

Im sure code takes a lot of time. Probably why you wont see a Stern Lcd soon because that would be twice the work I imagine of DMDs.

Look at SM. Give Lyman some time and space. He wont disappoint.

ding ding ding

I share your curiosity and frustration, but I think that your suggestion of employees, sitting around and wasting time is completely unwarranted. I've learned that if you dont know how something works, that instead of critisizing it, ask questions instead to learn a thing or two. Given that both Stern and JJP are going throught the same issue that way, maybe there's more to it than meets your ignorant eyes?

One thing that I think needs to be considered is that NOBODY has stated that it's wise to buy a machine before the code is done. If this is an issue for you (or you're more mature than some of us and/or don't have faith in the system), then you're better off waiting until the code has been proven. Buy an AC/DC instead of a StarTrek or Metallica right now.

The only way I see this being a real problem is if the pins are sold out before the code is done. Right now, that doesn't seem to be the way things work unless you're talking LEs -and even then, many LEs are still available for older titles.

Final line: Patience is a virtue!

Most software companies release software unfinished....hence the need for service packs. Pinball is no different. Why tie up revenue for code when you can release it for sale and update it later on? Makes sense to me (especially since I am in software)

Maybe he's new on the hobby but he have reason,I'm waiting for new code for Metallica,Avengers,WOZ and X men and I have to say it's not funny to play with the incomplete game with complete payment,time pass and the trill of the new game pass
My comment

stern doesn't need polished code to move nib machines they sell no matter what they do. trying selling your huo machine with incomplete/unfinished code is a different ball of wax.

bottom line is if stern really cared about about their customers and the machines they produce every 4 months there would be finished code and all mechanisms would be functioning as advertised more or less.

as it is now you pay ever increasing prices to be a beta tester for a year or longer.

i think it's a pretty poor way to do things imo, but they are moving product and that's what is important. how can you blame them for this behavior?

when customers stop buying nib machines with unfinished code that's when stern will take notice, until then enjoy unboxing nib beta machines

Stop buying them. It's never going to change, and if the game isn't a "winner", there will be no code dates at all.

I'm pretty sure that is not really true There are so few examples of finished code in the world.

You can always update software - and it's not just Stern doing it. I remember the original hype of JJP stating that WOZ "will ship with complete code". It didn't. Is it a bad thing? Not really. It gets the games out there to be played.

It's the old 80/20 rule. Getting software working 80% takes 20% of the time. The remaining 20% takes 80%. That's when you get into all the details, and making little changes can ultimately impact something else you didn't anticipate, causing you to spend a lot of time fixing bugs that crop up.

A bigger problem than the current late code/unfinished code issue is lack of communication. The "head in the sand" approach just makes things worse than saying vague things like "Hey guys, we're working on it...great things are coming!" I grilled George & Gary at a PPE seminar last year about this very thing, and stressed how important communication with customers is concerning code. They said they'd try to change, and we did get the press release about TF and Xmen code. It was a start...and there were a few FB posts about Xmen code coming up...but that was the last time that sort of thing happened. They more they ignore the problem, the more people bitch about it. All it takes is a statement here and there to calm fears.

Because people are buying them. Stop buying incomplete games and make your voice heard.

What are the coders on their staff doing? I think I read they program in a variant of C. I know guys who write C and I think they could probably finish a game in a week or so of eight hour days. There has to be a lot of cut and paste, hell all the sound effects and animations are already there.

This is so funny it's stupid. You obviously have no idea how difficult coding can be, in any language. Heck, you can easily spend a hour, day *or* week just tracking down a bug, especially if the events leading up to the bug appear to be random.

And the sound effects and animations are not "just there", someone had to create and tune these.

I obviously don't know the Stern process, but WTF? Are they all off playing tournaments and going to expo? Surfing pinside from their work computers? Chatting on the phone with their girlfriends?

Yup. No clue.

I really want someone to break down the coding process for pinball for me. Because it's obviously harder than I think, or there's something else going on.

I'm a graphics guy, but I can write some code. I used to do a lot of Actionscript (actual coding, not just frame tween nonsense), I have a CIS background, I've written in a lot of languages including some C before I decided to bail on being a programmer, I'm not utterly unaware of how this stuff works.

But I freely admit it's not my profession and I'm certainly no expert in pinball coding. These games are pretty simple really from a logic perspective. Obviously to do something like TSPP is tricky, you have a lot of things interacting simultaneously, and I'm not discounting the time needed to actually come up with the rules and craft the game, it's not just rote coding. But still, it's not exactly rocket science is it? There are a limited number of variables to control, there are only so many inserts and switches to keep track of. Surely they have standard libraries and APIs for this stuff by now. So what's the bottleneck when months and months go by without things moving along? I have to think it's more about Stern than it is about programming challenges.

Anyone have any insights?

100% correct

If Stern put 1/2 of the energy into public communication as they do with their pre-release PR videos, it would do wonders in making people feel better.

Because people buy the machines anyway?

Chris

I always 'ass'umed that the term incomplete code referred more to incomplete rules or unfinished code. I don't think there are many actual bugs, machines hanging up or rebooting, starting/stopping modes out of sequence, sounds or images occurring with the wrong switches.

It seems like they do a great job of making sure that the code is 99% finished as far as those things are concerned.

As for modes not implemented that is just business. Given the choice, no one wants to wait an extra six months for v6.0 of any table to be written before we get our hands on the table. There are numberless examples of willing consumers who will pay for beta versions of various products.

Yeah, no, I'm not talking about "bugs" in that sense. I'm just saying that the rules for pinball aren't particularly complicated in terms of what you need to keep track of. Sure, you can stack modes and create depth with various strategic tricks, but at the end of the day you're hitting targets, triggering switches, and incrementing variables. Does it take time to make it all work right? Sure. But what is it that takes months and months and months? That's what I want to know.

From working on CCC I can say that stacking things compounds complication very quickly - but you'd think the stern guys would be really used to that. It's not as if every new game is a complete fresh start.

Maybe they're all just super busy working on the 'next' system since that would be a fresh start, and nobody has time to buff out game code details.

Here's how I've always understood it (and Ep or Keith or whomever, feel free to correct this...) Let's say that you've got 50 switches. The code gets ultra complex fast.

You hit a switch. Directly following that switch, you have one of potentially 50 that you can hit, making just the amount of possible interactions from just those first two being 50 x 50, or 2500. Add the next, third switch in, and with only three switches, you already have 125,000 possible combinations of what could be triggered when.

All of these things need timing together worked out and to see what interactions work. With 50 switches and an average of 100, I believe that the possible combination of things that could happen in a single ball is a googol.

While you can obviously make some of those independent of each other and stuff like that, unlike a regular program where one thing leads into another, "the ball is wild" and it's hard to account for how everything will interact together properly at all times.

It's FAR more complex than it seems on the surface.

My guess is the timing. The delay between the switch being triggered, and the board getting the signal, then the software reacting to it. Then the switch is off when the ball rolls by, so that has a delay which the software needs to account for when it cycles, then do the logic, then do everything again because the ball doesn't stop, then factor in crazy multiball with numerous balls hitting things.....sounds like a PITA to me.

It's all a big black box to me. I'd be curious how much code is reused between tables.

OT, I wish that there easier ways for old code to be updated to complete the modes/rules for older machines. Like with DESW and now JP, is that one of the original code writers or how is he able to rewrite the program? It wouldn't hurt those companies that are now out of business so it would be nice to see what the community could do with some of the amazing pinball tables that they built if the rules were to be completed, deepened, balanced, refreshed.

Like I said it's all a black box to me.

Would you call that more of a technical challenge, like a pure coding challenge, or more of just a logic challenge? Are you mapping them out in any way? I would imagine you need to assign priorities to things so you know what should override something else when there's a conflict.

I wouldn't say it's as complicated as THAT, really. For starters there are certain switches that can get removed from that math as they only come directly after some other (like on a ramp). But the fact that you can't really anticipate most of what might happen next does complicate things. You end up with a lot of checking things like "Do (thing) but only if (other thing) or (other other thing) isn't already doing something" instead of just Hit Switch -> Do action.

Stern has lots of beta testers. "Us"

It does make you wonder why Stern doesn't do something to remedy it. It would go a long way in terms of PR at the very least. The three tier game program really has added stress to what seemed to be a rushed process when there was one type and 2 games a year. Why they don't do fewer games a year seems to be an easy step. Even if they continue with the 3 tier system, would it really be that bad to get a complete new game every 12 to 14 months instead of incomplete ones every 4 months. #Snow ball effect.

As someone stated earlier, maybe I'm oversimplifying something that is more involved; but less variables with more development time usually has a better chance of being complete. What I do know is staying the course will not allow for anything to change for the better. Metallica brought me back after the WOF experience. Although different, looks as though limited resources played a role in both. Fool me once shame on them, fool me twice shame on me. I have seen the light and will let future project come to completion prior to buying. Regardless of theme.

No axe to grind, wish them well but I will not support a damaged business model.

Alan

The pyprocgame framework has a system built in for handling priorities that is actually really handy - but if you want things stacked up running at the same time, it gets a little tricky. Mostly with the display.

With pyprocgame, each 'mode' gets a priority value and they're processed in descending order, so whatever has the highest gets switches first and goes to the display first. Switch handling down the chain can be blocked at any point to prevent lower actions from happening. And if the highest priority mode has nothing on the display, the next highest is shown.

But how pyprocgame's system works probably doesn't relate to how stern does things, so I can't really speak for that.

Ah, the switch timing stuff makes sense as a challenge, I buy that. However once you've got the game set up it seems like you should be pretty set with that kind of stuff when it comes to building in new modes. I say seems, obviously something is a lot harder than I think!

And it's not like every switch combo means something usually. As an easy example, if you're hitting an outer loop obviously you want to check the right switch after you hit the left one, because otherwise you didn't complete the loop. But every other switch on the playfield is pretty meaningless otherwise.

I think you are wrong.

To me it is not a big deal as long as there is a relatively complete set of software out within a few months of game release and then updates every few months. ACDC was on the outer edge of what we should stand for, but on the other hand it is the most complex rule set ever. Some games seem to wait many months just for a decent release and then nothing afterward. This is not acceptable.

Let's hope ST gets better treatment in this department than some of the other recent games.

Right, I'm just pointing out how complex it can be.

It's interesting because some of the more complex code-wise games you can actually sort of see how they 'think' by watching how they resolve certain stacked hits.

Why would it? ...and if it did, how should the people who own the last few previous titles feel?

Still thanks for the insight, that's helpful. You'd think Stern would have a framework for SAM that provides similar benefits.

It's kind of like "spouse" code, where she wants me to take out the garbage unless she isn't quite finished adding things to it or unless there's something else she wants me to do first. I've been married for years and I still haven't figured out the logic behind that code...

XM should be worked on before Metallica I mean it's been out over a year and the code is horrible.

Lyman is on MET and the code will get updated.

The initial code for 'was this ramp hit' and so on is more complicated than you'd think. Have a look at a loop sometime--there's often a spinner, then a switch in the back, then another switch on the other side, say.

Setting the timing intervals for those to be hit and counted as a right loop vs. a left loop (and not both) and not getting confused is actually nontrivial--several games that I'm aware of get this wrong and can be easily fooled into giving you a shot that you haven't made. With fewer switches this problem becomes worse, not better, since you have less awareness of where the ball actually is: this is why you can cheat the Powerfield jackpot on TZ, for instance.

You also need to get stuff like controlled gate timings down just-so at this point, holding them open long enough that both fast and slow shots make it through without allowing the player to jam the ball back through them when they're not supposed to be able to. The up-posts used on modern stern games to feed the pops (like on Metallica or Iron Man) need to stop the ball and then pop down to allow the ball to roll over them without unduly slowing the game down (of course, they don't really work right anyway).

Then, once you actually have all the 'shots' individually recognised (at least in single ball play ), you have to get all the if-then stuff right. Unfortunately, as the Nemo guys found out, just running a giant state machine isn't really enough, since (amongst other things) you want stuff to time out all the darn time, such as combo logic. You don't just care what switches have been hit and what order, but also in a lot of cases how long ago that was. The Crate on Elvira, for instance, always plays the sound effect for hitting it, but doesn't always give you credit towards multiball/jackpot depending on what else has happened recently.

Worse yet the processor in these things is teeny-tiny, so the machine bogging down is a big problem. As a symptom of this, you can look at the playfield flashers when a lot of things are going on---they often start flashing slightly slower (depending on the generation of the machine). Lyman hates-hates-hates bog, apparently, and so spends a bunch of time making sure that the machine doesn't use up more than all of the available clock cycles. This is transparent to the user--they don't notice something that takes ages, but do definitely notice if it goes poorly as it screws up the timing on things like shot recognition/callouts/sound effects. I'd guess than pin programmers use a lot more time optimising for runtime efficiency these days than most do, as pins are very Real Time and also have crappy processors (less true for JJP than Stern).

Multiball is another things that I'm sure takes forever to get right. Keeping track of what's going on is much harder than in single ball play, for obvious reasons, and keeping up with the often-flashy effects of multiball is I'm sure challenging.

Also, multi-use insert logic is I'm sure a pain in the ass. On lots of recent sterns one insert means a bunch of different things depending on context, and getting context right is probably un-fun. (On spiderman, for instance, the white arrows are mode start/mode shot/doubler/tripler/jackpot.)

Someone mentioned somewhere that the Hammer-drop code on Metallica was taking Lyman forever to get right. Realtime system code interacting with things like a gravity-dropped hammer can take a bunch of fiddling to sort out, and apparently things were really buggy in older versions of the code.

Ultimately I'm sure things like 'programming a the game rules mode' take much less time than all the behind-the-scenes stuff to make that mode actually work. However, this part of the programming actually requires playing the machine a bunch to decide what's fun, and hopefully integrating the mode with the theme and playfield design. It's unfortunate that the same guy is in charge of both "game design" in the software as well as making all the little nit-picky stuff work: the skill-sets for these two things are very different. Pin manufacturers seem to think that game design begins and ends with the playfield, and in fact have gone backwards on integrating the actual "game" (in software) with the playfield since the heyday of the 1990s, where the playfields were obviously designed with the rules in mind. The modes in games like spiderman or star trek are much less integrated with the playfield than the ones in, say, TZ or TAF.

Who cares how those other people feel? They bought the wrong pin!

Seriously, it's the luck of the draw. Code seems to be very different in terms of how good it is, how done it is, and how timely it's updated from pin to pin.

Avengers code seems to have been more complete very early after release compared to other pins. Are you saying that Stern was wrong to do that because other pins still needed to have their code improved/updated....and it might make those owner feel bad?

not likely but for the 7500$ stle price i will "hope" you bet right. good luck with it.

I played ST, it is in the same boat as Met, and some have posted here it has been in the works for almost 18 months. The game appears to be further along than most initial releases but after spending time on it, the polish and detail anyone above a casual walk up would expect is just not there.

It sad but true..

did a little bird tell you this? and if not why can't stern come out and say code is coming? i am getting tired of waiting for code like many here.

Then sell it!

Seriously, would it really make you feel better having an official announcement from Stern saying that Lyman is working on the code for MET? You really have doubt that he is?

Your write up was really insightful, I have no idea if it's all a guess or if you write pinball software for a living but is sure makes a lot of sense!

I think what you said in the quote above is key as far as the user experience goes. Without code there isn't a machine made that I would want to play. It's not about flipping a ball around a playfield. I need a reason to do it, and I want to feel rewarded when I am doing it well. That's the magic.

yes it would make me feel better if there was better communication, absolutely!

I strongly disagree, ACDC is very nuanced, with lots of scoring potential, but the basic rules are almost Sys-11 simple. Three multiballs to stack on whatever song mode you're playing, with the Super features and other odds and ends thrown in. Most of the complexity is merely in scoring values - how song shots build value and are tracked, etc... Now, the 12 songs are each quite unique, but the overall setup of the game is pretty basic. I still say the most complex game/rules is still TSPP. What other game allows the player to build up to stacking multiple wizard modes? WOZ is getting close to surpassing TSPP but not there yet IMHO.

I understand about wanting communication, but on something like this I really don't see what the big deal is since we all know that it is being worked on. And believe me, it is.

Great point, that kind of optimization can definitely be a time-consuming headache. It's kind of ridiculous that it's 2013 and we're even talking about that still, but hey.

Also, I should add that as a designer often times the end product looks "easy". That took 10 minutes right? And people didn't see the weeks of iterations and discarded ideas that it took to end up with something that seems simple but is just right.

let me guess...a little birdie told you? as much as i believe you if the message was coming from stern hq it would hold more weight obviously.