GGJ 2016 - The full story

It has been about 2 weeks since the Global Game Jam 2016. I must say it was really cool and very different to GGJ 2015. Here's the full story.

GGJ?

Really quick and incomplete explanation for those not familiar with GGJ. It is a world wide event where people create games about a specific theme that is revealed at the beginning of the jam (Friday), and in 48 hours you must have completed and uploaded your game.

It's not a contest, it's just for fun, it forces people to complete at least a quick a simple game instead of spending years improving a single one that will never be released (ok, that was for me), and because you know other game developers (a.k.a. networking).

An interesting part of it is that in order to enter the jam you need to go to a registered site (yeah, physically), which is just a place that can provide what is required for the event, i.e. electricity, Internet, desks, enough space, bathrooms, and in some cases some other vital nice-to-have things like coffee or pizza.

Going alone?

Compared with the previous GGJ for this one I was going alone, even if any of my friends would have gone, from GGJ 2015 I learnt that I didn't make any networking because I was really busy completing BARKH, so if was going to go to GGJ 2016 I was going to join a random team.

So yeah, I was a bit nervous because I didn't know in what kind of team I was going to end up! To make matters worse, there were 6 sites in my city... is that bad? well, the amount of developers here is not THAT big to require 6 sites, so instead of having 2 or 3 big sites, we had 6! This is not good because you have a smaller probability to find a good team, or to move to another team if you don't manage to fit in your first team. So yeah, somehow people here lost the point about the networking thing and decided to make a bunch of smaller groups :\, in my city were 6 of the 20 sites in Mexico.

But OK, I decided to be positive and go to the site closer to my house.

Joining a team

So there were I, very early as usual, this was not that new for me. You arrive, register, and put a sticker with your name and with your skills (using a color code), I labeled myself as "game designer" and "programmer". There were a few people, I took an empty table and played a while with my Jumpjustu music theme waiting for the event to start. After a while there were about 6 tables full of people, some guys joined my table too and the organizer asked us to make a "quick" group bounding dynamic. The guys in my table were a team already, I was the new guy there and I was not totally sure if I was automatically in their team or not... it was a little weird.

After that, the organizer asked who had no team, so I raised my hand... (I think, but I'm not sure, someone made some weird noise indicating I was betraying the guys in my table). So the organizer asked "who needs a programmer?", after about 5 seconds that felt like 60, a guy in another team raised his hand and I joined his team.

When the Jam ended I found out the guys I "betrayed" were from One Simple Idea @1simpleidea, creators of Mucho Taco a fairly successful game for iOS and Android, that got quite good rankings in Apple Store.

So, did I miss my opportunity to join a great team?

The answer is no.

I moved my backpack and sit with the other guys. They were going to be my team for the following 48 hours so it was time to know who they are. I must say I ended up having a quite nice team!

• Programmer: Marlon, works in Cosmogonia @CosmogoniaGames a known game development company in Mexico (for those related to game development), and previously worked at Gameloft. He has some years of experience in Unity.
• Conceptual designer: Mónica @moni_red, she is a Marlon's friend. She didn't know about making games but is very good drawing.
• Music and sound: Ricardo @inkeyesmusic, he is a musician and works in KaraOkulta another known game development company in Mexico.
• Pixel artist: Luis Zuno @ansimuz, he is the creator of Elliot Quest, a known indie game that was released in Ouya, Steam, and WiiU! He is an awesome pixel artist.
• Another guy: He left on Saturday, I hope he never read this haha.
• Me :), another programmer.

Marlon, Monica, and Ricardo went together to the jam, all the others had never worked together before.

I'm going to be honest, being creating a game together with Luis Zuno was really awesome for me. Other guys in the team didn't know about Elliot Quest, but I had already heard of it, and saw it in a Nintendo Direct. I'm not sure how to explain why this was so awesome for me, but let's say that if I could have a game I created to show up in a Nintendo Direct I could just die in peace haha. So I was just eager to talk with him about how it was to release a game in Nintendo and ask for any advice he could give me in general.

Working with the theme: RITUAL

They revealed the theme before I had my team, so when I heard "Ritual" I honestly didn't start to think anything, I was more interested in finding a team and work with them. So once I was with my team we started to throw some random ideas and write them down in a whiteboard.

