Quaternion: Too Drunk 4 a Title (Basically a Tuple)

Last edited: 21 March 2016, 7:26AM

Info

Quaternion: Too Drunk 4 a Title was a arena brawler where drunk people picked up various alcoholic abilities around the map and used them to attack each other. It supports both singleplayer and multiplayer modes. I'm not really sure what's going on with the title, but I wouldn't worry about it.

Background

Quaternion was yet another game jam project I hosted with my local friends. This one was held just after I finished all my classes at UCI and graduated, during the winter break between 2015-2016. We didn't have a large group this time, and our total member number sat just shy of half a dozen. Despite that, this was probably one of our better groups, as every member was fairly experienced and committed to the project.

The concept behind this game was a total mess, but somehow in the end it worked itself out. Usually I like to have a concrete idea going into a jam. It saves us a lot of trouble if we already have a clear idea what we want to do, and as I've experienced with my past Aria jam, not having everyone on the same page can be damaging to the project. But for various reasons, we didn't prep as much for this one.

It's not like I didn't have ideas I wanted to do. I think my best one was Lizard Entertainment Presents Earthrock, a parody of Hearthstone. In this game, a bunch of lizards played what would be cards against each other. But instead of cards, they played with rocks they carried around in their rock sack, what would be a deck. On the rocks were carved inscriptions describing their stats and effects. At some point, I think Alex was interested in doing a card game for a game jam, so he might be interested in doing this kind of jam and working out card mechanics.

Another great idea I had was a parody of idol games, called IDOLM0NSTER. Instead of playing to improve and find idols, you played to find monsters. Rather than a manager, you were more something like a monster handler. And that's pretty much it, I guess the the rhythm game aspect would stay the same. We've never done a rhythm game before either, so I thought that could be fun for a jam.

Both these ideas were mainly aesthetic concepts. It wasn't really that innovative on the gameplay side. There were always a few older ideas I could pull out, though these two were what I wanted to work on the most. One older idea I considered was maybe doing the 2nd person shooter I've always been talking about. I thought the 3D aspect would be too much to handle, so I threw that idea out. Funnily enough though, our next jam that will be held in a couple days from when I'm writing this is actually doing the 2nd person shooter.

Well anyways, all my suggestions were rejected. Winston, my roommate that lived right next to me, was the one I passed all my ideas through. He didn't like any of my suggestions, however, and didn't offer any possible ideas of his own. I don't know if serious he was, but he actually said if we did Earthrock or IDOLM0NSTER, he wouldn't come because they were too stupid. So I was left in kind of an awkward place where I tried thinking of new ideas but couldn't really come up with anything better than what I wanted to already do.

We ended up deciding that we'd try and figure something out during our car ride back to NorCal, a 6 hour journey with a lot of space jam in the background. Since everything I wanted to do was rejected, we started with what he wanted to do and worked from there. After talking a while, he wanted to do some kind of game based around drunkenness, maybe a fighting game, where your power(s) changed depending on how drunk you were.

So we thought up of a couple different variations of this. One concept was a game where the point was to keep on hitting the other person until they sobered up, and the first one to sober up lost. Thinking of the orientation also changed things too. Rather than a simple Street Fighter style side by side fighting game, we considered Super Smash Bros., which offered a larger map and item pickups, in this case alcoholic pickups, that could change your drunk state.

Mechanics had a lot of options too. In the spirit of drunken fist, maybe the more drunk you got, the harder you hit, and if you got too drunk it perhaps backfired against you. We thought about unique abilities as well for special characters as well, like throwing up and molotov cocktails. Art-wise, it may be too intensive if we wanted to make too many individual abilities and characters, but the variety of concepts we had was good to think of other ideas.

I wasn't really 100% set on a drunk brawler. I don't think fighting games appealed to me that much, though it was something new to try out. We didn't really ground the game concept completely over the car ride, but there was a lot to go off of, and we could probably narrow down our design come the day of. Personally, I think I was just satisfied with Winston wanting to do something and becoming more invested in the jam.

Next time, I'm not sure if I want to vet things through Winston, as he's only been pretty negative about my choices. For the next local game jam coming up, I chatted online with Alex about what to do, and he was a lot more receptive and helpful deciding things with. And I think having Alex on board with the project is the most important out of everyone on the usual team. He's definitely the most vocal and boisterous out of all of us, so keeping our emotional leader engaged and full of energy is important.

