Ultimate Arena | Event Circles

Since the game was released events have affected every character on the map, regardless of position. With Ultimate Arena 2.0 we introduce a massive change in the way this system works. I’d like to introduce you to Event Circles.

Screenshot 2016-08-02 21.30.44

Event Circles allow players to more carefully plan out attacks, selecting only a specific area of the arena to impact.

Screenshot 2016-08-02 21.31.47

The size of Event Circles is easily changeable, so you can hold grudges against specific fighters if you’d like.

Screenshot 2016-08-02 21.32.31

Alternatively, Event Circles can be massive and replicate the effects of how events behaved before this update.

We hope that Event Circles will bring an extra level of depth to the event system, we think you’ll enjoy them after you get the chance to try it out! Event Circles will be included in the 2.0 update coming August 20th, so mark your calendars.


Troy Bonneau
President of Triverske

triverske / August 2, 2016 / Tech Blog, Ultimate Arena

Circuit Breakers | Tech Blog: The Many Menus of Circuit Breakers Pt. 1

One of my finer achievements in game development is the menus of Circuit Breakers. For whatever reason during the development cycle I took on the challenge of creating something that both looked and worked great. In just a single year Circuit Breakers has progressed quite a bit as far as the interface is concerned. Let’s take a quick look back at the theĀ evolution of menus in Circuit Breakers.

Screenshot 2016-07-18 15.20.06

July 4th, 2015 Build

For the first two or so months of development, Circuit Breakers had no menus at all. On startup you were sent directly to the first room of the game. I can’t seem to find the code for this build but if I recall correctly the weapon selection only worked for Player 1. The important thing about this menu was how it allowed us to change the amount of players without compiling an entirely new build.

Screenshot 2016-07-18 13.45.36

July 20th, 2015 Build

The first menu that supported controller support (and actually accidentally only supported controllers) was first compiled just 16 days after the previously shown menu. The “QUIT GAME” and “FULLSCREEN” options are pretty self explanatory, “KICKSTARTER” opened up a web browser and took you to the Circuit Breakers Kickstarter. For the most part the Kickstarter option was for us to remind people that Circuit Breakers was on Kickstarter at SGC 2015 and Let’s Play Gaming Expo 2015.

Screenshot 2016-07-18 15.30.38

July 20th, 2015 Build

“DEMO MODE” pulled up the character select screen and then took you to the main game which we now call “Arcade” mode. The first character select screen did the job well, but I wasn’t too impressed with it. Functionality was basic, but this was the first build with all 4 characters and was one of the first times the game started to really come together.

Screenshot 2016-07-18 13.37.28

August 2nd, 2016 Build

The next change to the menu was to add the ability to change the controls. This build allowed you to set whatever player you wanted as a keyboard or xinput controller. You’ll notice that these last few builds have the date 7/18/2016 in the corner because I compiled these builds from old code I have in the Triverske archives. The compile date in the top corner was never as useful as I thought it would be, but if you go back and look I bet you can find a few builds compiled at 3 or 4AM.

Screenshot 2016-07-18 15.52.23

August 22nd, 2016 Build

By mid-August we had started working on a more refined menu that was a bit more fit for release. The new menu was built for the purpose of having clean aesthetic with the same basic functionality. Possibly the most interesting thing on this menu is the inclusion of an “ADVENTURE” mode. You’ll be sorely disappointed to know that the option didn’t do anything at this point in time. Hitting “EXTRAS” actually quit the game in this build for whatever reason.

Screenshot 2016-07-18 15.56.42

August 22nd, 2016 Build

For the first time you were able to select cores, and those familiar with how the game looks now will see the similarities between this character select screen and how it looks today. Also worth noting is how dark the colors are in both menus on this build. It must have been my laptop screen or something but things just do not look very good in hindsight. Anything from this build forward was never seen in public because we didn’t go to any more conventions in 2015.

September 25th, 2015 Build

September 25th, 2015 Build

For whatever reason the build date in the corner reappears along with the gears that are still there today. By this time we decided that “ADVENTURE” mode was not going to happen and was replaced with “SCORE ATTACK” mode. Hitting the “EXTRAS” option doesn’t exit the game, but instead tells you that nothing is there.

Screenshot 2016-07-18 16.11.41

September 25th, 2015 Build

More cores are in the game by the end of September, in fact allĀ of the regular cores appear to be here. The boxes around the characters have been removed. The green particles at the bottom changed colors based on how many cores were turned on.

Screenshot 2016-07-18 16.23.04

November 13th, 2015 Build

Right before release the menu takes on a near final form. I finally got around to finding some decent colors for the main menu. The current main menu as of when this was posted is almost indistinguishable. The “EXTRAS” menu is filled with several options and everything is working as intended.

Screenshot 2016-07-18 16.23.23

November 13th, 2015 Build

Cores now will appear locked if you haven’t obtained them yet. I swapped typefaces a few times until I found something that I was pleased with. We ended up removing the particles in exchange for gears that spin faster for every core that’s turned on.

Screenshot 2016-07-18 16.23.44

November 13th, 2015 Build

