Virtex Edge: Choosing Which Foot to Put Forward.

I’ve been working on Metric Racer for a while now, but the decision to have online multiplayer as well as porting it too Linux means that it’s going to take a lot longer than I initially hopped. So as a step forward I’ve reshuffled the deck so to speak.

I’ve decided to postpone Metric Racer by a year to ensure it gets the polish it deserves and decided to go forward with a game that’s essentially half done already, Euclidean. Euclidean originally started out as a game called Pixel on the now closed (?closing?) Xbox Indie Game Channel that I released in September of 2012.

The lead up to it being released ended up falling in line with me starting a new job in a new city at the time and it showed in the final product of Pixel. It had good ideas, but it being my first program I released, it had a number of bugs and performance issues, it was a textbook lesson in poor execution of a good idea. Needless to say, It’s success was underwhelming. I shelved the project for a little while until expanding on the original idea and decided to give it another shot feeling like there was a lot to expand upon in the game. I’d already expanded on the original levels back in late 2013 with the precursor to Vertices, but it was never more than a hobby I was working on. Now that Virtex Edge is in full swing, I’ve decided it’s best to lead with this one.

Screenshot from Euclidean after I spruced up Pixel.

Sandboxing It All UpThat said though, unlike Virtex’s other projects, at this time, Euclidean will only be available on PC due to the fact that MonoGame doesn’t support Instance Meshes currently. (I think I read somewhere it’s working under DirectX, but not OpenGL…so no Linux Support for the time being).

With Pixel (and even with the original Euclidean code), the original method I had in making the levels was to hard code each level and set up bounds for the level and then write a series of nested for loops of code which created the levels. This made loading the levels easier, but creating them was a lot of visualization coupled with trial and error.

You can see an example of the code below:

As you can see above, for some of the larger levels, the code got pretty complicated. Originally I wanted Pixel to have a level editor in it but it just turned out to be too difficult to implement on the Xbox at the time. This time around, since I’ve coded the Vertices Engine to have a Sandbox element to it from the start, it makes not only creating levels easier, but porting them over easier as well. In a weekend I was able to get the original Euclidean Code ported over to Vertices and to get a handful of levels imported and playable in the sandbox environment.


Testing Random Cubes in the Sandbox.

With the sandbox now working, it’s a hell of a lot easier to add in items and porting over the original levels. Instead of wrestling with nested foor loops, the process is now:

  • Copy the original for loops into Euclidean 2.0 base level code and running the level in sandbox mode.
  • After a quick check to see if everything loaded okay, Save the file as a sandbox file (A Serialized Class of Entity Data which boils down to essentially an XML file containing all required data to rebuild the level) so that it can be used later on.
  • Clear out the original for loops out of the code and move on to the next level.

This process had allowed me to port the first 4 levels and expand on them with ease within an afternoon.

euclidean import

The result after importing a level. It’s editable straight away in the new sandbox.

I’ll be posting a video of the sandbox very soon.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s