#fanta friday

[askagamedev]

FANTa Friday - Design Phase, part 6: Raising the Roof

Apologies for the lack of FANTa update last week. My workload at the office has been ramping up due to impending deadlines and scaling responsibilities. I’m still learning the ins and outs of the Creation Kit in my off time and I’m making some progress. This week I’ll be discussing a specific observation and tool for level design using a demo I’ve made with the creation kit. Specifically, how to make a space feel big or small, despite both having the same amount of playable and usable space.

This is our demo room. It is a rectangle.

I’ve added a ceiling to this room and built it for Skyrim. Observe - Here’s a video I shot of me just wandering around for a few seconds in this room:

It seems like a good sized room. Then I made some minute adjustments. Even though the total amount of playable space available remains constant (the total amount of space in the room where I can actually reach by walking), it feels very different. All I did was raise the height of the walls and ceiling by about double. Take a look:

Doesn’t it feel so much more spacious than before? There are all sorts of little indicators that make it feel bigger - the fact that the upper part of the room seems to be moving more slowly than the lower part due to the perspective, the fact the ceiling is now outside of the default sight line forcing the player to actively look up in order to see it. 

You may not have noticed these specific elements until I mentioned them, but I can assure you that your subconscious brain did. That’s why it feels bigger - your subconscious brain is telling you “this place is way larger than the last one”. This architectural technique is often used in home construction as well - if you build high ceilings, it makes the place feel bigger even if it’s actually a tiny studio apartment with very little floor space. 

This effect also works in reverse. Observe:

This time I brought the ceiling down from the “normal” height, to the point where it is barely above the player’s jump height. Doesn’t the room feel so much smaller now? The space just feels like an enclosed box. It’s still the same room. It’s still got the same amount of playable and usable space. It’s just the feeling from adjusting the height of the ceiling that evokes an entirely different reaction from the player. Your brain is subconsciously picking up on all of the little observations, like how the ceiling seems to move faster relative to the walls and the like.

Level design is about using multiple techniques to evoke a specific feeling in the player. For the FANTa project, we need to build a sense of verticality as well as scale and size. This means that we’re going to go with a lot of high ceilings in places like the Mezzanine and the Observatory. We probably want the Cellar to feel a little smaller and more claustrophobic, but we also want the player to fear potential falling, which means it will likely have low ceilings and bottomless pits visible. There are lots of other architectural techniques we can do in addition to this (some of which I’ll probably go over in the coming weeks) that all function as tools to craft a space where we can convey a lot of information to a player within a very short amount of time with just the way it looks.

This week we continue the Design Phase of the FANTa Project!

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent questions: The FAQ

[askagamedev]

FANTa Friday: Design Phase part 5 - Ambient Storytelling and Throughline

One of the things about exploring an environment is that we can tell a lot about a place just through the placement of objects in that place. If you don’t believe me, just examine a friend’s bedroom (if you can get permission... many won’t). Note the objects that are there - what’s on the desk? What’s on the floor? What’s on the walls? How are they placed? Why are they placed that way? What do each of these objects placed in such a way say about the person who put them there?

A neat person might keep things organized and stored away. A messy person might have things all over the place. That’s something easy that you can infer from looking. But what if you wanted to start looking deeper at what sort of person might be living in this room?

If you see a collection of ticket stubs, maybe you can infer that this person likes seeing live music. If they’re all for a specific band, you can infer that this person likes that band. There might be posters for that band on the wall as well - seeing all of these would definitely reinforce the idea that the inhabitant of the room is a fan of a specific band. This is just one throughline in the environment.

“But dev, why should we care? This sounds like some of that Gone Home crap. What does some band groupie have to do with the sky palace you’re building?”

The placement of specific objects in the environment is conveying information to the player, and we’re doing it without having to force it via lengthy exposition. There’s no NPC that has to explain what happened to the player, there’s no cutscene to sit through, it’s all there for the player to pick up just by looking around, exploring, and taking in the scene. This can be incredibly valuable.

Remember, we’re creating our environment out of nothing. Nothing exists there unless we choose to put it there. Details like these will get noticed by players either consciously or subconsciously. We can scatter the details around haphazardly, but it will feel much better to the player if all of the little details work together cohesively to tell a story just through their existence.

