Devlog 1 - Let the prototyping begin!

Hi everyone and welcome to our Devlog!

We are Group 7 in our class “Game Projects”. Our big assignment this semester is to make a couch co-op game, all the way from brainstorming, through prototyping, and to end with a finished game that should be a lot of fun to play.

So we came up with the idea of Goblin Wars, which is a couch co-op game in which you play as 4 goblins who are at war with the gnomes. Together with your friends you have to guide your big siege weapon to an enemy encampment, in order to take it over and win the war!

Before we started working on this idea, we had a couple of questions that we had to keep in mind when moving into the prototyping stage, in which we are currently. We will talk about these in this devlog!

What engine are we going to use?

So there are two engines we had the option to choose from: Unity and Unreal Engine. We’ve discussed this with our team and we have decided upon using Unity for our project. The reasoning behind this was that, while Unreal gives us much nicer looking graphics, the programmers of our team are much more familiar with the C# scripting in Unity as opposed to the C++ in Unreal engine. We decided that for a couch co-op game smooth gameplay is much more important than nice-looking graphics. Our artists however are much more familiar with Unreal Engine, but they are willing to make the switch over to Unity, since most of their work will be done outside of Unity, so we think that this won’t be of any problem.

Which mechanics do we want to have in our game?

The main mechanic is all about grabbing stuff and being able to move and throw them around. In order to keep the siege going, you have to gather resources which you can get from cutting down trees or mining stone. In addition to that you can also grab enemies and throw them into the grinder. Of course bigger enemies will require more people to carry them around.

We have also been thinking about adding a system that when your siege gets damaged, a part can break off and will require someone to come over with some resources to repair that part. While that is being repaired the siege won’t be able to move forward, thus making the players more vulnerable.

This image shows a tree which can be cut down, which will give you logs. On the left is the intact version, the right one is the version after it has been cut down.

What enemies will there be?

We have come up with a couple of enemies with different behaviors:
- Basic: the basic enemy will just come straight for its target, attacking it when it gets close enough.
- Bomber: the bomber is a variation on the basic enemy: this one carries a bomb, and will explode and do quite some damage when it gets close to its target. It’s best to stay away from this guy when it explodes, because that is quite deadly!
- Giant: the giant is another variation on the basic enemy, but instead of exploding, the giant will do a lot of slow melee damage, and will require 2-3 players to pick him up and throw him into the grinder. As a reward this guy will count for a lot of fuel for your siege weapon!
- Archer: the archer will seek his target, and will shoot arrows when he’s close enough. This guy will be easier to take down but can have a rather big range.

Two template gnome enemies standing around a tree.    

How will the camera work? What view will the players have?

For the camera/perspective of the game we decided to have a camera that looks down onto the game, and will move along with the siege weapon. When a player gets out of the view of the camera, he will be pushed along with an invisible wall to keep him close to the siege. We haven’t played around with the camera positioning that much yet, but we think that an angle of between 50° and 75° will work perfectly.

Here you can see the different players standing next to eachother, each having a different color. On the right side you can see some template resources lying about.

What problems did we have?

We are using Perforce in order to collaborate on a single project with multiple people. However since we’re using it for the first time, we’re not used to it yet so it took us quite some time to understand how things generally work.

We also had some problems with Visual Studio where our intellisense wouldn’t work, which was a big hassle when you’re trying to get work done rather quickly.

What worked?

The communication between our team worked quite well since we had set up a group in discord which we used to communicate between the different team members. We also get along really well, which is a big bonus.

We made a lot of progress in a short amount of time, because we are all pretty efficient in the tools that each one of us use.

What are we planning for the next week?

- fix some problems with the enemies that we didn't have time for to fix this week.
- fix some problems with the resource gathering and picking up since that doesn't quite work all that well yet.
- add a fuel system to the siege weapon.
- add a damage system to the siege weapon.
- try a couple more types of resources that you can gather.

That's it for this week's devlog, we now have to go, as the gnomes are getting the upper hand in this war... We'll see you next week with more progress!
~Group 07