The Story So Far

Briefly going over The Future Project’s development history.

stock_book.jpg

Infinite Level game discussed: The Future Project

In the last dev blog post, I talked about the inspirations behind The Future Project. You can hash out every detail of your game idea if you like, but until you open up an editor and actually create the idea sitting in your head, it’ll just be an idea. The Future Project began its development in the fall of 2018, shortly after development of Impressions had begun. Why work on two games at once? There are multiple reasons, but the biggest one is that I wanted to have a simple, small project to work on while working on a larger game, this way I can still put out new games at a reasonable rate. As I do with all games I make, the early stages involve simply creating the basic mechanics of the game. The Future Project is an interesting case because there were so many directions to take the player’s abilities. I recall coming up with three designs for the player, two of which focused on a specific philosophy in their moveset, with the third being something in-between. There was the “Environment” character, and the “Arsenal” player. The “Arsenal” design focused on giving the player a large arsenal of weapons, including energy swords, homing missiles, and various guns. Of course, these weapons would be the keys to unlocking doors. Meanwhile, the “Environment” design was focused more around using new abilities to manipulate the environment around the player, such as melting ice or charging a door. In the end, I felt that the “Environment” design would better fit the ambitions I had for the game.

Unlike the other designs, this one only gave the player two primary weapons, the basic gun and Missile Launcher. Anything else was in service to the idea that the player could use their additional abilities to affect enemies and the world. With that in mind, development began proper. The player’s movement was the first to be worked on, and this took a while to get right. Heck, I tweak it now and again to this day. Constantly tweaking such a basic system may sound unnecessary, but it’s actually very important. In game design, developers often break a game down into the minimum viable product. The famous example is with Super Mario 64, where it’s reported that the developers spent a year of the game’s development just getting the movement as good as possible. Why would they do that? Because, if you strip away all the levels, enemies, power-ups, and all the other parts of the game, all you have left is a character that moves. Since Super Mario 64 is a platformer, the players will be spending 100% of their time running and jumping, so the developers made sure that this part was as close to perfect as they could get. The idea was that they should you should be able to have fun with the game even with the most basic set of mechanics. From there, everything else could be built on top of that solid foundation.

 
Sorry, gotta censor the spoilers.

Sorry, gotta censor the spoilers.

 

Knowing this, it makes sense then why I would continue to spend time adjusting the game’s movement. But once I had it about where I wanted it initially, it was time to build everything else on top of that. So next came the player’s basic gun and missile launcher, along with all the tweaking that has since come with those mechanics. The basic gun is simple enough, just fire the basic projectile whenever the player presses the fire button, and allow them to hold it down for rapid fire. From there, just make sure the timing between shots is good. Weapon number two, the missile launcher, went through a similar process, but with the addition of making sure the missile had enough “oomph” to it. It is, after all, a much more powerful weapon, so it’s got to feel more powerful too. Next came the player’s elemental abilities, which would allow the player to open new paths, inflict statuses on enemies, and interact directly with the world around them in a way that aids the gameplay. So, the player should be able to use their ice element to create an ice block on a body of water. Or, they should see a patch of oil on the ground and light it up with fire.

Now, this doesn’t necessarily mean you can do everything. I’m not about to become one of those AAA marketing types that say “you can do anything”. You can’t. Like any good game, there are rules and limitations. As a developer, I have to lay down those rules, and then make a game that allows the player to do cool stuff without necessarily breaking the rules. Limitations are often seen as a bad thing, but they can actually be quite useful in finding the fun. It was during the element development phase that the game’s rules were properly laid out. Once that’s done, I was then able to get started on level design. Level design is very important to me, as I enjoy playing games where the world is built around the player character’s abilities. If I don’t like a game, I can often trace it back to level design not utilizing the player character’s moveset. This is often the problem I have with most open world games. I’ve long held the belief that you could replace most open worlds with a flat square and the gameplay would change very little, if at all. For me, they’re just boring to navigate. Obviously, I want to avoid that being said about The Future Project as much as possible, so when designing the maps, I make sure that a player can use their different abilities at many different points to open up the world, find items, or even just navigate a room more effectively.

FP alpha1.jpg

