#fanta project

I’ve started building FANTa on Unreal, doing some basic setup. We’ll be building on the foundation we lay here in the coming weeks and months. I’m still looking for a repository big enough to handle the FANTa file sizes. I’ll think of something. I’m also trying to strike a careful balance between doing specific things and being more general for speed and brevity’s sake. If you want to follow along in the meantime, here are the steps to get to where I currently am.

EDIT: Forgot to mention - you’ll need a C++ editor and compiler for this. I suggest Microsoft Visual Studio 2019 Community Edition. [Get it from Microsoft for free]. If you really don’t like Visual Studio, there’s some additional information on [setting up a different IDE here]. Remember, you can always compile your C++ code by hitting the Compile button in the editor.

We’ll start by creating a new Unreal 4.24.2 project. Under Games, choose the Third Person template, then select C++ instead of Blueprint. We’ll still be doing most of the work in blueprints, but we need C++ in order to work in the Gameplay Ability System that we’ll be using for the traversal mechanics and such, like so:

(I’ve already created a FANTa project, which is why it says it already exists)

Optionally, you can then go to the Unreal Marketplace and add a Paragon character to your FANTa project. The AAGD Patreon Dev Team voted in Terra for our player character model, so that’s who I am using.

After you’ve gotten the project created, you need to set up the basic Gameplay Ability System in C++. [Click here for the instructions to do so]. Make sure you have the Gameplay Abilities Plugin enabled, and make the core changes to FANTaCharacter.cpp and .h. You really only need to make the changes up until the Binding to Character Input section.  Find the ThirdPersonCharacter Blueprint and you should see the AbilitySystem inherited after making and compiling the C++ changes. Like this:

We’ll rename ThirdPersonCharacter to PlayerCharacter, since that’s probably a more accurate name for it.

For fun, we can also change the blueprint’s Skeletal Mesh to Terra (or whoever you decided to choose) and the Animation Blueprint to Terra_AnimBlueprint (use the dropdown menu to choose) and it should swap the mannequin for our big beefy axe lady. Compile and save everything.

Now we need a Gameplay Ability to give to the player character. Let’s start by creating a Blueprint which inherits from Gameplay Ability like so:

Name the GameplayAbility blueprint something like DebugTestAbility and open it up. We just want something for us to make sure it is being activated properly. Event ActivateAbility should just call PrintString with some message to indicate that the ability has been activated, like this:

Next, we need to add a little bit more code. We want to add a way to grant abilities to a FANTa Character and we want it callable via Blueprints, so I wrote this bit in FANTaCharacter.h under public:

UFUNCTION(BlueprintCallable, Category = "Abilities") void GiveAbility(TSubclassOf<class UGameplayAbility> AbilityToGive);

This declares a new class function called GiveAbility that is callable by blueprint that takes a Gameplay Ability subclass as a parameter. Then, in FANTaCharacter.cpp, we define the function as so:

void AFANTaCharacter::GiveAbility(TSubclassOf<class UGameplayAbility> AbilityToGive) {    if (AbilityToGive)    {    AbilitySystem->GiveAbility(FGameplayAbilitySpec(AbilityToGive.GetDefaultObject(), 1, 0));   } }

This means that we can call GiveAbility from any blueprint that inherits from FANTaCharacter with a class definition for an ability and it will give that ability to that FANTaCharacter. Build it and it should be good.

Now, we need some way to make sure that this ability has a tag so we can activate it by that tag. In the Details of DebugTestAbility, edit the Ability Tag and add a new tag Debug.Test.DebugTestAbility to identify this ability in specific.

This should be enough to set up our debug test ability.

Now we have to give this ability to the player character. Go back to the PlayerCharacter blueprint and create a new variable called StartingAbility. The variable type will be Gameplay Ability Class (not object). Then, in Event BeginPlay on PlayerCharacter, give that ability to the player character like so:

You also need to set a class default for this ability - use the dropdown menu and choose DebugTestAbility for StartingAbility. This should be enough to give the debug test ability to the player character.

Finally, we need to put in a way to actually activate the ability. Open up your Project Settings and go to Input. Add a new action mapping and call it UseAbility1. Assign it to something. In this case, I’ve I’ve assigned it to a gamepad button.

Now... in the PlayerCharacter blueprint, we’ll put in a quick test function for this. Add a new Event InputAction UseAbility1, and for “Pressed” you can put a printstring (to make sure the input is being registered), followed by TryActivateAbilitiesByTag. The Target should be the inherited Ability System Component. Then you just need an array of gameplay tag containers. We do that by doing MakeLocalGameplayTag (choosing the tag we added above - Debug.Test.DebugTestAbility), MakeArray on it, then MakeGameplayTagContainerFromArray, and feeding that into the GameplayTagContainer input field on TryActivateAbilitiesByTag.

Compile your blueprints and run. You should be able to move around and pressing the UseAbility1 button should print a string to the screen that matches what we set in DebugTestAbility.