Let’s bring this back to the sky palace. What are those core ideas we wanted to go over again?

Verticality

Openness/visibility

Showing places of interest

Encouraging the player to think in terms of up and down

Also, we need to prepare the players for a boss and maybe let them know what kind of boss it is. So what sort of environmental elements can we insert to help push these ideas as well as prepare the players for a boss? Here’s my thought: Do you remember how we were thinking about there being a menagerie in the Atrium? What if one of those things escaped? What if it wrecked the temple while doing so? But, more importantly... what if it never left? What if that thing is the boss?

Let’s consider how we can use this idea to tie together the rest of it. A strong flying monster, like a dragon, would almost certainly cause damage if it were crashing its way through a palace. If it were strong enough to kill the inhabitants, it could probably tear large chunks out of the walls that let the sun and sky in (openness and visibility, check). Those holes and missing chunks could probably let the player see through them and observe other elements of the dungeon (showing places of interest, check). Those holes would almost certainly be at differing heights, since the boss should be able to fly (verticality, check). All of this combines nicely with the idea of placing the bodies of the boss’s victims judiciously to show its danger. We could probably place a few broken cages at the menagerie to show its origin. 

Let’s do some role playing. Imagine it from the perspective of the player entering the dungeon for the first time. 

You enter the mezzanine to see the different levels separated by stairs, but some of them have been torn asunder. There’s a large hole in the wall below the eyeline to draw your eye up, and you can see the clouds and sky through it, as well as the ground so very far down below you. A stream of water falls from out of view from above, cascading down like a small waterfall down past the balcony. You can see trees and what look like some metal building frames through another large hole in the wall. A staircase up from your current level seems like it is mostly untouched.

Stepping forward, you look up and see the waterfall’s source - it’s coming from a separate floating island even further up above. Now that you’re at the edge of the balcony, you also can see the waterfall spill over a hole torn through the floor and flow down into what looks like a basement or cellar until it disappears from view. It looks like the hole in the floor is just large enough for you to fit into.

I presented this section without any images on purpose (also because I haven’t had a chance to actually draw things out). Still, can you start to see what the environment looks like in your imagination? Knowing what you know about the themes and core ideas for the dungeon, can you see how we’ve woven them into this environmental description? This is the power of ambient storytelling, and about using it to reinforce your core ideas. Define those core ideas and themes first, then use the environment design to help convey those ideas and themes.

This week we continue the Design Phase of the FANTa Project!

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent questions: The FAQ

[askagamedev]

FANTa Project Update - it’s on hiatus (for the next 2-3 weeks)

I’m really sorry about this, but I can’t update the FANTa project because my current project (the one that pays my bills) is now in crunch mode and I just don’t have the time to spend on adequate level design when I’m working an extra 20-30 hours a week on mission-critical stuff. FANTa updates are way more involved than regular updates because the regular updates are stuff I already know and can write off the cuff, but FANTa updates require me to spend time doing the design stuff and then writing about it (and taking screenshots or recording video to show what I mean).

I’m still working on it. I really want to keep going with it. But I can’t; not for the next two weeks or so. Once crunch is done, we’ll get back to it. I’ve got some really cool ideas for the Mezzanine I want to put down and some techniques I want to show you. But, for the moment, I just don’t have the time. Apologies.

This week we continue the Design Phase of the FANTa Project!

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent questions: The FAQ

[askagamedev]

FANTa Friday: What is the FANTa project?

The FANTa project is the Follow Along Not (quite) Tutorial Project. The FANTa project began because there’s a wide gap in game development resources between the very basic “getting started” tutorials and the much more advanced specialist topics. For inexperienced people interested in game development those gaps can feel immense, especially without feedback during the process. It’s really hard to improve when you’re not sure if you’re doing anything right.

That’s where the FANTa project comes in. Rather than just explain individual concepts one at a time in a vacuum, I’ve decided to start a project and show the process. This way, people can see what sort of things I’m thinking about while I’m doing this stuff, what sort of constraints we need to identify, and even consider scoping and scheduling issues. We’ve [chosen a topic] (level design) and have [chosen] a concept. Each week, we’ll advance the project, describing and commenting on the process and progress.