Come the day of this jam, most of everyone showed up on time and stayed for the entire time. Alex and Winston were the only ones who stayed overnight at my place, but outside of sleeping hours, everyone tried to be there. Alex had to unfortunately step in and out due to doctor appointments, as he was recovering from knee surgery and needed it checked out. Ted (Theodore) also came a bit late and went missing a more hours due to personal matters and distance.

Our first problem was to try and settle on the game idea. Basing our game on drunkenness was okay to work with, but we needed to ground other factors like orientation, moves types, and abilities. Making sure not to overcomplicate ourselves was another consideration too, as we could easily see ourselves getting lost in a rabbit hole if we wanted to make specialized characters, each with a ton of special abilities.

The simplest idea to go for was a Street Fighter style game where we had 1v1 local multiplayer. But designing the characters was problematic. How many characters should we make, and how many moves should they have each? We considered something like dive kick where there was basically only one move we had to take care of. In the end, it was difficult to think of a solution that didn't make the game too bland or complicated.

We considered something more like Super Smash Bros., where on top of a basic move set you could find abilities around the map to use. I think it was then that Alex suggested we look at Stick Arena. Stick Arena was a popular game back in the day that, if I remember, was on Kongregate and Addicting Games. It was a multiplayer battle arena game where you played as stick figures in an arena that went around the map picking up weapons to use and attacking each other with them.

Winston was a bit put off by the top down view of the game, a perspective we didn't think too much about because he wanted to focus on fighting with the profile view's traditional high, mid, low attack variations. However, Stick Arena's gameplay fit our idea well. Instead of weapons, we could pick up abilities around the map and use these to attack each other with.

Favor was shifting toward Stick Arena, which had more concrete and simple gameplay that we could model off of. Most of our work would concentrate on adding and implementing individual abilities, something we could arbitrarily add or remove from. The biggest problem was multiplayer. We could narrow it down to just local multiplayer if it came down to it, but in the spirit Stick Arena, I volunteered to handle all the networking.

I was actually a bit excited to code networking. It had a been a while since I last touched it, for a multitude of reasons. Part of it was because of how much I disliked UCI's networking track and was put off from working in it, although most of it was just myself working on a lot of non-networking projects. Given another chance to do networking seemed fun and challenging, and I committed myself to getting it done by the end of the jam or die trying.

I also wasn't too keen on doing art again. I wanted to use these jams as an opportunity to do more coding, and with Nina on the team, she offered to handle art this time around. It's not that I find art to be too boring, but I'm kind of the networking specialist out of this group, so I wanted to take care of it again. It's what I oversaw on Tetris Buddies and POKEMANS, previous game jam projects.

We agreed as a team to use Unity since that was something Nina, Winston, and the later to come Ted were fairly familiar with. Alex had some very basic exposure to it, but he was down to learn more about it. I've been on a lot of Unity projects, but most of my duties weren't code related in these games, so I was still pretty inexperienced. I would need time to get used to it, especially to understand Unity networking.

Well, let's dive into the meat of things now. It's been a while so I'll try remember what I did to the best of my ability. For the first and second days, I worked pretty much exclusively on networking. I had some previous experience with C# sockets, but to spice things up, I wanted to see what other things Unity could offer me networking-wise.

Unity mainly offered two types of network wrappers. The first, called Transport Layer API, was more low level, and the second was much more higher level, literally called High Level API. HLAPI interested me since all I've been doing now was sockets, and I wanted to see what other variety of networking programming existed. The HLAPI seemed to be what Unity wanted new developers to use also, so I decided to use it that for the project.

Using the HLAPI was very weird. I felt a considerable loss of control not being able to know what exactly was being sent back and forth between computers. Instead of sending and receiving packets like I was used to normally, most of what you did was slapping on a Network Identity component to Unity objects and hoping that everything synced properly.

The way it was designed made it so that you could start your project by writing a single player version of the game. Once that was finished, you added Network Identity attributes to variables/classes, and the multiplayer aspect would seemingly magically work. Yes, magic might be the right term here. The online tutorials to some basic extent explained what was going on, but a lot of it was trusting that the system worked and hoping what you were doing was correct.

