WIP: Visual Pinball in Unity (2021 Edition)

[freezy]

Hi folks,

 

It's been over 1.5 years and 700+ posts at VPF, so I thought why not start a new thread to summarize things.

 

Visual Pinball Engine, or VPE, is a port of Visual Pinball to C# and Unity. It's open source and compiles for Windows, macOS and Linux. We've had it running on Android and iOS as well, but that's currently not our focus.

 

There are three main reasons why we've started such an endeavor:
 

1. Tooling. By extending the Unity editor, creators can work in a full 3D environment while creating tables.
2. Scripting. A lot of code that authors paste into their tables could be included in the engine, making the need of custom scripts minimal.
3. Rendering. Unity's HDRP delivers fantastic visuals and is continuously maintained and updated to work with new hardware features.

 

So here we go. It's still work in progress, but let's dive into it.

 

Physics

 

We've decided to port Visual Pinball's physics to VPE. It works, but there are few performance bottlenecks that need to be fixed, and of course, a few bugs. So far we have implemented native support for nFozzy's flipper physics, and we are working on adding his other improvements as well (rubber dampening, flipper tricks).

 

Using VP physics means backwards compatibility and realistic flipper behavior, but also a few drawbacks, mainly:
 

• Static environment - Moving colliders need to be duplicated. This is fixable but has a performance cost. More optimization work is needed here before addressing this.
• Incompatibility with other engines - We can't easily use let's say PhysX for Junk Yard's wrecking ball or any other simulations on the playfield.

 

File Format

 

VPE can read and write the VPX file format. This is nice, because you can use the Unity editor for your VPX table, work on it, export it, load it back into VPX, and it works.

 

We don't know yet what the final file format will be. My best guess is a new .vpe format based on .vpx that keeps VPX-compatible data within the VPX structure.

 

There will also be an authoring format. Rather than a file format, this is a version control friendly file structure used during table creation, that allows quick import and saving.

 

I'm fairly certain that the authoring format is going to be Unity's project structure, since it's made for exactly that. So importing a binary would create that structure automatically which would be the "source of truth", so to say, for exporting.

 

Having an VCS-compatible format is a big deal in my opinion. It allows working much more transparently. "Small" table tweaks could end up in pull requests in the original table repository instead of new mod releases, and this might result in the community working closer together with less friction and conflicts.

 

Graphics

 

VPE uses Unity's new Scriptable Render Pipelines, which consists of URP and HDRP. While we try to keep URP "working", we're currently focused on HDRP.

 

@Pandeli is the boss here, and he's working on a HDRP project with good defaults (today we propose to use the default scene, which isn't ideal). Currently he's looking into how to deal with transparency. Here a shot of CFTBL, which is particularly hard to deal with, due to the numerous plastic ramps.

 

 

There's still many things to do, namely inserts and GI, but it's already looking pretty awesome. Here a video showing how the indirect reflection and planar reflection all contribute to the scene.

 

 

This took quite some time to set up, and Pandeli is working on automating most of it, and document parts that are difficult to automate.

 

Here another video from @Rowlan who put two tables into a nice environment:

 

 

Note that this is an unmodified import from VPX, and the quality of materials will significantly improve once creators start spending time with Unity and get the hang of how HDRP works.

 

Final note concerning graphics: Right after posting these kind of shots, people usually ask what about specs and framerates. For us, the goal is to get 4k at 60Hz on previous-gen hardware (currently Nvidia Pascal), and we consider that doable. This is of course with all the bells and whistles turned on. Unity supports multiple quality settings, so apart from reducing resolution, you'll be also able to turn off specially power-hungry features. Personally I have a GTX 1080 in my cab which runs at 1080p, so there you have it, the current recommended requirements.

 

Scripting

 

Scripting in VPX is somewhat unpleasant, to put it mildly. In VPE, scripting is split into two parts: game logic and physics.

 

For game logic, VPE provides multiple game logic engines (we call them GLEs), but you can also write your own in C#. This game logic is really what would be running on the CPU of your real pinball machine. It:

 

• Takes in switch changes
• Toggles lights and coils
• Drives displays and sound effects

 

That's really it. And because it's so simple and standardized, we provide graphical tools to set it up easily. Examples of GLEs that VPE provides are PinMAME (doc in progress) and MPF.

 

Physics scripting is more difficult. This is about simulating the various mechs and toys, like a spinning wheel on the playfield, or more complex stuff like JY's wrecking ball, or CV's ring master.

 