Here’s a rough idea of what to expect in the weeks to come:

Concept phase - Choose a concept, consider the high-level elements we want the player to experience. What is the overall scope for this level design? [Part 1] [Part 2] [Part 3]

Design phase - Now that we’ve gotten our core concepts, we need to start whittling it down. We have our high-level elements, and now we need to start breaking them down into conceptual chunks we can feasibly create. We’ll create some initial layouts and check against what sort of constraints the tools might have for us here [Part 1] [Part 2] [Part 3] [Force Push prototype demo video] [Part 4]   >> WE ARE HERE <<

Grey Box - Let’s build out the space without any art or textures - just placeholder stuff. How does it feel? Do the areas convey the sort of experience we wanted? Do they feel sufficiently differentiated from each other?

Placeholder obstacle/object/enemy placing and scripting. The area isn’t just going to be a space to explore, it has to have gameplay value. Here’s where we’ll get started getting these to work.

Playtesting and iteration - Is this thing starting to feel fun? Where are the pain points? What isn’t clear?

Environment textures. We like the way the space is laid out, now we’ll differentiate them and make them look right.

Environment objects/prop placement. Let’s get the areas feeling less empty and more like a real place.

Production pass - We’ll go back over obstacle/object/enemy scripting and placement to make sure they are getting fun. Replace all of the placeholder stuff with the real deal.

Playtesting and iteration - Get the whole thing together, then try playing through it. What needs improvement? What isn’t clear? Cool, let’s go fix that.

Release. Everybody gets to play it now.

Obviously, this entire process will take some time to get through. There will likely be unforeseen circumstances that will crop up, and we’ll have to iron out some kinks as we go. We’ll have regular snapshots of the project’s progress along the way for people to look at and follow along with. Hopefully, this will be a good start to bridging the gap and for novice game developers to take the next step beyond the first.

[Vote for the FANTa level concept!] Voting ends TONIGHT at midnight Pacific Time (8:00AM GMT Saturday)

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent questions: The FAQ

[askagamedev]

FANTa Friday - Design Phase, part 3: Playing with Prototypes

It’s FANTa Friday! This week, I played around a bit (when I could, the project I’m being paid for is nearing a pretty big milestone) with the scripting language and spent a few hours familiarizing myself with some of the elements of the Skyrim Creation Kit. If you plan on following along, you should get yourself set up too. All of the files that will be necessary for the FANTa project should now be available [here on github]. I hope that today’s post will help you understand how the Creation Kit organizes its data which, should you decide to use it, allow you to learn how to organize and construct your game elements.

