The engine used to build this game was a once-off creation, designed explicitly to run this particular title. This is not a real game engine, this is a GENERIC category.

A game run on an engine built for a few games (a game series, etc.), but not being clearly known or featured, should be assigned to Unknown engine.

Latest Media

No images, videos or audio files have been added to this gallery. Join now to share media with the community.

Blog RSS Feed Report abuse Latest News: What's on the menu?

About Proof with 0 comments by vivavolt on Jul 6th, 2015

This post originally appeared on the Voltic Blog

So far, we haven't actually talked about the menu systems of Proof. They're actually very important to the game, but we're trying to minimise spoilers as much as possible. However, we've decided that given the recent work we've done it's probably worthwhile sharing some of the details with everyone.

Old Menu

We've had an "item" menu in Proof for some time now, but we didn't _actually_ show it to anyone. So, here you go:

So, you might be able to work this out, but I'll explain it anyway. Basically, in Proof we have an item building mechanic. Nothing quite like the Minecraft style system, and (in my opinion) somewhat more intuitive. Basically, the player has one "item" equipped which is visible in the top row. This can be the combination of 1-3 parts which are visible in the second row. Each of these parts can be one of 8 different parts the player finds in game. These parts sometimes work individually, but can also be combined with one another. I'm not going to explain any combinations, since a large amount of the "puzzle" side of the game comes from these.


