(Topic ID: 173377)

Stern Software Development Platform

By PBFan

7 years ago


Topic Heartbeat

Topic Stats

  • 97 posts
  • 38 Pinsiders participating
  • Latest reply 7 years ago by phyreteam
  • Topic is favorited by 23 Pinsiders

You

Linked Games

No games have been linked to this topic.

    Topic Gallery

    View topic image gallery

    stern-programming (resized).jpg
    13177311_1155114661219483_7423252906447553483_n (resized).jpg
    25573344 (resized).jpg

    There are 97 posts in this topic. You are on page 1 of 2.
    #1 7 years ago

    Hi guys,

    as pinball hobbyists, collectors and players we often complain about the time it takes Stern to complete code, put out updates, etc.

    So I was wondering how much do we know about how their developers work? What development platforms, tools do they use? Are they still writing stuff in assembler (probably not)? Is the length of time it takes a result of an aging platform, etc?

    As a former application developer myself I am interested in the behind the scenes stuff. Does anyone have any insight on this or can point me to a link that discusses this?

    Hoping to keep this on the positive side of discussion as opposed to ranting about Stern. really curious about how it works.

    Thanks in advance everyone.

    -1
    #2 7 years ago

    Nobody is interested in this? OK, back to shopping my Shadow and playing LOTR.

    #3 7 years ago

    From a talk I saw at Pinburgh they switched away from assembly with the SAM system. It was interesting to learn that all of those old Bally/Williams DMD routines were written in assembler. I can't imagine.

    #4 7 years ago

    What surprises me is that they don't seem to have a standard template. You would think they would have a base code that they build up from. But some games that have practically no status screens would suggest that they don't do this.

    -1
    #5 7 years ago

    They may be able to start doing this now with the SAM system.. Anything written in assembly is basically impossible to templatize. I can't even imagine how they are doing that. I always assumed they had a custom compiler but.. wow. That says a *LOT* for the Stern devs, and clears up why some of the code updates take so damn long. 99% of developers couldn't hang, as they're used to being spoon fed with stuff like Visual Studio.

    #6 7 years ago

    I was told Sam and SPIKE games are written in C++. All other 90s games were written in assembler.

    #7 7 years ago

    c++ or c# ... ?

    #8 7 years ago
    Quoted from RipleYYY:

    c++ or c# ... ?

    C++. C# only ran on windows until rather recently. Plus you want a near real time environment for hardware polling like pinball.

    #9 7 years ago

    c++ than

    #10 7 years ago

    I'm definitely interested in this topic. If the community was interested you would need to find volunteers with a particular skill set - embedded software. Then you would first need to answer the question "Can enhancing/extending the code be done?" So what are the things that would need to be discovered in order to answer the question. Realistically, I don't think it can be done.

    It's not just a question of knowing the language. In fact, programming language is almost not relevant. You would have to disassemble the code. Figure out if they were using an realtime operating system (RTOS) and which one. If they were not using an RTOS, how are they handling realtime events - interrupt driven, semaphores, etc. Of tremendous importance is what microprocessor is being used, what peripherals are on board, how are bits arranged (endian order). Yikes...so much to think about. Then, once the new code is written, you'd have to manually link it with existing code (something the normally compiler/linker does).

    I think a new code base is more of a viable solution that enhancing existing code. I would love to be proven wrong! Even better would be if we could convince Stern to provide a plug-in or modular architecture that could be extended. That would be the path of least resistance.

    #11 7 years ago
    Quoted from Rdoyle1978:

    They may be able to start doing this now with the SAM system.. Anything written in assembly is basically impossible to templatize.

    Untrue. I reused a lot of routines when I was doing 6502 and 8086/8088 assembly. If you're organized it's completely possible to do. Programmers have just gotten a lot more lazy in the last 20-30 years with the high level languages that are in vogue now, and the executable sizes have ballooned with tons of redundant code. But, it is easier than assembly.

    -1
    #12 7 years ago
    Quoted from PinMonk:

    Untrue. I reused a lot of routines when I was doing 6502 and 8086/8088 assembly. If you're organized it's completely possible to do. Programmers have just gotten a lot more lazy in the last 20-30 years with the high level languages that are in vogue now, and the executable sizes have ballooned with tons of redundant code. But, it is easier than assembly.

    You're right, of course - but I guess I was trying to scale the complexity of what game code would need to do vs what my experience is, which was basically Visicalc (i.e. Excel computation), and it seemed just ridiculous to be able to get there. But my experience with assembly is pretty minimal

    #13 7 years ago
    Quoted from PinMonk:

    Untrue. I reused a lot of routines when I was doing 6502 and 8086/8088 assembly. If you're organized it's completely possible to do. Programmers have just gotten a lot more lazy in the last 20-30 years with the high level languages that are in vogue now, and the executable sizes have ballooned with tons of redundant code. But, it is easier than assembly.

    This has been going on for a long time. Assembly is more difficult to debug. Really wish we could get ahold of the original source code to old games. I have looked at doing work on games like BF, but reverse engineering a system like that is a huge investment before you even begin to code anything new.

    #14 7 years ago
    Quoted from dung:

    This has been going on for a long time. Assembly is more difficult to debug. Really wish we could get ahold of the original source code to old games. I have looked at doing work on games like BF, but reverse engineering a system like that is a huge investment before you even begin to code anything new.

    Assembly is more difficult to debug if you don't have the source, but if you have the source and label well, I never found it much harder than C to debug, especially if you have an informative window into the registers and memory variables. If you DON'T have the source and just have a dump of the assembly code, it's a nightmare to work with. But I do love the positively anemic file sizes of well-written assembly code compared to the massive bloat of high level languages these days.

    #15 7 years ago

    All this puter talk is too smart for me

    25573344 (resized).jpg25573344 (resized).jpg

    #16 7 years ago

    It's c++ and there we clearly something's that are re-used - you can see it in the score screens and bonus screens.

    -1
    #17 7 years ago

    They should use Python. Probably would get updates done 10x faster, and seems more fit for the specific cause.

    #18 7 years ago

    Yep, could have some real time code for tracking events, then a higher level scripting language for the rules.

    #19 7 years ago
    Quoted from PBFan:

    Nobody is interested in this? OK, back to shopping my Shadow and playing LOTR.

    I talked with a friend about Stern code and exactly this on friday, that it would be really interesting with a documentary with cameras present and just see how they code and work. Not with the intent of bashing, but genuine interested since I am a programmer myself.

    #20 7 years ago

    Meanwhile in the Stern software development area they are working real hard

    13177311_1155114661219483_7423252906447553483_n (resized).jpg13177311_1155114661219483_7423252906447553483_n (resized).jpg

    #21 7 years ago

    Someone leaked this photo of their advanced Spike workstations...

    stern-programming (resized).jpgstern-programming (resized).jpg

    #22 7 years ago
    Quoted from Otaku:

    They should use Python. Probably would get updates done 10x faster, and seems more fit for the specific cause.

    real time event (and interrupt) handling in a thread safe way is not something that python is going to do for you... its good at many things but that ain't one them.

    Neil.

    #23 7 years ago
    Quoted from NeilMcRae:

    real time event (and interrupt) handling in a thread safe way is not something that python is going to do for you... its good at many things but that ain't one them.
    Neil.

    Multimorphic

    -E

    #24 7 years ago
    Quoted from PinMonk:

    Someone leaked this photo of their advanced Spike workstations...

    I think I just wet myself. That is hilarious!

    #25 7 years ago
    Quoted from eli_lilly:

    Multimorphic
    -E

    That's only after the low level code is written... then perhaps you could create a system that allowed people to script the rules in python. However, Python is not an appropriate language for embedded programming. Assembly, C or C++ are the typical languages. You're working at a much lower level. It is very likely that you'd be coding to specific memory addresses, using registers, etc. You need some knowledge of computer architecture and real time concepts such as interrupts, semaphores, mutexs, etc. You likely would need a Comp Sci or Comp Eng background. I'm not saying it's rocket science but it's not like programming in Visual Basic either.

    #26 7 years ago
    Quoted from konjurer:

    That's only after the low level code is written... then perhaps you could create a system that allowed people to script the rules in python. However, Python is not an appropriate language for embedded programming. Assembly, C or C++ are the typical languages. You're working at a much lower level. It is very likely that you'd be coding to specific memory addresses, using registers, etc. You need some knowledge of computer architecture and real time concepts such as interrupts, semaphores, mutexs, etc. You likely would need a Comp Sci or Comp Eng background. I'm not saying it's rocket science but it's not like programming in Visual Basic either.

    You are indeed correct on all accounts.

    #27 7 years ago
    Quoted from konjurer:

    I think I just wet myself. That is hilarious!

    Yeah, the thought of something before even those tape machines cracked me up, so I dug out that picture of the Spike advanced interactive punch card programming system.

    #28 7 years ago

    Stern currently uses Sourcery CodeBench with the Atmel SAM9G platform(Spike) on Linux kernel 2.6.30. A moderate amount of the "base" code is shared between games (but is not limited to); lamp effects, base-language, coin door operation, coin meter, node board communications and diagnostics, node board switches, ticket/redemption, backbox lighting, slam tilt, start button, playfield tilt, generic tournament settings, active ball counter, ball save, display interactions..

    #29 7 years ago

    There we go ... The start of some interesting discussion.

    There must be someone out there that actually knows how stern does this. I wouldn't think they have a very sophisticated development environment because if they did code updates would roll out in a more timely fashion. I know they have to focus on the most recent games but I think they could easily sell enough extra games if they had a better release schedule. Hiring an extra programmer would not be that expensive or that hard unless the development environment was just not what newer developers are interested in. (Kind of like the issues we had as mainframes started to die-off - couldn't get a new grad to touch it with a 10 foot pole).

    #30 7 years ago
    Quoted from phyreteam:

    Stern currently uses Sourcery CodeBench with the Atmel SAM9G platform(Spike) on Linux kernel 2.6.30. A moderate amount of the "base" code is shared between games (but is not limited to); lamp effects, base-language, coin door operation, coin meter, node board communications and diagnostics, node board switches, ticket/redemption, backbox lighting, slam tilt, start button, playfield tilt, generic tournament settings, active ball counter, ball save, display interactions..

    Which makes the long spells between code updates and general launch condition of their code pretty inexcusable. That's a pretty plush development environment, with opportunities for substantial re-use of codebase if the projects are managed well.

    #31 7 years ago

    Subscribed

    #32 7 years ago
    Quoted from phyreteam:

    Stern currently uses Sourcery CodeBench with the Atmel SAM9G platform(Spike) on Linux kernel 2.6.30. A moderate amount of the "base" code is shared between games (but is not limited to); lamp effects, base-language, coin door operation, coin meter, node board communications and diagnostics, node board switches, ticket/redemption, backbox lighting, slam tilt, start button, playfield tilt, generic tournament settings, active ball counter, ball save, display interactions..

    Makes sense to do it that way but it also begs the question. Why the blue blazes does it take so long for them to update the code ?
    We use a system at work where all the safeguards are taken up by subroutines and any new modes we add to a device simply have to correctly integrate with those sub routines to ensure that nothing catastrophic can go wrong. It is then a relatively straightforward process to debug the code for the new modes.

    #33 7 years ago

    Speaking from experience, there are only so many hours in a day and you can only dedicate so many resources to one machine. How many machines vs. programmers do they have?

    I can't speak for Stern process but if they are run like any other major corporation, I wouldn't be shocked if half the day of a programmer isn't sitting in some meeting.

    #34 7 years ago
    Quoted from eli_lilly:

    Multimorphic
    -E

    P-ROC uses a low-level C library for interfacing with hardware:
    https://github.com/preble/libpinproc

    #35 7 years ago
    Quoted from Sonny_Jim:

    P-ROC uses a low-level C library for interfacing with hardware:
    https://github.com/preble/libpinproc

    Sort of, but that doesn't interface directly to the driver board system. That just provides a mostly language-agnostic wrapper that you can interface to the P-ROC from higher levels while providing a single point of change for future P-ROC updates while leaving as much of the higher level frameworks untouched as possible (there are several now).. The real "real-time" stuff happens at the FPGA level within the P-ROC.

    #36 7 years ago

    It takes so long because coding these things is not about how easy it is to type code into a studio environment. I'm not excusing the time they do actually take to get it out. But it's not the platform that's causing it. It's the seven things that go wrong whenever you change one other thing. It's the correct implementation of the result trees and score balancing. It's getting the mechanics to respond properly. It's about tweaking the timing. Etc, etc. The coding environment is a minor concern.

    #37 7 years ago
    Quoted from Sonny_Jim:

    P-ROC uses a low-level C library for interfacing with hardware:
    https://github.com/preble/libpinproc

    Well sure, and PC game designers aren't writing video and sound drivers either. My point is, assuming a sufficient abstraction layer, the game CAN be written in Python. Multimorphic has already demonstrated this.

    -E

    #38 7 years ago

    As a software developer (supply chain/ERP), the only constant is that code has errors and is hard to test. I can only guess, but due to all the random factors, testing pinball code must be a nightmare. We write testing scripts but those are only as good as how well you can control those factors. We have teams run those test scripts and document the results. Another group reviews and approves the test scripts and results. Even with this in place, a minor change can impact something you didn't consider or didn't find until it goes live in a unrelated area.

    I can give Stern a pass if they are slow to update. At some point, you'll only get bug fixes and not new features. The risk is always more bugs or you break something else that didn't show up during testing. At some point, the code is "finished"...bugs and all.

    That being said, I'd like more transparency on what's being worked on. I think it's better to communicate that even if it's just to say "we are only addressing bugs" or "there's no active development taking place." We might not be happy with the answers but at least we would know.

    #39 7 years ago

    I can't help but think that having different game code for the different versions of games (Pro/Prem/LE etc) has slowed the software development process considerably. As has been previously mentioned, seemingly minor changes in code can have consequences that were unexpected and each code revision requires adequate testing.

    #40 7 years ago
    Quoted from eli_lilly:

    Well sure, and PC game designers aren't writing video and sound drivers either. My point is, assuming a sufficient abstraction layer, the game CAN be written in Python. Multimorphic has already demonstrated this.
    -E

    I don't think any serious manufacturer is going to be writing their games in Python anytime soon.

    #41 7 years ago
    Quoted from PinBallMagician:

    As a software developer (supply chain/ERP), the only constant is that code has errors and is hard to test. I can only guess, but due to all the random factors, testing pinball code must be a nightmare. We write testing scripts but those are only as good as how well you can control those factors. We have teams run those test scripts and document the results. Another group reviews and approves the test scripts and results. Even with this in place, a minor change can impact something you didn't consider or didn't find until it goes live in a unrelated area.
    I can give Stern a pass if they are slow to update. At some point, you'll only get bug fixes and not new features. The risk is always more bugs or you break something else that didn't show up during testing. At some point, the code is "finished"...bugs and all.
    That being said, I'd like more transparency on what's being worked on. I think it's better to communicate that even if it's just to say "we are only addressing bugs" or "there's no active development taking place." We might not be happy with the answers but at least we would know.

    than again, some ideas we've proposed could be hard to put in place, and having some coding experience i understand and i agree
    but for sure, some bug corrections are really easy to do :

    - bad insert colors in BALLROOM
    - inserts "100" not beeing light at 100 ghosts (to 119, as at 120 its starting again with the "20")
    - having a unique "priority" sample at 100 ghost (or even 99) to prevent the player that mass hysteria is coming... yesterday, i have so much thing going on in the same time, that i get the "mass hysterai multiball" sample almost 15 or 20 seconds after it has began, was so late that i laugh at it
    - "build-in points" variable not reseted when missing the gear award & river of slime "hurry up"
    - P K E lanes blocked at maximum X20 (as on some others pins i know), why ? just let it grow with no limit
    - ...

    #42 7 years ago
    Quoted from FawzmaGames:

    Speaking from experience, there are only so many hours in a day and you can only dedicate so many resources to one machine. How many machines vs. programmers do they have?
    I can't speak for Stern process but if they are run like any other major corporation, I wouldn't be shocked if half the day of a programmer isn't sitting in some meeting.

    Not only that but for each game they have to program a pro version and a Premium/LE version with different hardware.

    -1
    #43 7 years ago
    Quoted from Sonny_Jim:

    I don't think any serious manufacturer is going to be writing their games in Python anytime soon.

    Sure, but that's largely because they're doing it the way they've always done it, or at least the way they've done it since the time they moved from assembly to C++.

    -E

    #44 7 years ago
    Quoted from eli_lilly:

    Sure, but that's largely because they're doing it the way they've always done it, or at least the way they've done it since the time they moved from assembly to C++.
    -E

    No, there's much greater reasons why you wouldn't want to use Python in your commercial product and it's not because of inertia.

    #45 7 years ago
    Quoted from eli_lilly:

    Sure, but that's largely because they're doing it the way they've always done it, or at least the way they've done it since the time they moved from assembly to C++.
    -E

    Ehh, I don't think so. Python just isn't suited for this kind of hardware environment. Could you MAKE it work? Maybe, but it would be ugly. Certain languages are suited for certain tasks. It's like saying you should switch to Logo for Stern pin development. Only slightly less crazy than using Python.

    #46 7 years ago
    Quoted from PinMonk:

    Ehh, I don't think so. Python just isn't suited for this kind of hardware environment. Could you MAKE it work? Maybe, but it would be ugly. Certain languages are suited for certain tasks. It's like saying you should switch to Logo for Stern pin development. Only slightly less crazy than using Python.

    It's not even close to the logo comparison, the need for a Turing complete language is implicit. All I'm seeing is vague responses as to why the higher-level "game" part of a pinball couldn't be done in Python. I know it can, the game itself is just a state machine. Heck, for one thing, Mission Pinball Framework already does it. The PC game industry often uses a similar model, the game engine is written in C++ but the game itself is scripted in a "lighter" language.

    Would you think a pin could be developed in Javascript? If your answer is no, take a look at the massive amount of Flash-based games. Many, if not most, are more complex than a pin. All are written in ActionScript, which is essentially a derivative of Javascript.

    -E

    #47 7 years ago

    Note that I'm talking about commercial pinball development, not P-ROC/MPF. I'm not saying it's impossible to use Python for this, just that you wouldn't if you were making a business out of it. I think you are of the belief that Python makes everything super easy, when in reality it's just as easy to write it in C++.

    #48 7 years ago
    Quoted from Sonny_Jim:

    Note that I'm talking about commercial pinball development, not P-ROC/MPF. I'm not saying it's impossible to use Python for this, just that you wouldn't if you were making a business out of it. I think you are of the belief that Python makes everything super easy, when in reality it's just as easy to write it in C++.

    I'm going to go out on a limb and assume you're referring to compiled vs interpreted languages, when you say that Python wouldn't be good for commercial applications. If this is true, what's your reasoning behind that statement. If not can you explain what you mean because sometimes you have ELI5, for me to understand.

    #49 7 years ago
    Quoted from Sonny_Jim:

    I don't think any serious manufacturer is going to be writing their games in Python anytime soon.

    I would consider Dutch Pinball a serious manufacturer, and I believe both TBL and BoP2.0 are written in python. There is no reason you can't use python, if using something like P-roc with its interfaces, that provides the needed realtime reaction to flipper, pops, slings, diverters, etc. That setup gives you the real time responsiveness you need, but the flexibility of a language like python. And while @epthegieek is not a 'serious manufacturer', his CCC is another example of a successful pinball machine written in python. I have not heard of any reports of CCCs not behaving as expected as far as responsiveness or having any latency issues.

    Quoted from PinBallMagician:

    the only constant is that code has errors and is hard to test

    The biggest challenge in testing software is often testing not what you expect a user to do (and what was coded based on that), but what they actually do. With a pinball machine, not only is there the player as a 'user', but in some ways the ball is also a 'user'. So combine those things with all of the different things/modes happening that all need to work in conjunction with each other, and the possible number of permutations relative to the sequence of events is massive. Even when things break, trying to figure out what that sequence of events was that led to the bug can be quite daunting.

    #50 7 years ago

    I feel like a kid at the Thanksgiving table trying to get in on the conversation, but don't have any idea WTF the adults are talking about. I still find it interesting though.

    Code updates from Stern take too long and I'd love to know what research they have done on making the system of update cycles faster.

    There are 97 posts in this topic. You are on page 1 of 2.

    Reply

    Wanna join the discussion? Please sign in to reply to this topic.

    Hey there! Welcome to Pinside!

    Donate to Pinside

    Great to see you're enjoying Pinside! Did you know Pinside is able to run without any 3rd-party banners or ads, thanks to the support from our visitors? Please consider a donation to Pinside and get anext to your username to show for it! Or better yet, subscribe to Pinside+!


    This page was printed from https://pinside.com/pinball/forum/topic/stern-software-development-platform?hl=rocketpin and we tried optimising it for printing. Some page elements may have been deliberately hidden.

    Scan the QR code on the left to jump to the URL this document was printed from.