Posted February 27, 2020 by silkenemegeer
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.
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:
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.