First, what I did - I built a quick and dirty spell that throws a magic energy ball that force pushes NPCs away from you, knocking them on their asses. It’s named “Force Push” and you can grant it to yourself after installing FANTa.esp that you should be able to download from [here]. If you have Skyrim and want to give it a try, install the mod (installation instructions [here], start the game, open up the console, and run “player.addspell 05000D62″. That ought to get you started. It doesn’t work on regular objects. Yet.

Think of Skyrim’s architecture as a set of building blocks with a hierarchy. Our Force Push prototype is a Spell. A Skyrim Spell consists of data like an ID, a name, a type, a means of casting, which hand you can equip it on, casting animations, etc. However, the Spell itself doesn’t inherently do anything by itself. Instead, it functions like a bag that holds one or more magic effects.

A Magic Effect is a collection of even more data. Here, we can set up different elements to a particular effect that can be used as part of a spell (or even reused as part of a family of spells). The effect has its visual and auditory components like what they look like when activated, when they hit, what kind of sounds to play at various times, what flags to set on nearby NPCs (like “turn hostile”), etc. The effects can dispel other effects, interact with particular schools of magic, or even require specific conditions be met before working. All of Skyrim’s current spells are built from multiple Magic Effects firing when the spell is cast. Beyond this, each effect can also run one or more scripts. 

Scripts are where we can start really flexing the creative juices. This is where we can make the game do explicit things with the code that don’t explicitly exist. In the Force Push script I wrote [here], you should be able to see what I did - I calculated the direction from the caster to target (plus moved it slightly upward) and used that as the direction of the havok force to apply to the target with a magnitude of 500. I tried 5000 at first, but that actually ended up shoving the NPC so hard she went through the ground. If you want to start playing with things, you could start by messing with some of those values. It should be easy to figure out how to edit the Force Push script to shove people upward or in a specific direction.

Remember, we’re still just prototyping stuff. None of this is set in stone yet. Our goal with any prototype is to get something together that’s close enough to what we want, even if it’s quick and dirty. It isn’t balanced, it isn’t pretty, and it doesn’t do everything I want... but it does provide me something that’s close to our concept that we can play around with it to find the fun. And... sending enemies or even regular NPCs flying is pretty amusing so far. We can use this, for example, to create a puzzle that involves shoving an NPC into a specific trigger zone. Next week, we’ll continue with the prototyping to try getting some form of High Jump working.

P.S. Feedback is important for a project like FANTa. I know that FANTa is supposed to be not quite a tutorial, but I also want to make sure that I’m providing enough in these posts for people to follow along without getting lost along the way. Please let me know if I’m skipping over/assuming too much, if I’m not moving fast enough, or just let me know I’m going at a good level of detail to get to what we need to do. The last thing I want is to leave behind the people that FANTa is for.

This week we continue the Design Phase of the FANTa Project!

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent questions: The FAQ

[askagamedev]

FANTa Friday - Design Phase, Part 1: Overview

It’s FANTa Friday. Today we kick off our design phase, where we’ll go over the level overview for the dungeon. If you remember from the [Concept Phase Review], we are looking to incorporate the following ideas into it:

Verticality

Openness/visibility

Showing places of interest

Encouraging the player to think in terms of up and down

This is a dungeon where power is literally based on height. The higher you go, the more powerful things get. The further down, the lower your status.

Also, this is a winged dungeon. This means that our basic layout will be five total areas:

A staging area (the Mezzanine) to function as a hub to reach the other areas. The key elements here are that multiple floors should be clearly visible from anywhere in this area. Expect spiraling staircases, railings, upper and lower floors, and decorations to indicate where the exits lead. We want to keep the exits to the Mezzanine within the normal field of vision, but not directly at eye level - they must be above or below to really hammer home the verticality.

The area where we obtain our first mechanic, aka the Cellar. This area should convey a feeling of underground, but a little bit different. This is a castle in the sky, which means that there isn’t much underground. Instead, we’re going to have a lot of holes and areas where the player can look down and see the clouds below (and possibly fall to her death). Think lower-class stuff here - servant’s quarters, storage, stonework, etc. This is also an excellent area for platforming.

The area where we obtain our second mechanic, aka the Atrium. Think of it like a botanical garden - it’s curated, but it’s full of greenery. We can expect birds, some wild animals (perhaps escaped from a menagerie) and plants here, but the environment should have a very planned layout.

The area where we obtain our third mechanic, aka the Observatory. Think telescope, lab equipment, and books. Science stuff, paintings, tapestries, bookshelves, and the like.

The area where we fight the boss, aka the Tower. This area will likely be shrouded in mystery, but it will likely have a big hole in the ceiling so the dragon can land and we can fight it.

Right from the start, you should notice that I’m naming each of the separate areas a very distinct name that inspires a specific kind of visual for that area. One of the goals of level design is to make each area visually distinctive in order to instill a sense of place in the player when they see it. One of the most frustrating things a player can go through is getting lost. Similar to how we want characters to have distinct silhouettes, we want level environments to have a distinct visual style. Naming them also helps dispel any confusion in the future when referring to them. I can say “the passage from Atrium to Cellar” and it makes sense to anyone familiar with the layout. If you’re designing a level, you should divide it up into major sections and try naming each one in order to help keep them straight in your mind as well as establishing a common vocabulary with other people and in documents.

You may also have noticed that I’m building the concept of verticality into the design simply by the sort of areas we’re making for each wing. The Cellar implies an underground area. An Atrium is more of a ground floor thing. The Observatory brings expectations of higher elevation, to be closer to the stars. The term Mezzanine refers to a large room with multiple observable levels separated by stairs. This is important - it helps reinforce the theme to the observer as well as the team members. Whatever your level’s theme is, it should be visible throughout your entire level.

I would like to note that this design is looking very ambitious. We may have to cut one (or more) of the areas/mechanics for scope. Five fully designed areas might be too much for one person to handle in a timely fashion. The good news is that any of the three mechanic areas are modular and can be cut. We don’t necessarily need all three. We’ll continue looking at them for now, but it’s just fair warning for those following along - this might be too much to finish. We must keep the mezzanine and the tower, but we could probably cut one (or even two) of the other areas if scope proves to be a problem.

Let’s recap today’s design takeaways: 

Keep your theme central to the different environments you’re planning out. Ask yourself how the theme is being shown in each area. 

Make sure that each planned environment is visually distinct from the rest. Players hate getting lost. 

Name each major section of the environment something short and descriptive to reinforce their distinctiveness. 

Keep an eye on the level scope. Identify early what must be kept and what isn’t necessary but still nice to have.

This week we step into the Design Phase of the FANTa Project!

[What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent questions: The FAQ

[askagamedev]

FANTa Friday - Concept Phase Review, part 3: Putting it all together

Welcome to another [FANTa Friday]. The votes have been tallied and the winner is a Sky themed dungeon. Today, we’ll gather up the overall concepts we’ll be incorporating into our level design. This also marks the end of the Concept Phase Review. Next week we’ll begin on the Design Phase.

Visually speaking, we should plan for a lot of clouds, bird visuals, and airy architecture. Think of architecture like the Moon Door from the Eyrie in A Song of Ice and Fire - gravity makes going down easy and going up difficult. The natural theme of “ascension” plays very nicely with the concept of a sky-themed dungeon. We start low and work our way up to the boss. We need to accentuate this with architecture that allows the players to see where they should be going. This means open floor plans and clearly visible other parts of the tower. There should be more pillars instead of solid walls, open windows instead of closed, and the very real possibility of falling.

The theme of a sky dungeon also lends itself well to the final boss being some sort of dragon. It’s visually very distinct as well - the dragon circles the final wing of the dungeon that remains just out of reach until the player opens it with the mechanics earned throughout the dungeon. The player will be able to spot it from a distance, which builds anticipation for the coming climactic battle.

We are currently planning four dungeon wings (including the final boss wing), which naturally lends itself to a couple of different potential layouts, like so: 

This layout gives the player the most freedom to explore. Each wing of the dungeon would need some way to traverse to another wing, and the added benefit here is that moving from A to B isn’t necessarily the same as going from C to B, meaning that approaches from different directions can be rewarded, especially if some of these means of traversal are also gated by traversal mechanics.

A second option is a more diamond-shaped structure:

This is a bit more linear, but it also gives players a better baseline for establishing expectations. We gate areas B and C behind the mechanic earned in area A, which can function as a tutorial to the dungeon. This conveys a feeling of “opening up” the remainder of the dungeon to the player, which usually establishes a sense of accomplishment if the task doesn’t feel trivial.

One core design concept we absolutely need to emphasize is the idea of verticality and height. Humans don’t usually think in three dimensions because moving up and down is difficult - we have to use things like elevators, stairs, ladders, or balloons to do it. As such, we aren’t trained to look up and down when we enter a new area, we look around. However, with a sky-themed dungeon, we need to train players to expect it - it’s what makes a sky themed dungeon different than another dungeon with a skybox. We need to craft the visuals to draw the eye upward and downward toward elements of interest in order to entice the player to get to these places. This means crafting obvious points of interest just inside the sight line, but specifically above or below the horizontal.

To recap, here are our major concepts for this dungeon:

Verticality in architecture and elements of visual interest

Emphasize a sense of openness and visibility. No thick walls or tiny windows. 

Show the player places of interest that they will be able to reach later. Show the boss early on, but gate it from the player by the mechanics

Encourage the player to think in terms of Up and Down (Place obvious elements of interest above or below the horizontal, but still within sight)

When you’re coming up with a level design, you need to establish your main concepts first. These will inform the individual and specific decisions you make when creating the details and keep the overall vision consistent. If things get ambiguous, the core concepts provide an important overall direction for the dungeon. This helps keep us from getting into the weeds when we’re focusing on those specific implementation details and remember what the central theme of the level is.

Next week, we’ll begin the design phase, where we start using these concepts to begin designing the individual elements of the dungeon.

[What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent questions: The FAQ

[askagamedev]

FANTa Friday - Design Phase, part 4: High on Jumping

It’s another FANTa Friday! Continuing our delve into the world of Skyrim scripting, today I’ve created a new prototype spell for the ability High Jump. The goal here is to let the player activate a spell that will allow her to traverse terrain she normally wouldn’t be able to reach by jumping. Right now it’s pretty crude, but you can take a look at the prototype in action here:

In order to get this ability working, I had to do a little bit of legwork. While there are game settings that control certain aspects of the game (like jump height), the Skyrim Creation Kit doesn’t actually let you change those setting values via script by default. Thankfully, the Skyrim devs have embraced the work of the modding team at Skyrim Script Extender (SKSE) and those hard-working people have managed to enable the additional functionality that I needed to get the High Jump working.

I’ve updated the FANTa project GitHub with the High Jump script so you can take a look at what it’s doing. If you are following along with the Creation Kit yourself, you need to get the Skyrim Script Extender by [clicking here]. Once you’ve installed the new files, you can use “player.addspell 0500182b” in the console to get High Jump. The SKSE team has a Steam installer that works pretty well, but those who want to write their own scripts will have to download the .7z archive and overwrite the script source in their own /Skyrim/Data/Scripts/Source folder or else the Creation Kit won’t recognize some of the new functions added by the SKSE.

These kind of growing pains are pretty common stuff whenever professional devs have to pick up a new tool or learn a new workflow. One of the most valuable skills a dev can have is the ability to get stuff working and figure out what you can do with them without a lot of hand holding. Whatever sort of development you plan on doing, the absolute minimum bar is getting the tools up and running. Just as a point of reference - I haven’t actually played Skyrim much. I didn’t even own the game until you all decided that the FANTa project was going to be a Skyrim dungeon. But I’m pretty good at picking up new tools and I’ve done it a lot, so it hasn’t been too difficult to feel my way through the early prototyping process. I’m learning this as I go.

The main takeaway from the prototype script this week is the way to structure a buff in code. Most buffs are comprised of three basic elements - an identifier (so you know how many and which buffs exist), an effect (in this case a Magic Effect) that does something, and a duration. The identifier is important for organizing multiple buffs. For example, if you want to create a spell that cures poison, you need to be able to recognize what is and isn’t poison. If the target has two debuff that reduce their attack power and only one is poison, you have to make sure that you’re removing the right one. The effect should be reasonably obvious - it’s whatever the buff status is affecting. In this case, it’s the game setting fjumpHeightMin that controls the game’s jump height. Duration isn’t necessarily a hard-coded time interval - it could be the lifetime of the character, a specific amount of time, a dynamic amount of time based on some character attribute like casting ability, etc. But there are always weird edge cases that can come up... for example, whether the buff stacks, what happens when one stack expires, whether there’s a maximum stack, what happens when you try to apply another stack when you reach the cap, and so on. When you’re structuring the code for this sort of thing, you need to recognize the entry points and exit points. When this buff starts, what does it do? When this buff ends, what do you have to clean up? What are the conditions for it to apply? What are the conditions for it to end? The Creation Kit (thankfully) provides a lot of that management for us - we’re specifically taking advantage of the OnEventActivate and OnEventFinished built-in functions for magic effects.

So far, the prototyping seems to be going about as expected. The possibilities these new powers bring to the table are pretty interesting. They definitely make the base game a little more fun to play with. There have been a few caveats so far with the prototypes though - Force Push still only works on actors, and High Jump has a strange side effect where you can get stuck in the air for a moment if you don’t keep moving. If we decide to push forward with these moves as our mechanics, we’ll need to iron out these bugs at some point. However, that’s not necessary yet to prove out the concepts, so we can endure some weirdness until then.

Next week - I’m thinking that we’ve been on the script thing for two weeks, so I’m thinking we’ll actually do some exploratory map design for the Mezzanine. This way we can create some basic environmental layouts and I can go over some of the constraints and considerations we’ll need to consider when crafting such a space. Unless you all really really really want to see me get Slow Fall working next week? Let me know either way through the usual means

This week we continue the Design Phase of the FANTa Project!

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent questions: The FAQ