Search the Community

Hi folks! 2023 was a bit of a slow year for VPE. I'll go into more details in a minute, but in general, side-project fatigue happens, and in order not to burn out, taking things slowly for a while is necessary. I've also changed jobs, so naturally, I'm a little bit more invested in my professional life. That's not to say I'm distancing myself from the project; on the contrary. There's lots of cool stuff to be done, and working with a supporting community motivates a lot. It's a genuine pleasure to share ideas and progress with you guys, discuss potential features and limitations of the engine, or post random stuff I've been working on, like this spinner. vpe-spinner-anim.mp4 So, let's have a look at 2023. DOTS v1.0 came out at the end of 2022, and quite a few things changed. A quick primer about DOTS: It's Unity's ECS implementation, meaning instead of the classic object-oriented approach, data is packed in a way that is much more accessible by the CPU, avoiding cache misses. Together with Unity's Jobs system and Burst, it offers an insane amount of performance if you're dealing with many objects (tens of thousands). VPE's physics port from VPX was based on DOTS, and with v1.0 coming out, much refactoring was ahead, since v1.0 broke most of the APIs of the previous beta versions. I started this in January, but there were a few things that had changed significantly: DOTS worlds must be contained in a sub-scene, i.e., a different file. This sounded great at first (it would be easier to integrate sub-scenes / tables into existing rooms/surroundings), but it didn't play well because we didn't use the DOTS renderer: Nothing was rendered on screen during runtime. Conversion is now taking place at build time through bakers. This is a problem because we want to load tables during runtime and need another way to bake. It's probably possible to work around those issues, but I had a hunch since I started with DOTS: Since every system (the code that simulates the physics world) is launched from the main thread, a lot of scheduling is going on. Every piece of logic (there were around forty systems) needs to be scheduled, even if not executed, on a different thread, for every tick of the physics simulation. This overhead is okay when dealing with thousands of objects that can be distributed over multiple cores, but here, we can't really do that, and even if we could, we would probably parallelize the ball simulation, and there aren't as many balls. Thus, removing DOTS might result in actually better performance. So, I started rewriting the physics without DOTS. To at least keep the current performance, all data should be tightly aligned in memory, and there should be no managed allocations, which would make the garbage collector kick in (and introduce frame drops). I somewhat finished refactoring all of this at the end of February, but then DMDext became more urgent, and I switched projects. It still didn't work, though. I only refactored it for two collider types, and one of them didn't work at all. I did some fixes in March, but DMDext consumed most of my free time until the end of August. In September, I slowly started to pick it up again, but there were still a lot of bugs, and physics in general are a nightmare to debug (imagine debugging through data at 1000 fps), so progress was tough. Then came the Unity debacle. Basically, Unity was demanding an "install fee" retroactively from the studios using the engine. Although this was a tremendously stupid idea (how would you track "installations"?), breaking users' trust by changing the rules retroactively was the main reason the whole game industry was in an uproar. It ended with Unity's CEO stepping down and most of the new terms being rolled back, but like many other Unity developers, it made me spend over a week looking at Godot and rethinking my life choices. I won't get into too much detail, but the main reason I finally decided to continue VPE in Unity was simple: I really like working with it, and it's still the best tool for the job, even compared to UE5. But back to DOTS. At the beginning of October, I finally got it running again with just Burst and Jobs. Here's a scene with 60k colliders: vpe-collisions.mp4 Using DOTS, this takes about 12ms per frame to simulate. After the refactoring, we got this: That's 0.2ms per frame for the entire physics simulation! That's a 60x boost of performance, which is crazy. This immediately raises the question: Why don't we make the colliders dynamic? You move, scale, or rotate an object during gameplay, and the physics simulation updates accordingly. That's something VPX can't do. So, let me introduce kinematic objects. You can now tick a checkbox, and objects marked as kinematic will do that. One catch, though: Kinematic objects don't have a velocity. So, if your object moves and collides with a ball during movement, its velocity isn't applied. It's like the object teleports, frame by frame, to its new position. I'll address this soon, but for now, it still offers a massive benefit for features like diverters, whose movement is less important than having them on multiple positions without manually creating numerous objects and toggling them, as we have to do in VPX. For example, here I'm transforming a ramp, live during gameplay, and the physics update in real-time. vpe-kinematic-ramps.mp4 The present While discussing these changes on Discord, a strongly related topic emerged: Freedom of how objects can be transformed. See, modern game engines build their 3D scenes through a hierarchy. That means you can parent objects; if you transform the parent, its children are transformed along. This is essential for many use cases. Imagine a player character holding an object. You don't want to have to transform the object and the character separately when your character moves in your scene. You parent the object to the character and let the engine do the rest. Unity is also built like this, but because our physics engine doesn't support full transformations, we had to add many hacks to the editor to not let the user transform all objects freely. For example, VPX's physics doesn't support flippers rotating on any axis other than the Z axis. Or, walls cannot be rotated at all. Not being able to transform freely also restricted parenting. While we can somewhat control how an object can be transformed, applying those constraints to its parent is difficult, especially if there are siblings with different constraints. Long story short, having complete freedom regarding transformation would solve many problems. So, I'm currently working on adding this to the physics engine. Here's an example of a flipper rotated to match a different playfield slope, something currently not possible in VPX: vpe-transformed-flipper.mp4 The future As mentioned above, kinematic colliders don't have velocities, so they can only be used for a few use cases. The next logical step is adding support for this to the physics engine and a set of components that can be linked to ROM outputs. We'll probably call those dynamic colliders. After that, the goal is to get the first SS game fully working. T2 is a good candidate, but we've since started a few other projects, so it might be a different table. In general, two major features still need to be implemented: A player app to load and play tables and an export format that can be loaded by the player app and allows importing a table back into the editor. Let me know if anyone with a C# or Unity background feels like tackling this! That's it for now I hope that every one of you is having a peaceful holiday. Personally, I'm excited about what's to come. If you're a developer and you are too, and you've got some time to help, let me know! Happy New Year, everybody! -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: Tooling. By extending the Unity editor, creators can work in a full 3D environment while creating tables. Scripting. A lot of code that authors paste into their tables could be included in the engine, making the need of custom scripts minimal. 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.

