top of page

void rally

The Games Design & Production course at Abertay has a 'professional project' in the 2nd semester of 3rd year. Each student, along with a group of others, develops a medium-sized project over the duration of the semester in communication with a client. Which in our case, was NearLight.

​

Our team, 'Saint Street Studios', were tasked by NearLight to make an 'Atari style game in VR'. And Void Rally is what we created.

​

We were:

  1. Chris - Programmer

  2. Liam - 3D modeler

  3. Finlay - 3D modeler

  4. Matthew - Concept artist

  5. Sam - Programmer

  6. Rotik - Producer

  7. Me - Creative lead

Project overview

We, as a team, came in twice per week, 9am-5pm on Tuesdays and Wednesdays.

 

Meetings with Nearlight were conducted once every 2 weeks. They checked up on our progress and gave us pointers and suggestions for development going forward.

Development went ahead pretty smoothly. The team had an open communication style, and there was an atmosphere of positivity and perserverance even at lower moments in the development process.

​

We initially deliberated between making a game based on Asteroids or based on 'Tapper', as was the brief. But we decided on Asteroids.

 

Early development was characterised by getting barebones functionality working. As well as doing things to get the team on the same page with the game's vision.

​

A specific, fun, instance of this was was doing "cardboard prototyping" of the interior of the ship (which can be seen to the side).

 

This was during week 2. At this stage of development, we didn't have access to VR headsets yet due to problems with the Uni's IT department. But I was anxious to make our development seem more corporeal. So I grabbed some cardboard boxes from the interior of the Uni and assembled them into an approximation of a cockpit. Doing so let us quickly figure out the ergonomics we would pursue for the game's controls.

​

Development continued and we got more support from the IT services. At this point I generally busied myself with programming tasks.

whiteboard1.png
2.png
4.png

I found myself most useful at this stage making "framework" code. To this end I made:

1. A global references system

Default references.png

2. A Game Events system

Game Events Code.png
Game Events.png
Game Events Listener.png

3. A generic trigger

system

I generally made this code with a mind for re-use, genericity, and editor-facingness.

IE, I made sure that it could be used in many situations, that were controllable through the editor rather than being manually inputed via code. Despite there being not much here I deem it pretty powerful.

Trigger Code.png

As well as this. I generally found myself to be the lead designer in terms of gameplay and aesthetics. I made sure to point out design flaws and points of consideration for people.

Because of my background in Level Design. I knew that we'd need to give some constraints as to where the player was able to go. The void of space lets you travel in all directions, but with our game shaping up to be about piloting a ship, that is only fun if there are obstacles and turns to orient yourself around. As a consequence, we created the 'Star Gates', which we lifted in design from Cowboy Bebop's 'Astral Gates'.

Star Gate.png
Cowboy Bebop Stargates.png

Early iteration of level ↓

Level .png

At this stage of development we had roughly 2 week left, and I figured that I shouldn't look to change up the design of the game that much.

​

At this point I focused on the level, addressing concerns about player disorientation through having a point players could orient themselves off of via the skybox. As well as adding cheap, non-volumetric fog to the level to help with visibility and readability.

bottom of page