The idea here is to provide a few of those mechanisms as re-usable components, and work with table creators dealing with more exotic requirements whether to include them as well, split them into smaller re-usable components, or ship them as table-specific code.

 

Tooling

 

We've spent a lot of time on tooling. In fact, most of the work spent so far were efforts to make the creation process as good as possible.

 

First of all, we replicated most of the editor features of Visual Pinball. That means you have editors for materials, images, layers, collections, and sounds. Properties of all the playfield elements are editable in the inspector. This should enable creators to virtually replace Visual Pinball for (.vpx) editing work.

 

Secondly, since VPE has a standardized way how the game logic interacts with the playfield, we have written tools that facilitate linking playfield items to the game logic. So far we have:

 

• A Switch Manager
• A Coil Manager
• A Lamp Manager
• A Wire Manager

 

As mentioned above, these interfaces replace the game logic part that creators need to script today.

 

Mechanisms

 

There are around a dozen mechanisms coming from Visual Pinball that you can put on the playfield and configure through a UI (flippers, bumpers, gates, etc). However, these are very basic and most games use additional mechanisms which creators today implement via scripting.

 

For example, nearly all games use a trough. In VP, this is implemented in core.vbs, and I don't know how creators do it, but for me, a lot of trial and error was involved in order to getting one to function.

 

VPE provides a trough component out of the box. You drop it on the playfield, set the size and the type, link up the switches and coil(s) in the inspector, and that's it. No coding required.

 

The trough is the first of hopefully many more mechanisms that VPE will ship with. In terms of scripting, they fall under physics scripting.

 

Displays

 

All pinball games have either score reels, segment displays, DMDs, or some sort of high resolution LCD.

 

VPE currently supports segment displays and DMDs. That means you put a display into the scene, and VPE handles the rest. You can of course customize the look, but you don't need to script anything. More infos here. To give you an idea how easy it is to setup displays, check this lengthy video.

 

 

Note that the ROM selection is being worked on and will be much more comfortable, since we can query infos about all supported games from PinMAME directly.

 

Plugins

 

We've internally talked a lot about plugins and how we can keep VPE open to third parties without having to know about them. So here's how this is going to work:

 

Per definition, a plugin is optional software VPE loads during runtime. It might be required by a certain table, but it's not required to create a table.

 

Plugins need an interface, also called "API", so VPE knows how to talk to them. And there are different subjects to talk about. One plugin might be interested in looking at (or even manipulating) DMD data because it adds colors. Another plugin might needs to receive coil changes in order to trigger some hardware in the cabinet.

 

So we're going to have a bunch of different APIs where third parties can hook into VPE. The first of these APIs is called IGamelogicEngine, and you guessed it: Game logic engines are plugins in VPE.

 

Documentation

 

And lastly, as you've surely noticed by now, VPE has... documentation! The goal is really to have high quality, up-to-date documentation that is delightful to read.  So whenever we merge a feature into mainline, documentation is part of it. It's part of our source code, and anybody can easily suggest changes via GitHub directly.

 

What's next?

 

I'm currently working on the import and export process, make editor tooling more stable, and finally see what we can do about physics performance. Order may vary and I'll probably get interrupted by other things, but those are the main points. @jsm174 is currently working on getting PinMAME more easily set up . @Pandeli is working on the render pipeline.

 

Thanks!

 

Finally, this is not a one man show. While I'm somewhat the main developer/coordinator of the project, there are many others, so thank you @ravarcade for your shader assistance and many other things, @shaderbytes for sharing your Unity know-how, @hoopybox, @ecurtz, @VroOnsh and @Rowlan for all kind of editor- and runtime code, @jsm174 for his work on PinMAME and cross platforms, and of course @Pandeli for his rendering contributions and overall VFX expertise. Additionally, we wouldn't be near anywhere we are today without the collaboration of @toxie on both PinMAME and VPX side. Also, there are many table creators now giving feedback and insights about how they work, specially @bord and @rothbauerw and other VPW folks, so thanks a lot for that!

 

Lastly, there is one new contributor some of you might remember: @BilboX, creator of Unit3D Pinball, a Unity based pinball simulation coming from the Future Pinball ecosystem, has availability again, and started contributing to VPE. This is specially awesome because he started working on v2 of Unit3D Pinball (named UP2) several months ago, before he learned about VPE. Turns out we've had many very similar ideas, and unfortunately, some of UP2's new features were already completed in VPE by the time he noticed. But many others are not, and it's still my hope that these features will make it into VPE eventually. Bienvenue mec!

 

