Welcome!

  We built Future Perfect because we love making games but don't love much of the drudgery that often comes with it. We imagined a giant pile of Lego-like game bricks that everyone gets to play with and create stuff we wouldn't even dream of. The whole idea is of course completely nuts but that didn't stop us trying. This was about a year ago and after much furious coding punctuated by heated debates that wouldn't end until everything was both sufficiently flexible and perfectly simple - we finally feel that it's time to share our madness with the world and invite you all to come play with our bricks. It's not quite ready yet - most of the bricks we made so far have nails sticking out and smell of superglue. However the foundation is in place and we think it's pretty awesome. Besides, the bricks we're building are just the starter set - Future Perfect is really all about what you'll make.

Basic Concepts

  Before we go make new bricks, let's look at the core ideas of Future Perfect's engine. The game world is a collection of entities. Entities are everything - the environment you're running around in, the avatar you control. Entities on their own can't do very much - they have a position and orientation, list of user defined tags and they can be optionally attached to another entity. The real work is done by components that you add to an entity. Each component type exposes a piece of the engine's functionality - the model component is the primary way to get something drawn on screen, collision component defines how the entity behaves in the physics simulation and the focus of this post is the script component that attaches a single Lua file to an entity. There are 16 different component types at the moment and they're all designed to be as simple as we could make them. As it would be tedious to have to set up each entity from scratch by painstakingly adding and configuring all its components, you can store arbitrarily complex configurations of entities as blueprints. Note that blueprints are like cookie cutters - modifying a blueprint won't affect entities already created using it. Blueprints are an asset - a file that lives in a package that is automatically processed by the game's asset pipeline. Worlds, Lua scripts, FBX models and WAV files are all examples of different types of assets. The game always watches for modifications to asset files and automatically builds and reloads them in the background. Packages, in addition to being bags of assets, also maintain a list of dependencies on other packages (depending on a package makes all of its assets available) and can be easily published to Steam Workshop. You'll always be 'inside' of some package - either by explicitly opening one in the editor or in a temporary working package, so that whenever a new asset is created it has somewhere to go. Beware that the working package is deleted on exit!

Creating a Package

  Alright, let's get started. I thought it would be fun to try to recreate the game of Minesweeper - a first person, multiplayer Minesweeper. With jump pads. Run Future Perfect and select 'Start Editor' from the main menu. First let's get out of this fleeting ‘working’ package that we start with - click on the 'Package Properties' button: [PACKAGE PROPERTIES BUTTON] In the packages menu, fill in the 'Title' in the left pane. The folder name will be automatically filled in for you - just hit the green tick. See that 'Publish' button at the bottom? Yep, that's all it takes to get your package up on Steam Workshop (I know it's tempting, but please be patient!). The middle pane shows the packages that our package will depend on - the game starts you with some nice defaults but for a Minesweeper game we'll definitely need a mine - search for the 'Mine' package in the right pane and drag it into 'Loaded Packages' in the middle. The right pane shows all the packages you've subscribed to in Steam and you can use the search function to look for all packages available on Steam Workshop. We're finished here, so just hit the 'X' on the right.

Adding a Player Spawner

  We're now editing a world called 'New' (see top left corner) - you can click on this tab to rename it. Select the default floor entity and use the sizer arrows along its edge to make it a bit bigger. If we'd start the game now, there would be no entity associated with the player so you would only control the default spectator camera. To fix that, place the 'Player Spawner' blueprint on the floor. Mouse over the right edge of the screen to open the asset browser, type in 'player' to see only matching blueprints and drag&drop 'Player Spawner' into the editor. Entities without a model component show up as dashed white square so our new spawner isn't much to look at. Click on the black bar with 'Player Spawner' label near top right to open up the entity editor panel: The blue tab bar lists the entity's components - the spawner only has one script component on it. Click on it (the gear icon) to see all the fields this script defines. Each is bound to a variable of the Lua script and allows us to configure the script's function. The most important value for us is 'Player Blueprint' - the spawner script will use whatever blueprint you'll bind to this field as the player entity whenever a new player joins the game. Click on the empty field next to it to open up the asset browser, filtered to only show assets of the type matching the field (in this case blueprints). Drag the 'Avatar' blueprint from the asset browser and drop it on the empty field: Press F5 or click on the play toolbar icon to spawn as 'Avatar' in our very sparse world. Now we're ready to pick up speed! Press F5 again to enter the inspect mode - which is just like the edit mode except that the game is running. Don't get too creative though as all changes are lost when the game is stopped. Press the stop toolbar icon to return to editor.