This week marks the first week we actually started making a game. Between defining the art style and laying foundations for the prototype, lots of things got done. 

Our programmers made progress on the circular 2D movement around the tower, and the camera system for keeping the camera centered on all players at the same time. 

On the art side of things, a lot of defining of the style has happened. We've thought about what general style we will use, done some character design, thought about proportions, UI... all to be seen in the art bible (WIP).

To keep track of our progress and remind ourselves, we've asked ourselves a few general questions:

Questions:

1. Is the current artstyle within expectations?

At this point in time we are happy with how the art style is turning out. The cartoony style emphasizes the fun, fast-paced gameplay we want to have nicely. There are some concerns on how well it will translate into 3D, as all sketches and textures made so far have been purely 2D, and cartoon-inspired. We'll have to experiment more with making actual props before we can really judge. 

2. Does the camera movement work?

Florian has been working on the camera movement, and how the camera pans according to where all players are on screen.

The camera works in a way that it will always have all the players on the screen, but won't encourage players to wander off far away on their own. Each tick the camera will retrieve all player z components (their height), take the average and match its own height accordingly. Because of the nature of averaging numbers out if the majority of players is on a certain height the camera will lean more to this height than that of players who are further away from the pack. Florian is thinking of improving this by also having the camera move further backwards if the height difference exceeds a certain threshold, but since testing has not presented such problems at this point this hasn't been implemented.

3. Should we have used a pawn or character movement?

We started off using the character blueprint for the movement but this didn't quite do what we wanted it to do, which is move in 2 directions along a curved plane. After this we decided to use a pawn blueprint instead. starting the movement from scratch is probably holding us back a tad development wise but should provide more control in the long run.

4. What do we make the endgoal?

A major mechanic and plotpoint we haven't decided on is how we're going to handle the end/finish of the tower race. This has to fit into the 'story' of our game. 

The endgoal will have an effect on winner and/or general player satisfaction as well. We can either make it a cool reward for getting to the end, or we can ruin the buildup of climbing the tower by placing something really silly at the top for comedic effect. We have been throwing around ideas from ritual sacrifices to something as silly as a golden bathtub.

5. How many mechanics is too many mechanics?

Right now we have a big list of ideas for traps and mechanics.  A lot of these sound intuitive and fun, but ultimately we'll have to decide on only a few of these.  Too many mechanics will ultimately be confusing for the player, as he might have too remember too many things (not to mention more mechanics = more work).

Some of the best games around tend to focus on a few mechanics and really polish those, making them work in tandem really well and ultimately making for a more streamlined experience. 

In this way we could focus on our conceptual 'bash' mechanic and movement in general, and make it so all traps in some way or another work together with it. This connection doesn't necessarily have to be as obvious as: "when you bash you avoid the trap", it can also be a subtle effect.

6. How do we like unreal so far? Should we use unity?

It's been a bit of a double-edged sword. We have been using Unreal so far and it is quite intuitive to work with, for programming as well as using the cel shader, but when something goes wrong or there is a bug, it is quite difficult to figure out what the problem is and fix it. For now we will continue to use Unreal.