Distant Sibling, the area seen in the gameplay video, was the first area to get its map laid out. So, now it was time to create a new map and start creating the world described in my map document. It’s at this stage where I can see any flaws in my design, such as a player soft locking the game or rooms that don’t have a good layout. Once the level is made, I then work on making enemies for this world. At this point in the game’s development, I just made four basic enemy types and adjusted their properties as the design specified. During this time, all the enemies are basically tofu blocks with extra objects mounted to them as needed. For that matter, everything has a “default” look to it. The maps are made up of cubes, enemies are blocks, and Unreal Engine’s default gun model is still being used. Making the game look pretty would come at a later date. Of course, while I’m placing all those, rigorous playstesting is in place both to look for new bugs and issues as well as make sure the level design works. And, I have a confession to make here…for a while, the level design didn’t work. It was too flat, with very little geometry, and did not adequately encourage the use of player abilities. It was like one of those open worlds I was just complaining about. I made three of the game’s worlds before it fully settled in. Sometimes, you work on something long enough and you get used to things being wrong. It becomes a problem that you need to recognize sooner rather than later.

The present seemed like the best time to address the issue, so I took the next few months revamping the levels to involve more platforming and create a stronger reliance on player abilities. The second major area of the game in particular benefited from this, as before it was just a long series of tunnels, a more open but flat area, and a short mountain. The platforming helped create obstacles that the player had to get past. Furthermore, around this time I discovered in one area that you can get by reasonably well without certain powers, but those segments would just be harder. Rather than force the player down a certain path, I instead opted to allow the option to pick and choose from two or three main paths, with the abilities acquired from them making a previous area easier to deal with. So if, for instance, you struggle with platforming across large gaps, you can try the other path and gain an ability for that. I don't remember how long this took, but it certain took a large chunk of time. Probably at least a few months.

Once all this got ironed out, it was back to designing the remaining areas and blocking them out. As of now, there's only one that doesn't have any enemies placed yet, but at this stage I'm saving it for a later date. For now, my focus is on polishing up the first two major areas and finishing any assets they need. Speaking of assets, at some point I felt it was finally time to learn some 3D modeling and get to making my own assets. I started by using my smaller project as a practice area, while The Future Project could have other work done to it. It took several months for me to get comfortable enough with Blender to start creating assets for my games, but the time spent practicing has been worth it. Once I was ready, I set out to “visualize” Distant Sibling. This meant placing foliage, laying a proper landscape with textures, and other decorative items. This was also the time when I started tweaking the game's lighting more, using a system within Unreal Engine known as Sky Atmospheres.

And boy, was that a process. Between creating the player assets, as well as visualizing the landscape and enemies of Distant Sibling, I was at this for about seven months. Some of that time had gone to learning character modeling so I can make the game's enemies. Most of this year has gone towards polishing this single area. However, the good news is, much of the work will transfer over to later worlds, such as the player UI and gun models. After all, you only have to make those once. So, the other maps shouldn't take up quite as much time. Looking at all this, I'm starting to see why the game has taken as much time as it has to make. I spent a lot of time just getting the game's fundamentals ready, followed by a lot of time designing maps, then blocking out those maps in the level editor. Then I revamped those maps to make them more interesting, followed by learning 3D modeling, then making those models. After that, it came time to put all these skills (and some others that came later – hello animation blueprints) to bring you the screenshots and gameplay video we have now.

 
gameplay_screen4.jpg
 

What's kind of crazy is that the part of the game shown off is just one area, and it's only a few minutes! There's more to Distant Sibling than I showed, not to mention the other worlds you'll be able to explore. And, in case I've not made it clear, I'm a solo dev. To all my fellow indie developers out there, my advice to you at this stage is to be very careful if you make a big, ambitious project like this one. I believe the reason I've been able to put this all together so far is because of the past experience I've gained working on other games. Even before War Ender, I had tried making a large game that, unfortunately, fell flat on its face. That game was canceled, and a lot of lessons were learned from it. Those lessons are now being applied to The Future Project years later. Perhaps one day I'll go over what happened...but for now, I think this is a good place to wrap up. That's the entire Future Project development timeline, summarized in a few paragraphs. I bet there's all kinds of stories I could add to this if I wanted to. But I better restrain myself, for both your sake as well as mine.


Until next time!

-Lance T.

Previous
Previous

The Jeweled Tundra

Next
Next

Origins of The Future Project