If you've made it this far, thanks for reading. I'm sure you're wondering how long until you can play a demo. Subscribe to this thread and you'll know!

 

Cheers,

 

    -freezy.

 

[TerryRed]

The future of digital pinball looks bright and sexy.

 

Amazing work from everyone involved.

 

I know my slow and painful progression of getting to know Blender (for what I do in FP-BAM today), and also getting to know how to create / use FBX models and more  will definitely be a benefit down the line with VPE.

 

If anything... I think adjusting to a modern real-time editor and new scripting language will be the biggest adjustment for most... but the end results will be so worth it.

 

 

Since I've been creating most of my stuff on FP-BAM, and that is done in "realtime" as a big part of the creation process, combined with some modern dynamic lighting / rendering... it makes it very hard to want to go back to static editors.... and much more difficult to want to go back to static rendering / lighting.

 

VPE will blow us away one day.

 

I can't even imagine what the VPX Blender / modeling gurus will be able to create. If anything they may need to get used to not baking in most of their lighting into textures now.

 

For DOF support... I could see that working well as a plug-in / COM wrapper so that it's done in a way that doesn't tie up Windows / COM as a requirement for VPE.

 

For SSF... that should definitely be native to VPE, and be almost seamless and require little to no work from the author.

 

 

 

For me.... if VPE can eventually have the following:

 

- FBX model and animation support

- total control over lighting, textures (and as much else as possible) via script

- something like ravarcade's BAM mini playfield tool on FP (reference what I've been doing with RetroFlair 2 and Silent Hill)

- some great C# scripting and table examples (as I only know vbs... I'm no coder)

- a possible replacement for PUP / PUPDMD for modern looking text and video displays (using native Unity functions)

 

...that's where I would be a very happy camper and start to dabble / create in VPE in a serious way. Yes, it will most likely be outrageous fantasy based pinball... but it would be damn amazing without any RAM limitations and using modern lighting and shaders.

 

 

 

Exciting times are coming.

[gtxjoe]

Thanks for the sharing these updates. It was a great read. Looking forward to seeing what we can achieve with VPE

[bord]

I hope this puts me out of work in the best way. Even in a worst case scenario making a better-than-the-best vpx game in vpe will take 1/4 of the time and headache when you remove all the manual texture rendering to get around 2d lighting, not to mention the nFozzy stuff being native!

 

Lots to learn, but baseline for quality is going to be raised immeasurably. We've had great tools for spreading the love of pinball this far. So glad there will be a whole next generation.

 

As always, let me know how my limited skills can be of service.

[LynnInDenver]

Looking forward to the future here. Having direct support for DMD/Alphanumeric displays for originals will be seriously game changing for authors, as will the support for MPF, my limited experience using a LISY-1 MPU in Solar Ride showed me it's quite capable of making a good portion of a game with no coding necessary.

 

So I need to decide, do I move into MPF coding in the future, or do I move into learning whatever else might be integrated? I'm working on a table right now with my husband, and it may ironically be my last one in VPX from the looks of it.

 

Advantages I can see is reduction in the hacks for things like ball shadows, looks like it brings the POV Rotation agnostic future that I've been kind of pushing for as I can (VPX is really the only reason to run a cabinet in landscape at all), stepping away from the COM system that's been showing the cracks as Microsoft has been working on tightening up security and heaven forbid you're trying to use it for real time operations now...

[dillman]

Wow...everytime I see table examples I'm blown away.  Seeing CFTBL, one of my all time favorite tables is very, very exciting.  This is going to be amazing, and I can't wait to see all that can be created..  🙂

 

[Gravy]

Wow... that is coming along nicely. The future is looking very bright.

[scottacus]

This is an awesome undertaking and this will be the future for this hobby!

 