After some minutes we were kind of close to make a game about a witch that summoned ghosts with OCD... it sounded fun but something didn't feel right about it. Also the playable part was not quite clear so we continued exploring some other ideas.

I don't remember many of the other ideas we analyzed, but somehow we ended up talking about an African shaman defending his village, we all in the team were happy with the idea. It was a little inspired in Patapon but the core gameplay was actually quite different. It was going to be a tower defense, were the tower is you village at the center of the screen, and enemies come from different predefined paths to attack it. The player must use combinations (shaman dances) to summon magical attacks on the roads and stop the enemies.

There were still some things that were not very clear about the idea, but we agreed in create a prototype and then we would decide what was right and what wrong.

TIP: In a game jam you can waste a lot of time planning, but a quick prototype will help to understand how much you can actually achieve in the remaining time you have.

Let's work

We were divided in 3 groups, graphics, music, and programming.

Monica created some concept art that later Luis converted into pixel art:

Ricardo pretty much worked by himself :), once in a while Marlon explained him what sounds we needed, and others in the team gave some ideas of how the music should be.

I don't have much detail about how the music and graphics side happened, so let's talk about the programming side.

Organizing the programming side

This is what we did and worked very well. Consider this an advice on how to organize the programming work in a jam (some things are Unity specific):

1. Create a Github repository (Github has a nice helper to create the .ignore file required in Unity projects to avoid adding files not required).
2. Enumerate all the sections of the game you need to program: the screens, the input manager, the enemies, the different attacks, and so on.
3. Enumerate all the Unity prefabs you need to make. As a matter of fact, most of your game's components should be prefabs.
4. Create a scene per developer. Each scene is modified only by the developer assigned to it.
5. Create a main scene to put all the completed parts and see how it works, once in a while you can just copy all its content into your personal scene.
6. Have a lot of communication about modifying shared files, make sure to don't overwrite others' work.
7. Backup often. You don't know if something really bad is going to be pushed to the repository.
8. Sync up often. Waiting too much to pull others' work is a recipe for disaster.

A lot of this organization was Marlon's idea, probably because of the experience he has. I was learning everything I could!

First prototype

After one day, on Saturday evening we already had a first playable version.

It sucked.

It was totally unplayable, but it was fine, we had enough time and some of the flaws in the gameplay were quite clear for me. Personally I feel that my contribution was important for this. Let  me quickly discuss some of the problems with this first prototype.

The enemy rate

The enemies appeared in a constant rate, this was a huge problem, you need to give the player moments of excitement and moments of peace, so she can organize her ideas in the moments of peace and prepare for the next encounter. If you just throw enemies in a constant rate the player gets overwhelmed. This is used in almost any tower defense game, e.g. Plants VS Zombies, maybe you are always under attack, but there are some times that there are only a couple zombies, then they let you know a horde is coming and you get ready. Beating the horde is satisfactory to the player, so she gets more engaged and willing to confront the next horde.

The controls

In this first prototype the game was played with keys A, S, D, and F. They felt weird. To make matters worse, the combinations you needed to do for the different attacks were randomly generated every time you played.

Ricardo pointed out that ASDF didn't feel good when he played, so we changed them for the arrow keys, also we removed the random generator and made the combinations related with the position of the area to attack, so it was much easier for the people to get the idea of what they needed to do. For example to throw a Fire Attack at the top-left corner of the scenario the combination is Up + Left.

After that Marlon's wife (that was there at that moment) suggested that the last key to select the attack should be different to the arrows. I had the same feeling but somehow changing it sounded like a lot of work for the remaining time, anyway her opinion was the push I needed to go for it, I proposed to use keys 1 to 4, which is more intuitive in my opinion. So the combinations ended up being something like: Up + Left + 2.

To make it crystal clear for the players I suggested to make the Title Screen to use a combination to start. I got the idea from Depict1, a game that introduce the game mechanics in the very first screen. So we did so, and did the same for other screens.

Visual feedback