Congratulations everybody, FANTa has begun (again). We’ve set up our character and our gameplay ability system with one working ability! Future posts will be a little less in the nitty gritty as we become more familiar with the UE interface and I’ll focus more on the principles of what we’re doing rather than the exact details of the implementation. If you’re having trouble getting set up or following, please ask in #fanta-discussion on our discord server! I also want to thank all of our patrons on Patreon for helping to make this possible. We really appreciate your support.

[Join us on Discord] and/or [Support us on Patreon]

We’ve started the FANTa project in Unreal. [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

It’s been a while, but that’s primarily because of the larger scope of this particular update. We asked our patrons what we should do, and they voted to add a fair amount of functionality to the Gameplay Ability System that we set up in the last update. 

The things we’re looking to do this time around are:

Keep track of what abilities a character’s active Abilities are

Create a way for us to determine the targets so one ability can hit multiple other actors (e.g. PBAOE, self-buff, etc.)

Add the ability to play an animation and wait for a specific game event triggered during that animation

This will enable us to do things like basic combat, spells like a fireball, and also things like self-buffs (e.g. giving the player the ability to jump higher or heal). This code is primarily adapting from [Epic’s free Action RPG resource]. Action RPG is a learning resource that’s very helpful, but we can’t just directly copy and paste code and blueprints; there’s a lot of dependencies there that exist under the hood. We need to bring over some of their stuff to FANTa, and that’s going to require some additional code work.

Fair warning - due to the scope of code changes, I’m going to be simplifying some of the description of what’s being done. I’ll make the code repository available via [google drive here] if you want to get it. If you do get this code, you’ll need to re-generate your C++ files by double clicking the FANTa unreal engine project file after getting the code into the appropriate places. This may end up overwriting some of your other code changes (especially if you’ve done anything else to your version of FANTa in the meantime). So let’s go to it, shall we?

#1: Create our own FANTaAbilitySystemComponent

Reference file: Abilities/FANTaAbilitySystemComponent

We’re creating a new FANTaAbilitySystemComponent that inherits from AbilitySystemComponent. It does all the same stuff as the base AbilitySystemComponent, but also has some additional functionality. Specifically, we want to add a function called GetActiveAbilitiesWithTags which will return a container of ActiveAbilities that match the gameplay tags being passed in, a function to get the Default Ability Level (for abilities that have more than one level), and a static function to get the FANTaAbilitySystemComponent from a specific actor if it exists.

In addition to this new component, we also need to change the AbilitySystem variable in FANTaCharacter to be of FANTaAbilitySystemComponent type instead of the old AbilitySystemComponent type. This will be necessary later, when our montage ability task tries to get the appropriate ability component from the player.

#2: Create our Targeter

Reference File: FANTaTargetType

We’re creating a new UObject here called a FANTaTargetType which will function as a target-getter. It will run some logic that will return a list of valid targets. We can use the base functionality to create sub-targeters like a circular AOE, a character-based AOE, a self-buff, and so on. It’s important to make this Blueprintable so that we can make blueprints that derive from this class. We also created two subclasses of this - TargetType_UseOwner (for abilities that target oneself) and TargetType_UseEventData if there’s already targets defined in the Gameplay Event Data.

#3: Create our Gameplay Effect Containers

Reference file: FANTaAbilityTypes

We’re also creating a set of structs. This will be a little odd since we’re not actually able to do this via the editor (since we’re not creating a new C++ class), but you can get Unreal Engine to do it for you anyway by having it #include “HeaderName.generated.h” and it will still do it for you after you re-generate your C++ project files. Specifically, what we’re doing here is creating two structs that will keep track of a Targeter and a batch of associated Gameplay Effects. The first struct takes a specific targeter and a list of Gameplay Effects to apply. The second is generated when we instantiate the first and keeps track of all of the effects and targets (and also has the ability to add additional targets). This is necessary for the next step we’re doing, which is to create our own FANTa Gameplay Ability base class.

#4: Create our own FANTa Gameplay Ability base class

Reference file: Abilities/FANTaGameplayAbility

This is the crux of what we’re doing. We’re making our own Gameplay Ability that has several blueprint callable functions, specifically in relation to the effect containers we did in #3. Our gameplay ability will be able to take a container or a container spec (i.e. targeter and effect data) and then apply those effects to the targets specified by the targeter. These are all Blueprint callable so that we can create subclasses of the FANTaGameplayAbility and use this functionality.

#5. Create a Gameplay Ability Task that plays a montage and listens for gameplay events 

Reference file: Abilities/FANTaTask_AnimMontage_WaitEvent

The animations we’ll be using from blueprints are called Montages. We create an Ability Task - that’s a Gameplay Ability-specific subroutine that runs asynchronously from the Ability and then can call Delegates when events happen inside. What our code will do is create a new Blueprint function called Play Montage and Wait for Event that we can call from within our FANTa Gameplay Ability. This will allow us to play an animation montage and then, when certain things happen like a specific keyframe is hit, we’ll notify the ability and do something cool (like cause an explosion, heal the player, spawn a projectile, or play a particle effect).

Woof, that’s a lot of ground to cover if you want to follow along. Thankfully, even if you don’t know your C++ super well, you can probably unzip the source into the folder by overwriting everything, re-generate your C++ project files by double clicking the FANTa Unreal Engine Project File, and be able to compile and run ok. If you’re having trouble following along, please visit our [discord server] and post in the #fanta-discussion channel. Next time we’ll put together an ability in blueprints using this new tech. 

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [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

Today you get the TLDR first! Two main points:

The FANTa project is returning and being rebooted

AAGD is starting a [Patreon account] with @axl99

I’ve been thinking about this for a long time because I don’t like leaving the FANTa project where it is any more than most of you probably do. Every time I look back at it, I try to think about what it is I can do about it, and I think I’ve come to a conclusion - I honestly don’t know enough about the Skyrim creation kit to do what I set out to do. Part of this is that Skyrim’s asset library just doesn’t have the kinds of assets I need to build the original FANTa concept (a castle in the sky), nor is it good about changing the size of objects (as far as I can tell). This was the original issue I ran into when I started the FANTa project, and the combination of these factors along with the increased workload at the office ground FANTa to a halt. FANTa is a lot bigger than just answering questions. I know the answers to most of the questions I respond to, or they require minimal research on my part. Each part of FANTa really requires a significant time investment. I just didn’t have the time to do my own life stuff in addition to my workload and the FANTa project.

What can I do about this? Well, I was faced with two options - try to force it and make it fit or look for something else that I can use to fulfill the original FANTa idea - an intermediate-level follow-along project. I’ve given it a lot of thought and I believe that the second option is the correct one. So the real question here is “what sort of toolset can we use to do everything we want to do?” Let’s review the core gameplay and constraints:

The theme is Castle in the Sky

There should be some means of the player acquiring and activating 1-3 abilities to navigate and interact with the environment

We are limited by our inability to create new assets specifically for the FANTa project

Thinking about this, I’ve come to a realization. There’s one platform out there that is free, should be able to handle all of the core gameplay we’ve laid out, and has a lot of (free) asset support. So yeah… we’ll be moving from the Skyrim Creation Kit to the Unreal Engine. Unreal should be able to handle all of the things we want to do, and I’ve spent a good amount of time over the past few months learning to use it. There will, of course, be a few logistical issues that need to be solved like:

Unreal projects tend to be much bigger on disk than Skyrim mods

Using some of the Unreal features I wanted to do will require some programming knowledge. We’ll try to stick to Blueprints as much as possible, but there’s some places where C++ will be unavoidable

Some of the free assets might be time-limited from the Epic store.

A new FANTa post each week might be too much. I probably need to take a more careful look at the post/update schedule for it.

However, I think that this is probably the best move for the FANTa project overall. I look forward to resurrecting the FANTa project and hope you all are still interested.

There’s one more thing and this is kind of a big one. I’ve been thinking about this for a long time as well. I’ve been writing and maintaining this blog for a long time - over six years now, and over that time I’ve always just done it for fun. My friends have told me to compile the posts into an e-book and put it up for sale, or monetize the blog in some way. I’ve certainly put a lot of time into this and they feel I should be compensated for it somehow. Part of this is also trying to maintain my anonymity while somehow being compensated. Overall, I think I’ve figured something out. What I’ve decided to do is partner with the inestimable @axl99 to run a [joint patreon account]. I really need a better development machine at home, especially if I need to compile shaders and things for an Unreal project, so… I’ve got my hat in hand, if you are feeling generous and would like to support me, axl99, or both, we’d greatly appreciate it.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted.

[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

Hey everybody, today is a quick update on the current status of the resurrected FANTa project and how things will proceed from here.

First, if you want to follow along the actual FANTa development, go [install Unreal Engine 4.24]. Get it working on your computer, maybe play around with it a little bit. It’s a pretty hefty download, around 11 gigabytes if memory serves. Game dev is not cheap when it comes to disk space. [Remember, this is the absolute minimum bar to get started with game dev]. If you just want to play the FANTa project without any of the dev stuff, I’ll (eventually) post a repository for the various builds of the game as they come online. If you know of any places that can host multiple gigs of data, please let me know.

Second, this is how future FANTa posts are going to be laid out: I’m primarily going to write conceptually about choices I’m making in the project. I’m not going into the nitty gritty details for getting specific things up and running unless it’s FANTa-specific. For example, I’m going to be using Epic’s Gameplay Ability System, but I won’t go into integrating the necessary C++ code into into the project. Instead of writing all of the basic tutorial information myself, I’ll try to link to a relevant tutorial on the web somewhere that gets into those specific details. If you have a hard time following the project from update to update, [join us on Discord] and visit the #fanta-discussion channel where you’ll be able to discuss the specifics in detail. 

Finally, we need to choose a player character model for FANTa. We’re going to be using Unreal Marketplace free assets, so the easiest way of doing this is to pick a supported character from Paragon to use as our player character. There’s a lot of them to choose from! You can take a look at the various models available by [clicking here]. 

Patreon Patrons will be able to vote to decide which character we use for FANTa

[Not a patreon member? Become a patron!] We’ll also need to make other high level decisions later on, which will also be decided by future patron votes.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [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

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

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

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

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