As an EM author I'm very curious about the GLE's for this project.   Making SS tables with a ROM is a breeze but those of us who make EM's have to handle all aspects of game control from low level player management to higher level game logic.  I spent months learning how to use MPF for my homebrew project and it was a particularly unpleasant experience.  The documentation is good but the framework is extremely unforgiving in terms of syntax and formatting, the learning curve is steep and it takes some time to get help at the forum because the few people who write mpf code have lives to live outside of mpf.  If you are a native python programmer then maybe you'll probably have an easier time than I did but it took months to get a properly working Cuphead table.  (see https://pinside.com/pinball/forum/topic/cuphead-home-brew-pinball for all of the gory details)

 

I realize that MPF will handle a lot of the low level game functionality but having to get multiple modes working with each other, casting player variables for use across modes and getting logic to work out will be a challenge.  One great thing about VPX is that the code in VB is fairly easy to write and very forgiving in terms of format.  I suppose that once you get a working base table in MPF it will be easier to transfer that into future tables but I would prepare for a rough go the first time around.

 

One aspect that would be great to have integrated into your base engine for EM makers is some sort of score motor functionality.  In the EM world many aspects of play are tied into the score motor and once a score motor is running, it cannot accept additional inputs.  That is one of the odd beauties of these machines.  Another feature that would be great to have integrated would be accurate reel reset routines.  These routines would be tied to a score motor and pulse each reel once per step, stopping the reel when it reaches zero.

 

Lastly, one short fall in VP is the sound engine.  It uses Microsoft virtual room to achieve some degree of sound positioning and because of this sounds cannot be panned completely left, right, front or rear.  There is always bleed across the pan and this new VPE is a chance to fix this right out of the gate.

 

Thanks again for all of the hours you guys are putting into this and if you was more insights into the EM world feel free to PM me.

[TerryRed]

12 minutes ago, scottacus said:

This is an awesome undertaking and this will be the future for this hobby!

 

As an EM author I'm very curious about the GLE's for this project.   Making SS tables with a ROM is a breeze but those of us who make EM's have to handle all aspects of game control from low level player management to higher level game logic.  I spent months learning how to use MPF for my homebrew project and it was a particularly unpleasant experience.  The documentation is good but the framework is extremely unforgiving in terms of syntax and formatting, the learning curve is steep and it takes some time to get help at the forum because the few people who write mpf code have lives to live outside of mpf.  If you are a native python programmer then maybe you'll probably have an easier time than I did but it took months to get a properly working Cuphead table.  (see https://pinside.com/pinball/forum/topic/cuphead-home-brew-pinball for all of the gory details)

 

I realize that MPF will handle a lot of the low level game functionality but having to get multiple modes working with each other, casting player variables for use across modes and getting logic to work out will be a challenge.  One great thing about VPX is that the code in VB is fairly easy to write and very forgiving in terms of format.  I suppose that once you get a working base table in MPF it will be easier to transfer that into future tables but I would prepare for a rough go the first time around.

 

One aspect that would be great to have integrated into your base engine for EM makers is some sort of score motor functionality.  In the EM world many aspects of play are tied into the score motor and once a score motor is running, it cannot accept additional inputs.  That is one of the odd beauties of these machines.  Another feature that would be great to have integrated would be accurate reel reset routines.  These routines would be tied to a score motor and pulse each reel once per step, stopping the reel when it reaches zero.

 

Lastly, one short fall in VP is the sound engine.  It uses Microsoft virtual room to achieve some degree of sound positioning and because of this sounds cannot be panned completely left, right, front or rear.  There is always bleed across the pan and this new VPE is a chance to fix this right out of the gate.

 

Thanks again for all of the hours you guys are putting into this and if you was more insights into the EM world feel free to PM me.

 

 

 

Yah, I'm in the same mindset as you in that... when I hear about a framework for most of the code and logic... I have a hard time "letting go" of the idea of doing everything myself manually in code and to have total control.

 

I've been coding two tables completely since last Nov (RetroFlair 2 and now Silent Hill)... and these aren't recreations. I can't imagine making these fit into a framework of some sort (they are very non standard pinball tables). Like you said though...maybe with a good example table and easy to follow docs and notes in the script it may be easier.

[Pandeli]

@scottacusUnity has a full 3d 7.1 audio setup based on a listener position in 3d space as well as integrated overrides and a good DSP stack,  Properly managed it should be possible to have correct audio for SSF and HRTF "out of the box" .  I won't speak for other members of the team but for me this is definitely on the radar.

Edited June 21, 2021 by Pandeli

[hitman12]

@Freezy

Will a table imported directly from VPX be able to run and play in VPE?

[freezy]

@scottacus I would love to talk more. I'm mainly interested in what the pain points are when scripting EMs in VPX, as well as the good stuff. Then we can look into whether VPE could simplify the complicated stuff (i.e. provide simple APIs for it), or even replace it with something more visual.

 

If you're on Discord, gimme a PM, otherwise we can talk here as well. There is also a bunch of other people I'd like to include in this discussion.

 

@hitman12 No, of course not. We have a patching system that applies a few things on best-guess basis, mainly to make development quicker, but that won't be part of the runtime. VPE is not intended to replace the VPX player.

[Thalamus]

Good choice to "start the thread over", made me read it all the way though and you've come further than what I had hoped for to be honest. In the beginning I was a bit hesitant, wondering if this would some day come through or not. I guess it is still early on, but, with progress you've guys made I'm really believing that VPE will be a thing and a huge one at that. Fantastic work everyone - I'm in awe to you devs. ❤️

[naeromagus]

I'm very excited and pleased to be able to experience the fruits of your labor. Thank you all for bringing this closer to a reality. You have no idea the joy that all of you smart and super talented individuals bring to me on a daily basis. THANK YOU:)

[Felsir]

16 hours ago, freezy said:

 

@hitman12  VPE is not intended to replace the VPX player.

 

Do I understand correctly that VPE will be the software to create tables, but there will be a separate "player" that loads and runs tables at runtime? I assume at some point VPX player will be abandoned to take advantage of VPE create tables with newer materials and plugins etc.?

 

Anyway, awesome work! I've been following along with the updates. Many thanks to all involved to move the community forward!

[freezy]

1 hour ago, Felsir said:

 

Do I understand correctly that VPE will be the software to create tables, but there will be a separate "player" that loads and runs tables at runtime? I assume at some point VPX player will be abandoned to take advantage of VPE create tables with newer materials and plugins etc.?

 

VPE is the overall term of the project. It consists of a runtime, editor extensions, a Unity authoring project (soon), plugins, and at some point a player (which uses the runtime, and will ship with some plugins pre-installed). It's probably going to be called the VPE Player. And yes, this would be the "game" that you run that can load tables and play them.

 

I can't speak for VPX, but I'm sure it isn't going away soon. In fact, I'm working closely with toxie, and he's looking into porting VPE's new features back into VPX in order to keep backwards compatibility.

[Felsir]

2 hours ago, freezy said:

I can't speak for VPX, but I'm sure it isn't going away soon. In fact, I'm working closely with toxie, and he's looking into porting VPE's new features back into VPX in order to keep backwards compatibility.

 

Sorry, I worded it a bit harshly; I meant that there will likely be VPE specific tables to appear to take advantage of rendering and other (gameplay)effects that could be possible because of the underlying Unity framework.

 

I did not mean to diminish the work of Toxie and other VPX developers and the future of VPX itself. It is a great project that I enjoy on a nearly daily basis. 

[freezy]

No worries. Yes, without VPE specific tables appearing, the whole exercise would be kind of useless.

 

However I don't worry too much about creators not adapting VPE, since we're working together with them on many things.

[leojreimroc]

I'm beyond words about how good this looks.  This is going to look incredible in VR.

[LynnInDenver]

BTW, what's the earliest Windows version that will be supported? I'm about to prepare the next upgrade to my cabinet, likely SSF, and I need to know if I should get it up to Windows 10 instead of Windows 7 before I start that process.

[TerryRed]

15 hours ago, LynnInDenver said:

BTW, what's the earliest Windows version that will be supported? I'm about to prepare the next upgrade to my cabinet, likely SSF, and I need to know if I should get it up to Windows 10 instead of Windows 7 before I start that process.

 

Win 7 should be considered no longer an option for a newer APP the way I see it. No more support from MS and none from nvidia for new drivers.

 

Win 11 is around the corner...so that should tell you all you need to know.

[LynnInDenver]

25 minutes ago, TerryRed said:

 

Win 7 should be considered no longer and option for a newer APP the way I see it. No more support from MS and none from nvidia for new drivers.

 

Win 11 is around the corner...so that should tell you all you need to know.

 

Yeah, I'll admit I've already been toying with the idea of getting Radiant Silverball up to Windows 10, if only so that I don't potentially get left behind... there's recognition that Steam will eventually drop Win 7 support ("oh, you want to keep playing the games you bought, you're going to want to upgrade soon") and at least keep me from getting more pinball that way.

[LynnInDenver]

OK, went ahead and plunged into doing that upgrade. I'll be spending the next two weeks checking to make sure there's no issues with the existing software. This should make sure I'm ready for VPE.

[cristianosahe]

Ótima leitura incrível a próxima geração 

 

[hitman12]

28 minutes ago, cristianosahe said:

Ótima leitura incrível a próxima geração 

 

Please write in english or use translator.