DevLog - Post 01

Totem Towers  

Our group had (in our opinion) great ideas for games. We liked the ideas so much, that we ended up Frankensteining ourselves a combination of most of the ideas to a new Idea. We did so not because we wanted to appease everyone but to make the best possible game we could come up with. Loic had the idea to have a map with a totem in the center, in a jungle theme that after a level is completed would crash down and bring us to the next level by falling down to it.

Michael and Nakisa had similar ideas about arena brawler fighting style games.

Michaels idea focused on fighting against each other and creating traps and using different kind of weapons against each other. Nakisas idea focused on fighting until at the end, one player would become a boss type unit and the other players would have to play together to fight against that player.  

And that is how we got our game idea. We all liked the idea and were excited to work on it. Nakisa created a very simple prototype after the first week to showcase a fighting system of everyone vs everyone. However that prototype was very simplistic and not nessesarily very fun.

In the second week, after getting the feedback that a fighting game would be very difficult, we decided to make a variety of prototypes and decide before our meeting with our leads in the following week, which game we will make. We came up with an alternative idea. A platformer with a similar setting. A totem center piece which would be built similar to a spiral staircase which we had to run up. First to reach the goal or last alive wins the game.

We decided that Michael would make a platformer prototype in Unity, Silke would make a fighting game in Unreal and Nakisa would extent the fighting game he already started in Unity.

What have we learned from the prototypes:

Unreal (by Silke):

When starting with Unreal, I had a hard time figuring out where to find certain functions. As I am used to working with the blueprints, I know there are certain functions that I can use. While trying to implement similar things in C++ Unreal, I had to look up the functions I wanted to use to find what header files I needed to include. After working for a bit now, it does get easier after a while when you know what to include for some functions. 

To add multiple controllers, Unreal has some useful functionality (CreatePlayer function), though I did run into some problems. I tried to create a player controller for each player, while there is already one player controller created automatically when the game starts. I fixed this pretty easily when I figured out what was going on.

The second problem I ran into, was that there was no collision happening for my players. I created a new component for my players that checked for collision when moving. Then I set my player mesh as the root component and updated this in the movement component. This last step solved the problem, as I was not moving the player mesh before.

Finally, I also added a double jump to my player movement by adding an impulse on my player. I first tried moving the player upwards a bit every frame, but then I found that adding an impulse was a more convenient way to add a jump force to my players.

Most of the problems I ran into with Unreal Engine up until now were because I often had to search for where certain functions were located and what exactly Unreal calculated for me already or not. Of course, these problems will go away quickly after working in Unreal some more and getting used to everything. A disadvantage of Unreal is that you have to wait quite some time when creating new classes or when building your project. But there are also a lot of advantages of using Unreal. For example, it was really simple to add physics to my game (gravity, …), Unreal also has a lot of classes that you can build further on to add input to a player and so on.

Unity prototype pvp (by Nakisa):

What was bad about the first prototype?

Thats the first question I asked myself when I sat down to start with the new prototype.

The answer, everything!!

Well, to be honest there was not a lot to begin with.
The camera was static, the attacks were instant, the movement was very direct.
With all these things in mind, I made myself a todo list and went about attacking these three main points.

For the camera I wanted to make sure that any player would be seen at any time, but we would not see unnessesary parts of the map. So I created a camera that centers in the middle of the players and zooms in and out depending on how far apart the players are from another.

Next was the movement. I didnt like the direct press left go left input. I wanted even the decision of movement to have some sort of impact.
So I entered rotation and movement penalties to attacking and rotating.

I also reworked the jumping and dashing. The dashing was just balanced in terms of force and cooldown. For jumping I added some downwards drag so the jump felt like an actual jump when you go down and not like you are playing "Mary Poppins Y'all".

After being somewhat satisfied with the movement the fighting mechanic was the next target.
I started by coming up with the attack cycle. When you press attack, the "Animation" begins, but it does not deal any damage yet. The next part of the cycle is the damage dealing part in which you will damage another player if they are inside your attack range. And last the animation outro time, so there is a part for the animation to end and the character to go back to its idle animation.
Next I added knockback and stun to the attacking and damage receiving so there were consequences other than taking damage to getting hit. And last I made the heavy and light attack.
My goal was to make the fighting mechanic feel somewhat natural and intuitive.
Heavy attack:

Light attack:

After a ton of playtesting (shout out to my room mate for testing with me five times an evening!) I was satisfied (for the time being).

However the game still felt somewhat empty. Which made sense, since none of the planned mechanics outside of fighting were in the prototype.
So I spent some time implementing the totem in the center of the map, which can:
Spawn heal Cubes, that can be picked up and despawn after a while


Spit fire, which deals damage and stuns players that get hit

After that, I also added traps. These traps are per default deactivated. They get activated by a player running through them.
The next player that walks through them takes damage as is stunned.

Lastly, I added the win condition. Which is that each player needs a crystal, which they can lose to other players and win the round if they get all the crystals there are.

When entering the next level I also added the falling down part, which is how we transition from one stage to another.
Lastly I added some minor quality of life and build supports, which include a selection for how many players are playing (2-6), a menu with which you can select the player amount and close the game, as well as a win screen.
All minor things that look so ugly, I almost forgot to mention them ;)

Problems, Conclusions, Solutions:

The main problem for me was testing and balancing. To make it feel good is my main goal in this project and this prototype.
For that purpose I am very gratefull that I have several people around me that were allways willing to pick up the controller and play a little with me and give me some honest feedback. Through that I feel like the prototype I have made currently is satisfactory and shows that the game can be pleasing and fun to play in the end.
However it is allways annoying to have to wait for someone to be there for me to be able to test the game with, which is of course not allways possible. Through that there can be some down times in which I cannot test new aspects of the game.

Other than that, ego and "great ideas" are of course a problem for any person and me especially.
I am glad that I have learned to not feel attacked by honest feedback but embrace it and improve my game through that.
But it can still take some time for me to realise that I am going down a path to a dead end instead of just switching my idea and outlook.

But I have been becoming better and better about that throughout the years and I will get better yet (I hope :P), so I am looking forward to anyone telling me I am doing things badly, so I can improve them.

After all, sucking at something is the first step of getting good at something. And any extended version of that sentence.

Unity prototype platformer (by Michael):

I found that through Unity’s component system and easy to use workflow I was quickly able to create a character. I ditched the old input system and implemented the new input system which is a lot cleaner to use and faster to create. The new input system allowed me to easily spawn players and to detect controllers that are plugged in. This was an issue in the previous input system that controller wouldn’t always correctly be detected or their ID changed without us knowing.

After quickly creating a basic totem with platform that rotate around it and slowly drop, I noticed that when a player stands on a platform the player does not move together with it which is quit annoying since this is a pretty big part of my gameplay. After some time I managed to rotate the player relative around the totem when he/she is on a platform.

Unity's default implementation

My implementation

 My platform rotates around its own pivot (at 0, 0, 0) so this means my platforms only rotate and don’t move. If for some reason I would later on add a platform that actually moves I would need a new implementation of that and a way of detecting this. Although these problems are still easy to fix Unity might not be the best option in regard to a platformer but nothing is stopping is to create an own implementation. 

Conclusion:

After the feedback we got last week, we asked ourselves if the fighting style game was realistic to develop or if we should go in another direction. So we started discussing and came up with another idea: a platformer game.  After playtesting, we decided that the fighting game was the most fun to play. The variety of the different mechanics added onto the fun the main mechanic already gave.

The next question for us was how we wanted to extend the gameplay. We had multiple ideas:

• More interactive traps
• Hidden traps
• Totem could release insects or different types of beams
• Weapons
• Different types of pickups
• Usable items
• ...

We made  a semi-isometric front view camera that zooms in and out depending on how far the players are from each other. We picked this camera view as it gave the best overview of the game. And it always kept all the players in sight. It shows what is needed, but not more.

The most important question right now is how we are going to implement the fighting mechanics.  Currently the fighting game is purely collision and timing based, so when you attack, there is a time it starts the attack, a time it deals damage and where it ends the attack. We want to look if we can extend this system to a more dynamically based system that would be based on lowpoly meshes and simple keyframe animations. That way we could add a more physics-based feedback and might have better playerfeedback as to where and when a player hits another. 

For the movement, we still want to try different approaches. Currently it is translation-based. So we would like to make it physics-based and try different ways of directional input. (look in movement direction, look with different joystick, ...)

Plans for next week:

Extend the prototypes to test more of the gameplay, test some game mechanics.