There wasn't a lot of documentation and help online I could find explaining subtle issues that cropped up. In the end, for some problems we forcibly tried the hackiest combinations of code in order to find a fix. I'm not sure if this was partially the fault of us or a fault of the actual API, and that's a bit unsettling and troubling to deal with.

The nastiest bug I encountered was an issue where a parented network object that was spawned behaved very oddly. For some reason, when you spawned a new object as a child of another object, for instance, displaying a fire animation in front of your player when you activated a molotov cocktail, the animation would teleport off of your player and go to the (0,0,0) point of the overall map. The weirdest part was that this only happened on certain players' screens, either the client or the server, though I imagine the former.

I couldn't find out why this was the case. I thought maybe it had to do with an issue not calling Commands/ClientRpc calls correctly, but no matter what I did I couldn't find out how to fix the issue. If there was no parenting involved, it was fine. We could have the fire and punch animations be static animations that displayed, but the moment you wanted to attach these onto a player, you ran into problems.

Eventually it was Nina who found a fix with a really weird workaround. Instead of spawning a new animation every single time, all players automatically had a fist and fire animation attached onto them by default that was parented correctly. When they attacked, the only thing we had to do was enable the animation to become active and visible instead of worry about parenting.

Apparently that worked, but the way she called this process was plenty strange too. Apparently she went to the lengths of calling a ClientRpc method from another Command method in order to make this change reflect on all players' screens. Really odd stuff, and props to her for figuring it out. I don't think I would have found a solution by the end of the jam if it was just left up to me.

Figuring out the network syncing was half the problem, however. The other half was figuring out how to properly set up connections and lobbies. By default, there is a very generic looking lobby manager that you can use to quickly set up matches, mainly for debugging purposes. One would think that you could simply mess with the UI within this object easily make a prettier lobby for your needs, but the truth is anything but.

I couldn't figure out how to get a custom lobby manager going by itself, and looking online for examples didn't help much either. Eventually, I found a sample lobby project provided by Unity itself, and after meticulously looking through their code and setup, throwing away whatever I didn't need, I was finally able to get something working. This was a really tedious process and took a long time of trial and error to get working since there was barely any explanations or tutorials covering this. I really hope there's better documentation somewhere by now.

While I was working on networking, the rest of the group worked on the main game. The first thing to do was flesh out the abilities. I don't really know if all of them were thought up of then, but by the end we had 5 item/ability pairs. The default ability was a basic fist that did small amounts of damage. You switched to this if you used up all the charges of other abilities.

The next was a vomit projectile that shot across the screen and disappeared if it hit a wall. Then we had a poop ability that set a poop trap underneath your character when you used it. If another player ran over the poop, they took damage and were slowed. This poop interacted with the next ability, a fire attack that hit in a cone shape where you aimed it. You can clear poop on the ground by firing over it. The final ability was a heal to regenerate your drunk bar. You slowly lost drunkenness over time and needed to refill to keep it up.

How the game worked was that you tried to kill people with your abilities and then steal away the drinks they've collected. Every time you picked up an ability off the ground, you gained a number of drink points. Upon killing someone, you stole something like maybe half or a quarter of their drinks, I forget. When you reached zero drinks, you lost the game and were eliminated.

I'm impressed that we were able to implement all of this into the game in time and on top of that balance them to a reasonable degree. We actually had quite a bit time left to spend our last few hours testing and adjusting the game to our liking. In terms of scope, I think this was definitely one of the biggest and most polished projects I've worked on in a game jam.

Nina took care of art and finished it very quickly, moving onto game and miscellaneous code by the second day. Apparently art wasn't too bad to do. The top down view made animations very easy, as we could do most of the simple transformations within Unity itself. All it involved was shuffling the parts forward and back for walking. After the characters, she moved onto items and map tiles.

A good thing about this project was how iterative it was. The number of characters and abilities she worked on could be easily subtracted from or added onto. There was no pressure to finish, I don't know, half a dozen animations for a character to call it complete, which is probably what would have happened if we did a traditional fighter.

On top of doing the art, she contributed a huge amount to the game code as well. Alex was inexperienced with Unity, so a lot of his guidance was helped through her. Tasks-wise, she handled pretty much all the states/animations and fixed a ton of awful, disgusting bugs like that of the parent spawning issues. There were a few bugs still lurking in the end that we couldn't figure out, like the fire animation flashing weirdly, but oh well, what can you do.