So, there are a few issues we identified with this old menu system (I'm sure you can think of more):

- The old system had an implied ordering to the three part-slots
- This is misleading as the parts can be combined in any order
- The selection grid for the 8 different parts is fairly confusing when the player has not discovered all the parts
- The blank center spot in the selection grid is how the player removes a part from a slot, which is pretty unintuitive

But, overall, the biggest issue for me was that the code was horrendous. The original menu was one of the first things I wrote in the game, and I was still fairly new to Flashpunk and AS3. At this stage, we've written a lot more library code that simplifies menu design massively. Overall, the original item menu clocked in at 720 lines of code. Now, I am a big believer that linecount doesn't _really_ mean much but that is quite a lot for a single screen. On the same note this wasn't great code, I've learned a huge amount over the course of this game about structuring applications that I had no idea about at the time.

If you'd like to see the original file, I've uploaded it in a gist here.

New Menu

So, in what some may consider a bold move, I decided to rewrite it. This was a big decision, as the original menu took me a couple of days to rewrite. Additionally, as we all know, rewriting code is a slippery slope. You can easily rewrite your entire application. Spoilers: it only took me a few hours.


Sadly, I don't have my original sketches for the redesign. Our first thoughts were that we would keep a similar layout but replace the grid-selector with a circular one, as you can see below:

This was mainly to allow us to have a variable number of parts available to the user, and to remove the confusing "centre-of-grid-empties-a-slot-for-some-reason" interaction.


Throughout the course of the game's development, we've built up a pretty solid framework on top of Flashpunk. This is tentatively called Volticpunk.

Volticpunk provides a lot of functionality, so I'm only going to highlight the features that were most useful for this menu system.

One of the most beneficial utilities I've created is the concept of Groups and FixedGroups. By default, Flashpunk doesn't provide a way to group Entity together. This allows simple games to be developed quickly, but when creating a menu system life is much simpler when you can group things together to move them and operate on them. Our Group implementation allows one Entity to contain other Entity's or Group's. The lifecycle of these parent-child combos are tied together. So when one is removed or added to the world, all the children are added or removed. These make use of the same interface as World's typically do.

An extension to Group's is the FixedGroup, any entities added to one of these will have its position treated as relative rather than absolute to the world. When this parent group is moved, the children also move correspondingly while maintaining their offset. This is amazingly useful in menu systems and almost everything in the new menu inherits from FixedGroup.

The parts menu moves with the part slot here using FixedGroup.

All positioning is also accomplished dynamically, this allows very clean layout code which relies on math rather than manual offset specification. This is done using pretty basic trigonometry, but I'll include some sample code for completeness:

for (var i:int = 0; i < ITEM_LIST.length; i++)
    item = items[i];
    item.isSelected = false;
    var angleIncrement: Number = 2*Math.PI / ITEM_LIST.length;

    calc = this.angle + angleIncrement * i - Math.PI / 2;
    item.groupX = Math.cos(calc) * radius;
    item.groupY = Math.sin(calc) * radius;

This simply displays however many items the player has in a circle surrounding the origin of it's FixedGroup.

Major Lessons Learned

The main difference, aside from grouping and other utility methods from volticpunk, is just better design. The new menu system is built in layers:

    -> EntryPoint
        -> Subslot
            -> SelectableItem
            -> SelectableItem
            -> SelectableItem
            -> SelectableItem
            -> SelectableItem
            -> SelectableItem
            -> SelectableItem
            -> SelectableItem
            -> SelectableItem
        -> Subslot
            -> SelectableItem
            -> SelectableItem
            -> SelectableItem
            -> SelectableItem
            -> SelectableItem
            -> SelectableItem
            -> SelectableItem
            -> SelectableItem
            -> SelectableItem
        -> Subslot
            -> SelectableItem
            -> SelectableItem
            -> SelectableItem
            -> SelectableItem
            -> SelectableItem
            -> SelectableItem
            -> SelectableItem
            -> SelectableItem
            -> SelectableItem

Each of these layers is only aware of the layer immediately below it. This allows very clean code design, which is not tightly coupled to any specific menu implementation. Basically, each of these layers has `open` and `close` methods, which the layer above calls as appropriate. Here's a how that maps to the actual in-game appearance:

Tweaks and Design Takeaways

So, here's a final Gyfcat overview of the system: Final Menu

After solving some of the original design issues we had with the menu we took some time to think about how to make the menu easy to use. One of the first measures we looked at for this was animation. The old design was also animated, but with a circular design the animations and timings do a lot to give the user context. If the animations are too slow, the UI will feel unresponsive and frustrating but making them too fast will lead to the user failing to understand exactly what happened. It's basically a balancing act, and we think we've arrived at something reasonable.

In the same line of thought, we added the "spokes" that join the EntryPoint to each Subslot to help visualise the rotations and linking. Originally we also used these to join each SelectableItem to each Subslot but decided it was too busy for the user to digest.


So there we have it, we identified the issues we had with the old menu, planned a design that would overcome them, iterated on the design and came up with something that I'm pretty happy with. This is a classic example of our skills outgrowing our work though, which has been a common theme throughout Proof's development. It's satisfying taking something to that next level, but a little depressing when two years later you think it's rubbish. Hopefully we won't have another two years on Proof for me to redo this again!

I think this has been an asset throughout Proof, and has helped us hold on to the mindset of constantly reevaluating our work. This doesn't mean we're always redoing everything, but it's very important to be sure you're happy with the game you're putting together. I'm still exploring ways to improve this menu even though it's "done" at the moment..!

Remember to follow us at @vivavolt and @iammonshushu for smaller updates on the game's progress!

Add game Games
Disposable Heroes
Disposable Heroes

Disposable Heroes

Updated 1 hour ago TBD Single, Multiplayer & Co-Op Hack 'n' Slash

Meet the disposable heroes... A rag-tag band of nobodies who - quite by accident- represent the kingdom's last hope.With the royal army slain it is they...



Updated 2 hours ago TBD Single Player Cinematic

In Proof, you control an ethereal, disembodied spirit who becomes more tangible in light. You begin deep underground and must work your way to the surface...



Updated 2 hours ago Released Feb 26, 2015 Single Player Educational

Swipe and swap your way through SUM IDEA’s 140 challenges of mental dexterity. 4/5 148Apps: "charming throughout, with visuals that keep you happy as...

JutsuOnline - A Naruto MMORPG (2GB Standalone)
JutsuOnline - A Naruto MMORPG (2GB Standalone)

JutsuOnline - A Naruto MMORPG (2GB Standalone)

Updated 5 hours ago TBD MMO Role Playing

A Naruto-Like MMORPG. Alpha testing phase is now Open! (2GB standalone client.) View gallery for infos.. Visit us at



Updated 5 hours ago Released Jul 2015 Single, Multiplayer & Co-Op Arcade


Post comment Comments  (50 - 60 of 122)
defragen1 May 25 2012, 9:18pm says:

The name of my engine is engine.

+4 votes     reply to comment
Trollmar Mar 8 2012, 6:14pm says:

this might sound rude but i need help. i need a coder, modeler, texture wad artist for a new game i made called pspikmin. again sry for being rude but i need help. so if you want to help message me.

+5 votes     reply to comment
coc568 Mar 2 2012, 8:40pm says:

This engine is just built by the engineers or whom ever made the engine for a specific game or game series and this is not one is not one engine

+4 votes     reply to comment
Vhorthex Feb 28 2012, 7:34pm says:

Sweet pic for the background there. I want it for my desktop! :(

+5 votes     reply to comment
aydens Feb 2 2012, 6:00am says:

how u do it

-2 votes     reply to comment
togoaway Aug 31 2012, 8:59pm replied:

how u do what?

+2 votes     reply to comment
aydens Feb 2 2012, 6:00am says:

how u do it

-3 votes     reply to comment
hug00m Jan 5 2012, 12:10am says:

How much is the licence for this engine?

+5 votes     reply to comment
togoaway Aug 31 2012, 8:57pm replied:

it costs around $400 - $500 to get the commercial licence. xD

+4 votes     reply to comment
Zollec Oct 8 2012, 2:42am replied:

U R such a troll :D , but Dat question XD

+2 votes     reply to comment
xweert123 Apr 21 2012, 9:51pm replied:

..Your kidding, right?

+3 votes     reply to comment
mutput7 Jan 7 2012, 2:32pm replied:

Exactly four hard works.

+12 votes     reply to comment
Post a Comment
click to sign in

You are not logged in, your comment will be anonymous unless you join the community today (totally free - or sign in with your social account on the right) which we encourage all contributors to do.

2000 characters limit; HTML formatting and smileys are not supported - text only

Send Message
Release Date
Released Sep 2007
Engine Watch
Track this engine
Community Rating



309 votes submitted.

You Say


Ratings closed.

Highest Rated (11 agree) 10/10

Dumbledore Gets Killed By Snape.

Sep 6 2011, 9:58pm by pocketlint60

Embed Buttons

Promote Custom Built on your homepage or blog by selecting a button and using the embed code provided (more).

Custom Built Custom Built
Custom Built
15 of 721
Last Update
1 day ago
253 members