All of us were aware that there were still missing parts in the first prototype, but we underestimate how important was to clearly show the paths the enemies were going to follow. Also the enemies didn't show any reaction when they were attacked, so you couldn't know if what you were doing was working. After we added those effects it became much easier to play the game.

Initial design ideas

One of the initial ideas was that you were going to have 3 spells to cause damage, and one spell to recover health. The player was supposed to use the one to recover health when the village looked sick, but if the player would use it against the enemies by mistake, the enemies were going to become more resistant.

At some point we dropped the idea of the village status, but we still had the spell to recover HP to the enemies. I needed to argue with some of the team members about removing it because it was extremely confusing. There was some idea of using it against undead enemies in order to kill them, but it was clear those enemies were not going to exist by the time the jam completes. So after some arguing we agreed to make it a different attack, one that makes no damage but makes the enemies really slow.

The final day

We had a lot to fix, and we actually rushed to complete all the changes we needed to make, but anyway we managed to have some time for polishing. Ricardo's music really fitted the art style, and it was very catchy as well. We fixed some bugs, added the final level (that you must see ( ͡° ͜ʖ ͡°) ), added the music and sounds, added the credits screen, added the drawings for the title screen and game over, and tested some times the whole game.

As always I asked people to play the game without telling them how to play, and it was very satisfying see they got the idea quite fast.

Marlon exported it to WebGL and uploaded it. I uploaded it here too because in this way I can make sure that the game is up and running as long as my site is up and running too.

The Presentation

We presented our game to the other teams, it was quite satisfying because the game feels complete and fun. Latin America's Unity promoter actually recorded the presentation (it's in Spanish, I'm the guy using a blue shirt). Other teams made interesting games too, you can see here the other games created in the same site, however many of them are not playable via browser.

It was an amazing experience, definitely going alone and know new people was a good idea, I highly recommend it.

You can play Shaman Defender here, and drop me a comment if you want.

Epilogue

I saw my team again when we presented the game in our city's Unity User Group. I got some feedback from Ricardo about my song for Jumpjustu and I'm planning to continue going to the group meetings.

~ The end ~

New (mini) game in process

First, I'm not abandoning Ascendam, I've been programming a little of its main mechanics and I thought I will need a lot of feedback to make them feel as good as I want, so I decided to make a small game based entirely in Ascendam's wall-jump mechanic.

Besides I think it is kind of simple game I have had a though time explaining it to a couple friends, that sounds kind of a warning signal so I'll make sure my prototype is very clear about what the game is about. All what I'm going to say for now is that it will be local multiplayer game based on wall-jump mechanics.

I'm really exited about start prototyping it, I already have some code from Ascendam and I decided to use very simplistic art style... I haven't had very much time for game dev lately, however will do my best.

I drew this characters in Pixly... then I noticed I could make them directly with Unity basic objects haha, so probably I will use this only as a guide to make the 3D ones:

Pixly did something weird with the original colors (eyes should be black, and the sword doesn't change), but it's fine, it looks kind of cool anyway haha.

Looking for feedback: How-to-play for Defender Blender

Defender Blender v0.3 is finally here :), I made this looking for feedback about the How-to-Play level. I also tweaked some stuff and fixed a few bugs.

Please take a look, I really appreciate your feedback!.

You can play it here!

Edit:
Lesson learned: Seems like Friday is the "official" date for look for feedback in Unity forums and Reddit, so I posted here:
Unity feedback Friday post
Reddit feedback Friday thread

I really got inspired when writing the Reddit one and wrote this, a little dramatic but I hope it will grab some attention:
Defend the secret Laser Cannon while it traverses the land to protect you people from an imminent attack!! Your willpower and hope to survive this challenge have converted you in a immortal killing machine, were you be able to use all your power to defend your people?! Don't be afraid, you are not alone! With your help, the Laser Cannon can gather power and destroy all the enemies in screen with a single powerful laser beam!!

Will it work? We will see :P

Game progress: Defender Blender

This was a really busy week, however I managed to have a little progress with Defender Blender.
Defender Blender is a game I made for learning Unity, I'm still learning from it and experimenting playability, difficulty, and a some game design. I will talk more about it once I upload it here, for now I'm sharing the progress I had this week.