Alex worked on weapons and damaging players. Due to this lack of experience, he did comparatively less than what he put out on other projects, but I'd say he had a fun time with this project regardless. Rather than having to deal with the gnarliness of the usual Pygame, he found the entrance of Unity much more graceful and almost too easy. Later on, we did some paired programming/testing later on to fix some spawning issues and balance a lot of the game.

Winston had a variety of odd jobs. He started off working on the spawning of item drops, and once that was done, moved onto level making. This he worked with Nina pretty closely with since she was experienced with using Tiled and Tiled2Unity and was in charge of drawing the tiles as well. I'm pretty sure all of the maps were designed on by him. At some point, I recall he was working on some kind of particle system too, although that never panned out.

And last but not least was Ted. He decided to take on something often neglected on projects, sound. We had quite enough people already working on the game, and since he came late, he wanted to contribute in a different avenue. Since sound was something he didn't have much experience in, if at all, he thought it would be fun to give it a shot.

He made the entire background music through a MIDI synthesizer, if I recall, and the sound effects I want to say he generated from BFXR or JFXR. For a first time effort, I think he did a really good job, and I like the groovy track. Since having to work on sound on the next project, Going Home, I have total respect for anyone now who dives into sound and produces something by the end of it. Music production's not easy to jump in and get used to.

Ted did a significant amount of programming too. He put all his sounds and music into the game and also started the movement and collision code for players. I think at one point he wanted to do some kind of drunk effect with the turning movement where you had trouble changing directions due to your drunkenness, but he couldn't get the math down for that. I think what happened was that a bug would pop up where you would randomly spin in circles. In the end, he removed it and kept the turning simple.

Most of the drunk effects were done by me when I worked on the camera. I handled all the camera bobbing and rotating movements. It took some time to get the math down and make sure it felt a good amount of drunk, where it was drunk enough but not too nauseating. I think I'm happy with the final product. Screen shake was also handled by me since it involved the camera too. And also the end game zoom out was an effect I added at the end of the project when we wanted to figure out what to do with the camera after you lost.

That pretty much covers most of our individual roles and most of the development. By the end, after a long night of bug fixing and balancing, I'd say we were very content with our final product. Our last hour consisted of playing a lot of 5 player matches, and these went for the most part quite smoothly and were fun to play in. I think Alex was probably the most happy with the end result, saying that this was definitely the most polished of a game that's come out of our local jams.

I guess I should say something about the name. Because we never really had a concrete game idea, we didn't really have a name we wanted to go with. When we started talking about possible name ideas, I was coincidentally working on the camera rotations and movement. By then, I was working with quaternions for the first time, and they were pretty damn weird to understand. Actually using them was easy, but none of us really knew how the individual quaternion components worked.

So I said a phrase I picked up from other members of VGDC, where quaternions were basically just a tuple, don't worry about it. And as an inside joke, that became my/our response to everything. Why couldn't we fix this parenting bug? Quaternions, man, parenting's just a tuple. Naturally when we tried to decide a name, I responded with quaternion since I couldn't think of anything else. Eventually, it came time to actually put in the name, and Nina, throwing our inside jokes together, created what you see now, Quaternion: Too Drunk 4 a Title (Basically a Tuple).

We had a lot of fun trolling and dicking in this jam. The atmosphere was better than my previous summer jam with the Aria project, which was significantly less loud and boisterous, and less fun overall as a result. On top of making a fun game by itself, I guess finding the right gelling of people is important too. I'll do a better job making sure more people can show up and more of the right people can show up.

I guess as a final note, I'll leave with the duck story. If you play the game a couple times, you'll probably notice that there's a character who's a duck, and if you play the game enough, you might get the chance to hear the secret duck soundtrack that plays in special circumstances.

The story behind this was that if I recall, Nina made a third character at one point to add on top of the normal male and female characters. This one was supposed to have a baseball cap, but the first thing we thought of when looking at it was that it looked like a duck. I think she tried to change it to look more normal, but without much luck. Eventually we decided to run with it.

Later on, Ted as a joke made a duck soundtrack by switching out all the synthesized sounds in the normal song to duck noises. We actually thought it was pretty funny, so we kept it in as a joke. I'm kind of actually amazed we pulled this off since there was a lot going on at the time. I guess if you want to meme, you sacrifice everything else to do so. Memes before dreams, people.