Score Attack finally got its own screen pretty close to release. As far as I’m aware this screen is exactly as it appears today. There’s a fun story about getting the Avatars to correctly display next to the name of the player. That’s a different story for another time.

That about wraps up part 1, in part 2 I’ll talk about the extra screens, and changes made since release.

Troy Bonneau
President of Triverske

triverske / July 18, 2016 / Circuit Breakers, Tech Blog

Circuit Breakers | Tech Blog: My code works, but I don’t know why

Recently I’ve been doing some optimization work which is pretty regular occurrence for anyone who’s ever gone beyond “hello, world” and the intro tutorials, and I’ve always been fascinated by the idea of getting games to work on hardware that shouldn’t be possible, my personal favorites being Doom SNES and any version of RollerCoaster Tycoon 1+2. Today’s tech blog revolves around me experimenting with a few different optimization methods in GameMaker: Studio.

The Problem

Programming is a lot like travelling from one city to another, there are several options to get there and depending on your choices it could take you a little bit more time to reach your destination. For example, the bus might be more cost effective, but it also will take more time than driving a less cost-effective but quicker car. Sometimes we have a lot of money and no time, and sometimes we have a lot of time and no money. Often it is up to the programmer to decide which route will be used. The problem happens when either time or money has been exhausted and you’re not able to reach the destination.

Layman’s terms aside, Circuit Breakers is deceptively CPU-heavy and requires a sizable processor to keep up with hundreds of instances of enemies, players, and energy crystals at 60fps. Most people tend to be under the impression that games that look like Super Nintendo games could run on equivalent hardware. The good news is that we have made it possible for pretty much any x86 desktop in the past 7 years can play the game in its perfect fluid form, however some hardware was not quite as lucky.

We don’t keep extremely low-performance x86 hardware around the office for reasons yet to be discussed, so in the midst of our testing I decided to establish the “Android Test Platform” in order to simulate what low power x86 hardware might behave like. The Android Test Platform (which I’ll just refer to as the ATP from now on) is actually just an Ouya that I binge-bought from a few years ago. The Ouya has a quad-core 1.7 GHz ARM Cortex-A9 that simply doesn’t cut it when it comes to games. I found the worst dual-core Celeron of 2008 and it has a sizable performance increase over the ATP despite it having less cores and clock speed.

Ouch, thanks to CPUBoss+ GeekBench

Ouch, thanks to CPUBoss+ GeekBench

It’s very clear that the Cortex-A9 even with its improvements over its predecessors can’t top the greatest processor architecture ever created. This is off topic though, the point here is that the ATP is a glance into pre-2008 computer performance, and probably pre-2012 laptop performance.

Upon booting up the game after exporting it through the compiler I found that the game ran on the ATP with a few visual defects. For one, some of our shaders were not behaving and resulted in some unwanted but not game-breaking graphical issues. More importantly the big problem is we couldn’t hold 60 frames for any period of time, a deal-breaker when your logic is tied to the framerate. In order to quickly combat frame drops I reduced the amount of effects rendered to the screen, decreased particles, and limited the amount of enemy instances that could appear concurrently. Unfortunately none of that helped to the point where I could keep the game running at a steady 60, not to mention it affected the overall game experience quite negatively as the game isn’t as interesting when you remove the explosions, enemies, and particles (who would have thought). It was time to call it a day, and expect people to have better hardware.

Well that’s probably what should of happened, but I was determined.

These kinds of challenges happen to every developer, it’s not some sort of unusual thing for people to try and get the most out of a machine. When faced with low-performance and you’ve done all you can, you must learn to compromise in all the right ways. Masahiro Sakurai mentions how challenging it was to get Super Smash Bros. for 3DS running fluidly, and makes multiple compromises to the graphical quality of the game in order to make that happen. For example, he makes some objects run their animations at 30fps.

So I did exactly that,

but with everything,

and I don’t know why it works, but it does.

Frameskipping is not some foreign concept, in fact many games skip frames on purpose for non-performance reasons like Skullgirls. When I told the game to draw every other frame I was able to hit that coveted 60fps that I had been longing for and was able to add in those effects, enemies, and particles. The only negative result is that I’m only able to see every other frame instead of every frame, a compromise I’m willing to make if I can keep the game the way it was intended to be. Normally a person would stop here because the “problem” has been fixed but I have a new problem now. This is actually impossible and there’s no reason why this should work

From what I understand, GameMaker runs code in the following order


Which means that with my code it should look something like this


Only one problem though, as you remember, when I had effects and particles and enemies on the game wasn’t running at 60fps, meaning that

|-----GREATER THAN 1/60s-----|

A step > logic combination was most definitely taking longer than 1/60 of a second. As a result, that should have caused the second step event to occur at a point later in time, thus slowing the game down. This never happened though, the game runs at 60fps only drawing every other frame and I have no clue why. Should it not be constantly stuttering between a frame that takes more than 1/60 of a second and one that takes much less than that? If you can explain please send me an email at troy@triverske.net

triverske / September 25, 2015 / Circuit Breakers, Tech Blog