R.C. Extreme


R.C. Extreme is a simple racing game created in Unreal Engine.  A few years ago, I created a racing game that was never a completed game, so I decided to use this game as an opportunity to finally make a fully functional racing game.  I also wanted to work with Unreal Engine again, since it’s been a while since I have made a game in the Unreal Engine editor.

You can hear about the things that I learned with Unreal Engine on the July 2018 Knoxville Game Design show.

The game consists of four cars competing to finish in first place.  The player controls the red car, and must race around the loop for three laps.  There is a ramp half way through the track.  Be careful to not run off the track, as there is no way to recover.

The game takes advantage of the Unreal physics engine, so make the ramp jump and collisions with other cars appear realistic.  The game logic was created using the Blueprints visual scripting tool.  The cars models were created using Blender.  The game supports both keyboard and gamepad controls.

In a future release of the game, I would like to add additional tracks and a track editor.

R.C. Extreme - Title R.C. Extreme - starting line R.C. Extreme - jumping the ramp R.C. Extreme - finish line R.C. Extreme - making a turn

 

Released

Posted on

Raspberry Pi Arcade Update

The Emory Place Block Party is this Saturday (August 20, 2016), and I will be there at the Technology Cooperative showing games that I have created.  Other members of Knoxvile Game Design will be there as well showing off their games.  Stop by and say “hello”, and pick up a free sticker and refrigerator magnet as well.  The sticker is great for laptops to show your support of Levi D. Smith Games!

I will be showing off the new case that I created for my Raspberry Pi arcade system.  Two new blue buttons have been added, which I have set to control the 1 and 5 keys.  In Mame, 1 is used for the 1P button and 5 is used for Insert Coin activation, so now Mame games can be played completely without using the keyboard.  The button configurations are set in the retrogame.c file, which must be recompiled each time it is reconfigured.  I have a secondary button configuration for controlling Pygame and Scratch games.  The buttons are mapped to the 1 through 4 keys.

Getting the additional buttons working was a little tricky, because there is a limited number of ground pins on the Raspberry Pi.  Each arcade button must be connected to an active pin (which is the button identifier) and a ground pin.  I was able to strip a write that I used for ground, and connected it to two of the connections to the new blue buttons, and then wrapped them together with electrical tape.

I am currently in the process of painting the case, so be sure to come to see the new paint job.  This new case should be much more sturdier than my old lunch meat case.  The only mistake I made was that I made the joystick hole bigger than it needed to be.  I should have used the 1″ (inch) hole saw bit that I used for the buttons, since the joystick hole only needs to be as big as the shaft, since the ball on the top of the joystick can be detached.  I did put another 1″ hole in the back of the case, which will be used for running the USB power cable and HDMI cable.  I am also planning to mount the Raspberry Pi to the bottom of the case, but all of the screws that I currently have are not small enough for the mounting holes on the Raspberry Pi board.  I also need to find a way to cover the edges of the holes which can be sharp.  Currently, I have it covered with white duct tape.

After I got everything working, I took everything apart again so that I could paint the case.  I used a can of Rust-Olem white paint and primer.  Unfortunately, it started sprinkling rain a few minutes after I started painting, which I believe led to the small air bubbles.  It’s actually sort of a neat pattern.  I applied a second coat of paint about an hour later, then waited 24 hours for the paint to dry.  The hardest part was removing the buttons from the lid, which were much easier to put in than take out.

Honey Bear ScratchAfter I got everything back in the case and wired again, I tested the software again.  I wrote a simple Scratch game about a bear catching honey that falls from the sky.  I uploaded the game to the Raspberry Pi using FTP from my desktop PC.  I quickly realized that the Raspberry Pi is running Scratch 1.4, so Scratch 2 games would not run on it.  After I installed Scratch 1.4 on my desktop, I was able to upload and run the game on the Raspberry Pi.  I also discovered through the Scratch errors, that it is built on SmallTalk Squeak, which is a development environment that I used for one of my first computer science classes at Georgia Tech.  I would never forget that font and window layout!

I also updated the simple “arcade.sh” bash script that I wrote, which loads the game when the Raspberry Pi is booted.  I made a menu so that the user can press the white button to run a Mame game or the yellow button to run the Honey Bear Scratch game.  Pressing the left blue key confirms the player’s selection.  I had to update the Mame key mappings, so I could use just one instance of the retrogame program for both Mame and Scratch.  The four buttons are mapped to 1, 2, Enter, and Tab.  Enter is required to run “green flag” that starts the scratch program.  I used 1 and 2 for the yellow and white buttons, since keys like Control and Alt are not available in Scratch.

Posted on

Rank Updates

Rank Modifications

Modified the way that ranks are calculated at the end of a level.  Before, I had S, A, and B values defined for each of the three categories (pieces, luminosity, time) for each level.  I’ve realized that I will not have enough time to come up with all of those values for even the 50 stages that I currently have.  Therefore, I’m just going to define values for the S ranks.  Then, I will derive the A, B, and C values for pieces by adding 1, 2, and 3 to the S rank.  The same goes for the luminosity value, but decreasing the value by 1, 2, and 3.  For time, I will set a base S rank time, and then calculate the A, B, C ranks by adding 2 seconds for each lower rank level.

Fixed an issue with records being wiped when New Game is selected after the game is executed again.  This is because the constructor of the PlayerRecords class was initializing all of the array values to -1.  Now the save data is loaded once when the game is started, after the rank arrays are initialized in the constructor.

The rank values now gradually appear on the game win screen.  Currently, the ding sound effect is played when each value appears.  The game is already heavy on the voice work, so I thought the letter voice work was excessive.  I may use Audacity later to modify the ding sound, so it is different for each rank or new best ranks.

Added boolean variables and methods to track if the new ranks obtained for the level are better than the previous ranks obtained for the level.  This wasn’t pretty, because the GameWinScreen doesn’t have references to the GameLevelScreen or PlayerRecords classes, so it has to keep local variables to track if each rank is the best.  The GameWinScreen then uses those boolean variables to display if the rank is a new best if appropriate.

Level Number Display

Created a static method in the Level Definition class, which takes an integer level number and converts that number into a string level name.  It divides the level number by 10 and adds 1 to get the first number, and then takes the modulo of the level number by 10 plus 1 to get the second number.  For instance, level 25 becomes “3 – 6”.  Level 10 becomes “2 – 1”.  This is the value that will be displayed to the player on the various game screens.