First lesson learned, after update Unity 3.2.something to 3.6.2 I found that my game was not working anymore, most of the collisions where working just sometimes so I was not able to hit the enemies, the player was not pushed to stay in the screen (it is pushed by an object at the left of the screen), and things like that, so I started to investigate and found that there where two reasons for these problems:

    1. Rigidbodies sleep. Seems like this is an old Unity feature (before 3.2 version), so I'm not sure how my game was working before :). In order to optimize the physics in Unity, the engine does not check for collisions unless they are required, i.e. only if any object's property that could affect the physics changes. Why my objects were not detecting some collisions? Let me explain.

• You can have a Collider with Rigidbody, or without Rigidbody. A Collider without Rigidbody can actually collide with other Rigidbodies but only if they are awaken. A Rigidbody won't wake up when touched by a Collider. Some people use a kind of workaround for this (however, note that this is not a bug, it's a feature), they change the Rigidbody's position in the Update method in order to wake it up, something like: "rigidbody.transform = rigidbody.transform". The problem with this is that it is a kind of dirty trick that won't help your game's performance. So what is the correct solution?
• When a Rigidbody touch another Rigidbody, it wakes up. So put a Rigidbody component in whatever objects you're going to move constantly (like the player, the enemies, the projectiles). Adding a Rigidbody to some objects fixed my issues with some collisions.

    2. Methods in animations. After adding the Rigidbodies to some of my components I was still having problems to attack my enemies, it was like there was a kind of random factor that could make it work, or sometimes delay the collision. Actually I was able to see the collision happening in OnTriggerEnter method, however it was still not working. Then I found out that the issue was because the logic I used to activate the collision of the player's weapon. I used a method call from an Animation as you can see in the screenshot:

StartAttack() method activates a boolean variable that decides whether the sword collision is going to happen or not, this was needed because even when the Collider was really small when not attacking, sometimes the enemies just died because they touched the Collider inside the character.

So the plan was: when the animation starts, call StartAttack(), so the collisions are processed...

Well that is how it worked before, however animations seem to not have a lot of priority for Unity in processing, they are visual components, it's not a really good plan to depend on their accuracy to fire events in the right moment. Instead I called StartAttack() from the method which starts the animation. That fixed my problem.

What is I was really planning to do

After solving these bugs I started what I actually was trying to do, I added a new component to my game: Walls. I'm planning to use them mainly to teach the player how to jump because I noticed some people struggled to notice that keep the jump-key pressed make the character to jump higher. Also I want to use the walls to teach some other movements in the game, I will use them in a new How-to-play level.
Since my game uses physic objects as Kinematic objects, it does not use the physics engine to affect the objects movement, it only detects the collisions, so add a wall is not as easy as drop a rectangular Collider in there.

The Kinematic Rigidbodies/Colliders know they are touching each other, however they don't know the direction of the touch, so I can't just program my character to stop moving when touching a wall, because then it will stop as well when walking above the wall (it must be able to work above the walls). I was planning to use a different Collider on the top of wall but it was going to be messy. My plan so far is to do it by comparing the wall's position and the character position. When the player is above the wall, the wall will behave as a platform, and when the player is in any side of the wall, it will act as, well... a wall.

Well this is work in progress, after complete the programming of these walls, I hope to make a post about my how-to-play level design. See you next week!

Burn & Run Kamikaze Heroes!

I have had this blog for a couple days without a real idea of what would be a nice first entry, I really didn't want to post a "Hello world" again.

So, what could be better than start with a game! - I teamed up with a friend, Lal0l, a couple days ago and participated in the Global Game Jam 2015, which theme this time was the question: "What do we do now?"

We ended up doing this kind of funny and sinister game where you find yourself in a really dark labyrinth with a bunch of friends. You are around a big torch and you know the only way to find the exit is by BURNING YOUR HEADS TO LIGHT UP YOUR PATH!!!... btw, you are a bunch of matches ;)

Give it a try, it is the first version created in less than 48 hours, we have already some ideas to improve it, but I think you'll find it fun in its current version. You might also found a couple bugs.

Play it here! (controls: Mouse + WASD)

Would be nice to know what you think about it. If you want to comment please do it in the game's page (the same above).