Being now in the fourth week of development for the game projects, we have fully well entered the first phase of production, which will last us an entire 3 weeks, after which we will have another production sprint, finishing up with a shorter polish sprint in which no features will be added, only presented better and given that extra care that should make it shine.

Introduction

Our first major step was to redefine some of our gameplay ideas using the lessons we learned from the prototyping phase. One of our more important decisions was to still keep the entire aspect of having our hovering power source connect the alien players together while reducing how punishing the system would sometimes be by removing the ability to even be disconnected in the first place. The maximum movement speed and the power of the player's vaporiser gun would be affected, depending on their distance to the power source. This would be visually indicated by a light on top of each player's head dimming or brightening.

A lot of time was also first spent on planning and setting up an environment in which we could contribute to the project at the same time without having Unreal or Perforce getting in the way. For example:

Using permanently streamed levels linked to a main level, we can work on different parts of our main map without stomping on each other's feet with having files locked out from each other. This system can also be extended to include a streamed level consisting of lighting, particles and so on...

Finally, a decision we had to take this week was the one to switch back to Unreal 4.23.1 instead of using 4.24.3. It turns out that this latest version caused some unexpected issues which did not exist on 4.23.1, and as we have no need for any of the new features, we have officially reverted back.

Art & Design

Since we aren't making prototypes anymore, it is time for us to make assets which more or less aim for the final quality we're expecting out of ourselves. Of course, we still have the polish sprint to push the art even further, but now is the time for us to make stuff with the consideration that it might actually be in the final product.

Here are some preview images:

Objects

UFO

We started of by tackling some of the most important meshes first: guns, collectibles and the UFO.

These were all assets that required a Substance Painter pass as they would get a lot of screentime. Once these assets are all finished, we can really start 'mass-producing' modular meshes as the pipeline for those goes a lot quicker.

The texturing in Painter allowed us to quickly add in some subtle details, but it might be nice to add some custom texture maps to create more of a stylized wear and tear feel.

The UFO will see some more variations in the (near) future,  as we'll have to add some compartiments to store the collected batteries and fuel. Once we're getting into the rigging process of this asset, we should also add a door/staircase for the aliens to access their ship.

Level

This week we started on creating the first draft of the level as well. We figured starting off with the central room, where they keep the UFO, would be the best idea, as we can just expand from there on out. We really want to focus on keeping everything as modular as possible, every mesh we create to populate this room, should be reusable everywhere else. With the main features being defined, we can really focus on fleshing this area out, trying to ballance gameplay and playspace with the actual looks of the level, it should look good, but should most importantly be fun. 

Programming

As we are now in the first production sprint, we cannot afford to make throw-away code solely meant to contribute to the ideation process anymore. We're aiming for a sound code base, which any new programmer to our team could easily jump into and start working as fast as possible.

We've been thinking a lot about how classes should interact, whether we should aim for inheritance, components or interfaces depending on the situation (while always keeping in mind that composition is preferred over inheritance, of course!), and which parts of the Unreal engine code we can already take advantage of.

Here are some results for this week:

GameMode and GameState

In the Unreal gameplay framework, a distinction is made between these two classes. The gamemode is usually what holds the logic behind the rules of the game and how it plays out (decreasing the global time available to players, switching states...), and gamestate holds the data related to the gamemode being played right now (number of players, time left, amount of collected objectives...). In onlines games, only gamestate is replicated to players as far as we know, it does not really concern us as we're aiming for a local multiplayer experience but it's always interesting to keep doors open.

In our case, the gamemode also takes care of setting up the play session: for example, spawning players together at a random location at the start of the game. Unfortunately, there are a lot of considerations you need to take into account to do something like that (which aren't necessarily very obvious at all) or, more often than not, you will end up having your players spawn in unexpected locations, or not spawn at all in the first place. Sometimes, more obscure problems can occur such as the players appearing in the Editor, but not in a Build version.

Our conclusion was that we absolutely needed to have all our player starts already placed in the level. (it is not reliable to spawn new ones in when initialising the game) Then, they can be linked to a player spawn group entity keeping track of linked player starts and simply removing all but one player spawn group (and their links) at the start of the game, before any player is initialised. This gives us the expected result.

The player spawn group in the middle is linked to the 4 surrounding player starts and is fully aware of them.

AI

Despite unfortunate bugs occuring such as blueprints not recompiling properly, leading to them using callback functions different from the ones we actually intended, the basis for AI has been set up.

A solution we tried looking into was the "CompileAllBlueprints" option but the only thing that helped in the end was recreating the blueprint derived from our C++ class from scratch, which isn't too re-assuring for the future to say the least... The C++ class used the proper callback while the blueprint somehow "remembered" the name of the old callback function and tried using it (we could see this in the debugger), which resulted in many hours of pure confusion. Feel free to mention anything about it in the comments section.

Using C++, it is possible to set players and enemies in different AI teams, and they will properly react to stimuli sources according to affiliation. The main idea is to use the IGenericTeamAgentInterface interface provided by Unreal, and override things as you see fit. As such, our enemies are able to see players correctly, even though the reaction hasn't been programmed in yet.

We have implemented roaming back and upgraded our node system:

It is now possible for nodes to randomly lead to any number of possible next nodes, which should help in avoiding having the AI be too mechanical. It should be defeatable of course but still unpredictable enough to keep players on their toes even after multiple rounds. This system could easily be extended to provide weights to each next possible node too. This system is also very easy to use for level designers as guards simply pick the closest node to start roaming at the begnning of the game, and then follow the selected nodes.

Camera

Our camera remains mostly the same from its prototyping version, but has had some improvements as well. You are now able to set the maximum/minimum inner and outer coordinates differently:

You can basically imagine it to be something like the following:

When all players are within the inner area, the camera is allowed to zoom in. If some are within the inner area but others in-between the inner and outer, the camera will keep its current arm length. If any players are outside of the outer area, the camera will increase its arm length as required to keep everybody visible. It also takes advantage of our player group spawn system, as it simply spawns in the middle of the players when initialising the game.

Power Source

Even though the basis is set up, most of this gameplay feature remains to be made but we thought we'd share one last tidbit concerning an improvement we've made to the power source entity over our prototyping phase. It is now able to hover above the ground properly:

You can also see some AI roaming around, in addition to the power source detecting nearby pickups using our custom object collision channels! Our gamemode is also in action, as you can see the amount of time left in the top left corner is decreasing while playing.

Using a combination of raycasts, forces, linear damping and angular damping, it is posible to have this pretty neat effect. Since this is all affected by mass, it will have to be re-adjusted for the real model we will use but this shouldn't take longer than a few minutes as all the parameters discussed can be changed in real time. (mass itself can be modified in Unreal)

Conclusion

If you wish to take a look, a build of what we have so far is available right here. For the coming week, we will continue adding more features on top of the current ones in order to build our final game. We will most likely look into completing the power source entity, making the collection of UFO parts work and count towards the victory condition that is already set up in our gamemode, adding more to the AI, completing health systems and so on...

In the hopes that you liked this week's devlog, look forward to the next one!