Hey all, here's a look at my current pintable I've been working on the past few months, Crazy Cats Demo Derby. Crazy Cats is my second table for VPX. It's intended as an 80s Williams System-9 style game with LED score displays as well as a running jackpot on the backglass. This table is dedicated to longtime friends who have effectively become family to me who are or have been part a demolition derby team out of the town of Monroe, WI called the Crazy Cats. These guys have been running derbies for over 30 years spanning two generations. The theme is running in a demolition derby, something I personally haven't seen much of in either real or virtual pinball. The idea in Crazy Cats is to acquire, build, and run a derby car to run in the next derby. Completing these heavily involves shooting the blue Garage targets on the mid-right portion of the table to open up the Garage itself. Then you put the ball into the Garage to progress. These are indicated by the Stage lights on the playfield. Progression through Heats are indicated by the Heat lights on the playfield. Stage 1: Acquire your derby car by opening up and shooting the Garage for 50,000 points and adding 50,000 to the Heat Jackpot. Stage 2: Build and set up your derby car by shooting the garage and starting a 2-ball multiball. Shoot lit shots for jackpots. Complete a certain number of ramp shots and spinners for additional awards. Stage 3: Run your next derby heat by locking three balls to start a 3-ball multiball where you can score the running Heat Jackpot on the jackpot display. Complete two Heat Multiballs and go through the Stages to set up the table for the 4-ball Feature Heat. Score 2 Heat Jackpots during the Feature Heat to light the Trophy that must be collected before losing the ball. The Trophy currently scores 1,000,000 points plus the total of the jackpots scored during the Feature Heat, maximum 9,000,000 points. There are also two other multiballs to play (a 2-ball called Salvage Multiball and a 3-ball called Boogie Multiball) that have score objectives and can help build the Heat Jackpot.. Hopefully I am able to convert this basic demo-derby idea into a fun-to-play pinball. Pretty much all the code and functions are done at this point. I still have testing and debugging/tweaking/adjusting still to do. I'm also still thinking of things to possibly add. Currently I'm looking at releasing sometime late spring or early summer. Take Care

Hello everyone! For the longest time, I have been wanting to work on a massive original table idea I've been developing (on paper) for several years now. Since I just graduated college, I have more free time to make this table a reality. But I cannot bring this table to fruition without the awesome help / contributions of the VPU community! Currently, the table is in very early stages of development; I do not even have a file that you can download and play (yet). But I have a fully complete draft of the game rules. And attached is a table layout idea (thanks to @DonkeyKlonk for a majority of it). I did move the center ramp to between the horseshoe, added a triangular captive ball in its place with 3 standup targets inside, a 5-standup bank outside the right part of the captive ball (can be hit from the shooting lane), and replaced the 3-standup bank in the picture to 3-bank drop targets. The full draft game rules can be found at https://wallden.pdstig.me/game_rules/pg/start . Please let me know your thoughts / suggestions in this thread. I chose to house the rules on a separate custom website because it allows me more fine-grained control over formatting, and the rules are too long for VPX (would hit the character limit in table info... it's a LOT). I also might do a couple other things with the site in connection with the table. Do note I do not plan to offer the table for download on that site though (except the alpha versions because I don't want to clog up VPU and VPForums with WIP files); it will link to VPUniverse and VPForums for download. --- CURRENT VERSION: 0.0.1-alpha (attached) This table is NOT OPERATIONAL! This is so people can download / test out the table layout, shots / flow, etc. and leave feedback / suggestions on improving. Please leave feedback in this thread. --- What I need / contributions wanted This table will not be possible without contributors as my skill set is not vast enough to cover all areas necessary to bring this table to life. I could most use artists / graphic designers for the table art and possibly a PinUp display, someone experienced in making well-polished and beautiful table layouts to polish what I have, several voice actors (men, women, and a couple who can do children) for call-outs and dialog, testers, and overall anyone who wants to see this table come to life and has something to give. Someone to make original music and/or sound effects for the table would also be amazing, but not critical as I can use Creative Commons media. All contributors however big or small the contribution will be listed along with their contributions in the table info, on the website above, and everywhere the table is posted for download. If compensation is necessary for you to be able to contribute, I can offer a small compensation (especially artwork / graphics). Please ask me if that is the case. However, as VP is a hobbyist community filled with people who do what they do for the love of pinball, I prefer volunteer contributions. Please reply to the thread if you are interested in contributing to the table and what you would like to contribute. Thank you! --- What I plan At some point in the near future, I will release the first non-playable 0.1.0-alpha so others interested in contributing can begin downloading it and toying around. I will also make a detailed roadmap of all the things needed for the table so contributors know exactly what I'm wanting to work on (but contributors can, and should, let me know of ideas / suggestions if something should be different). Alpha versions will be released as the table is developed until it reaches completion. Then, it will become beta for testing before finally becoming a full 1.0 release. I will be working on the table too, mainly on the scripting side of things and game play logic as that is my strong suit. So I'm not just asking for others to make a table I want to be made. --- Again, thank you for taking the time to read, and for those interested in helping me make this happen, you have my utmost gratitude! Saving Wallden.zip