As a long time software engineer and architect, I was more confident about this week’s content than some of the other areas we will be studying on this module. Nevertheless I was well aware there would be a steep learning curve as I had absolutely no idea how to make a pinball game. My game-plan for this week’s content was:
- Choose which game engine to use
- De-risk the big ‘unknown’ such as how to make a ball follow the curved path of an orbit or ramp, how to launch the ball and create working flippers.
- Create a working grey-box prototype
As you can imagine there was a lot of work here that would underpin the feasibility of the game which is part of the reason this post is 3 weeks late.
Choice of Game Engine
The primary contenders for the game engine were obviously Unity and Unreal Engine 4. There wan another option as well: Visual Pinball
Whilst tempting to use as it would make the entire module far simpler, I elected not to use Visual Pinball. I felt it wasn’t in the spirit of the module to base my game on this particular framework making the development process little more than a purely cosmetic exercise with fewer opportunities to acquire usable game development skills: the problem domain would be reduced to little more than a CAD exercise followed by painting in Photoshop. The other big reason was Visual Pinball is only supported for Windows, not MacOS. As I tend to work on both platforms I needed a solution that would be less restrictive.
That just left Unity and Unreal Engine 4. This choice was much easier to make.
I chose to base my game on Unreal Engine 4 (UE4) as almost everything I’ve developed thus far has been on Unity. I wanted to also gain experience in UE4 to allow me to make a more informed choice of engine before embarking on the major project element of the course. I also felt having exposure to both Unity and UE4, with both featuring in my portfolio, would serve me better in the future.
The decision was made: Unreal Engine 4, specifically version 4.27.2
De-risking the unknowns…
One of the biggest unknowns for me was how to make a pinball ball follow a curved path such as a playfield orbit or a ramp. Was this something the game engine’s physics engine would support or would I need to program this myself??? If the latter, that would prove too big a task for a 12-week project and a rethink would be needed a.s.a.p.
I had a notion the engine would provide this support. Looking back at FPS game, SWARM!, I started to develop last year, the gun’s projectiles would clearly bounce when they hit a solid object so there was clearly support for some physics behaviour in the engine. I was still uncertain about following a curved path such as running around a wall for example. To this end I created a pinball playfield in Blender with rounded corners to verify this would indeed work (Figure 2)
Bringing this into the engine as an FBX file allowed early testing to verify the physics would do what I needed for the game (Figure 3).
Fig 3. THORN, 2022 Very early prototype to verify ball would follow a curved wall
This exercise highlighted an issue I had not previously considered: scaling. When creating the playfield model, I researched sizes of existing pinball machines to use and chose 46″ x 20.5″. This meant the ball had to also be the correct size (1 1/16″ or approx. 27mm) with a mass 81.5g.
One of the major, unforeseen issues I had was converting between Blender units and UE4 units. Blender, typically uses a scale of 1 unit == 1 metre whereas UE4 uses a scale of 1 unit == 1cm. I found with my early model attempts the export process was not as easy as I had anticipated with my FBX intermediate files often coming out either far too big or too small. Once identified as the problem it was relatively easy to resolve and in the end I kept the scale at 1 Blender unit == 1 metre and created an FBX export setting to ensure everything came out the same. The downside was that the models in UE4 are on the small size but, when compared to the UE4 mannequin I’m happy the proportions are correct (Figure 4)
Having proved to myself that I could make this work, I felt much more confident moving on to the next item on this week’s agenda…
Creating a Grey Box Prototype
Using primitives significantly sped up the process to product this prototype. One of the main issues I had 12 months ago was getting bogged down too early with concept art and modelling rather than producing a working grey box version. The concept art and models are important but at this stage of the process I felt it better to provide concepts through rapid prototyping and add the polish further downstream.
This was the first time I’d ever looked at using the blueprint event graph to capture behaviour. It is without doubt far faster than writing C++ code but owing to my lack of knowledge here I found anything other than very simple things much easier to produce in source code. Figure 5 shows an early prototype for flipper control that simply applies a rotation when the appropriate key is pressed and released. Note the upper block that allows an Actor to receive keyboard/controller input.
This Blueprint was later reworked in C++ to give a more realistic flipper motion through interpolation rather than a step change. I could have implemented this within the blueprint but found it far easier in C++.
The biggest issue I had was with the ball launcher. My C++ class was not receiving collision events which held me up for a while until I realised I’d neglected to change it’s base class from the UE4 Actor class to my own, doh!
Conclusion
Producing a grey box prototype took much longer than I anticipated. I hadn’t taken into account how rusty I was with UE4 nor the issues I had with creating scale models for UE4 from within Blender. Again, I put this down to a lack of experience rather than anything else, both of which will improve over time.
With a playable grey box prototype I feel more confident moving into the next elements of the module. My focus will now need to turn towards the overall game design, artwork, modelling and the myriad of other skills and tasks necessary to make a pinball game.
List of Figures
Figure 1. THORN, 2022 Grey box prototype of pinball game
Figure 2. THORN, 2022 Blender model of playfield prototype
Figure 3. THORN, 2022 Very early prototype to verify ball would follow a curved wall
Figure 4. THORN, 2022 Checking scale against UE4 mannequin
Figure 5. THORN, 2022 Early blueprint prototype for flipper control
References
Photo by Faye Cornish on Unsplash
