The University year has reached its end and with it my time at DJCAD is also almost over. This final year has been incredible and I think most of it has to do with my project.
I’ve always had this dream to work on games, possibly ever since I started playing them as a child. Unfortunately it’s one of those dreams that require dedication, it needs you to dedicate yourself entirely to it and learning things you have never had to do before. Essentially it’s one of those dreams that you keep pushing back, thinking that you will one day get to it.
In April of last year I learned that Hideo Kojima, one of my favorite designers, started working in the industry when he was just 23 years old. At the time I was 22 and I suddenly realised that I had done nothing to work towards my dream. Despite having all the chances to do so, I had never even tried it. I think that was the moment that finally pushed me over the edge. It made me realise I had to put aside my fears and start working on what I wanted to do.
I knew I would have a whole year of University to work on whatever project I wanted unfortunately my previous enquiries about presenting a game had been met with less than enthusiastic behavior. I understand why, a game is weird, it doesn’t really follow the usual projects that are presented. Perhaps it wasn’t the best idea, nevertheless I felt like I had to do it.
Honestly? I’m incredibly glad I did. I have now been working on this project for more than a year and I have loved every single moment of it. I had no idea working on a game required so much depth of knowledge in so many fields or that it required extensive thought and planning even for the smallest details. There was definitely a turning point. Things that I had been working on separately suddenly started to fit together in the bigger scheme. Talking to people, making this character move and seeing those people having fun with what I made was incredible.
Don’t get me wrong this project has been mentally exhausting, it has required me to put thousands of hours in research and development. But looking back on it now, I’m not tired of it. I wouldn’t mind putting another thousand hours into it at all.
It’s not easy to put into words what I’m trying to say. This was so rewarding and so fun that despite the endless nights in front of a screen writing code it was all worth it to see my project coming together. It’s hard to express that I’m sure that I have found what I want to do for as long as I can. I’ve worked in design for a long time, pretty much since I discovered the internet. But nothing has ever sucked me in like this project before.
I have to admit, I am kind of trying to cheat the system. I’m not technically presenting a game, I’m presenting the method behind it and using what I created as proof. I’m sure that is going to be very annoying for my lecturers and external examiners. But I hope they can look past that and see how much design work has gone into getting this project to where it is now.
Games are seen as a highly technical endeavor, I’m sure many designers just think of them more as something a programmer should make, entirely unrelated to design. I’ve already received comments from other lecturers about this, and I understand it entirely. But if there is something that I hope my project will get across is that design and games are the ultimate meeting point of technology and design. Games aren’t just code, they’re just incredibly complex products, interfaces, user testing, research all coming together into a single project.
I realised my script so far is based a lot in the internal animation system Unity provides. So far I’ve been manually checking if X animation is playing and making certain actions happen in case they are. Don’t get me wrong, this worked fine when the game was small and contained, but with the script increasing in size it’s become extremely hard to manage by using this method.
So I took the week to plan out and develop a new system fully and I’m pretty impressed with what I managed to come up with. This is going to be a VERY technical post, be warned.
To put the state of my animations into perspective, this is how they looked originally.
This is a mess. Every box in the image is a different animation. Every arrow is a transition between animations. Because of the old system I was using I couldn’t separate different animations into layers without complicating my system tenfold.
I needed a way to make animation checking automatic removing as much work from myself as possible. This is around the time I learned to use Dictionaries properly. Dictionaries are essentially giant Arrays, the big difference between the two however is that a Dictionary can have a hash rather than an index. So, instead of calling a value like this
Array[index] values can be called like so
This essentially means that given a unique number of any kind, any value can be added at that index and associated to another value. Which is great, because as it turns out most of the animations handled by Unity are stored as hashes.
After wrestling with a lot code and trying to understand largely undocumented Unity methods, I was finally able to figure out how to add every single animation in my game to a dictionary and making it possible to check what animation I was currently in by passing a single line of code.
This has made fixing the code and adding new parts to it much easier than it has ever been.
I have been having some trouble finding a shape to start making my level from. Unfortunately I am really inept when it comes to 3D modeling, and I also had quite a hard time putting my ideas into drawings.
I finally managed to find a solution with clay. I bought a big block of it and spent the next few hours making, destroying and changing it around until I managed to come up with a general shape that I liked .
It looks pretty simple, I know, but as I have started building this level out in the game itself I realize how much making it out of clay first was.
The original idea was to make this look like one of the many italian cities that are build out of the side of a mountain. I supposed that would offer plenty of occasions for the character to shine in.
However after looking into it a bit more I just could not make it work with the time I had available. All these design will be eventually revisited when the game is more complete and there is more time to develop them properly, however for the moment the level I plan to show off to the public is going to be some sort of playground designed to show off what the character can do.
It is slightly disappointing but this has been the one hurdle that I have yet to move past.
I took a quick break from writing my guide and coding to take a look into how designing my level. There were a few things I had to keep in mind while doing this that I learned while talking to my interviewees about their experiences with 3D platformers to try and understand the essence that made these games so special, one of the most interesting observations I collected was about how the level design helps the flow of the game.
In case you are unaware, the objective of most 3D platformers is to get from point A to point B in a 3D space, while having to “beat” challenges related to controlling your character (jumping, beating an enemy, dodging an obstacle). Once you get to your objective, you collect an object and you’re then booted back into some kind of overworld where another level can be chosen.
In my interviews I collected to key insights regarding levels:
- Players liked that the levels were not one and done. In many games in the genre they levels were used again and again with the starting point remaining the same, but the final destination changing. This meant that as the players progressed through the game and played levels, they would become more and more familiar with the levels itself, being able to complete it better and faster.
- Quick gratification and instantly quantifiable progress made the players feel accomplished. By finishing a level and collecting whatever object the game tasked them to collect, they game would make it clear that they had done verifiable progress. By keeping challenges original and interesting and without making them particularly long to complete, players would become addicted to making small increments of constant progress. This keeps the game fun and interesting.
I’ll try to bring these insights forward while trying to build the level.
While I’m aware that this was not needed at all, ReactJS is extremely employable so I thought that if I had to make a website I might as well learn something new while doing it. Getting started took quite along time as I couldn’t quite figure out how to get it to work at first but once I started understanding its inner workings everything else became much faster.
The website is CURRENTLY not online yet. While the code has been written and the content is finished I want to do a few more revisions to it before making it go live. I do have a sneak peak to show though.
With things starting to wrap up I have had to stop for a second and look at my work. At the moment I think I am in a pretty good place. The game is in a more than presentable state and I have finished writing my style guide.
As it currently stands my style guide is most likely going to also be my booklet. I have decided that the main way to consume my style guide is going to be through a website, at least for the time being. Web access will make it easy to consume and will allow me to make the information about my design available to the public.
In the coming weeks I will start designing the website and adding my information to it.
As mentioned previously I have been trying to collect a lot of the information I have learned while working on this project. My biggest problem at the moment is understanding how to make it easily readable. What I don’t want to have is what happened with this blog, an endless stream of technical blogposts that don’t really explain anything about my design process.
Hopefully by the end of it the blog and this information will both serve a purpose. The blog to see the technical stuff from behind the scenes and the document as a style guide.
I realised that I was still lacking a way to directly translate my character into digging into a wall so I decided to use the newly coded dash to make up for that.
At any moment, the player can dash against a wall and by pressing the correct input the character will automatically drill into it.
This is all I have done this week as far as the game goes. However I have now started collating all the information from my design process and the making of the game so far into a text document. I’ll post more updates about that as it comes along.
At this point the feedback I received from playtesting was that the character felt good and fun to control, but common complaints were:
- There’s nothing to “save” a bad jump.
- I needed a faster way to move around.
The solution for this was a dash and slide.
The dash can be performed whether the player is running or jumping. If the player is running, the dash allows the player to reach their goal faster. If the player is mid-jump, they can decide the direction in which to dash in and change their direction.
It’s a simple but elegant solution. Response seems to be positive, although I want to work on it a bit more thoroughly.
Continuing with the previous posts about digging I have made a few changes after observing some playtesting.
First of all. If the player is digging and exits the digging area, depending on the current inclination he will either be forced up or forwards.
This change wasn’t made for any particular reason rather than me having an idea for a future change. As of now it’s just slightly nicer to look at.
Secondly, I realised there was some interesting stuff I could do with jumps while digging. Before now, if the player pressed the jump button while digging, he would just jump up out of it no matter the slope he was standing on. By changing the direction of the exit jump depending on the slope it’s now possible to reach places opposite to walls where the player is currently digging on. This not only extends mobility, but allows for more complex level geometry and navigation.
I have made an interesting discovery that I had not planned for and I now think that I might add it to the game as a feature.
Apparently, because of the way my movement is handled, something very interesting happens if my character builds up enough speed while digging. With enough speed and a ramp of any kind the player can essentially launch the character across very long distances.
I love how this just happened by complete mistake but I now have something incredibly fun to add to my game. Player response about this has so far been very positive so I’m very hopeful that people will enjoy it.
If I had to choose one moment to explain why I like making games so much, this would most likely be it.
I just now realise that in the last blog I explained the problems and showed how digging looks but I did not talk about how it works for the player.
Essentially the player can dig in certain predefined areas set by me. From my point of view these are simple box triggers (the green square in the picture below):
However for the player once the game is more finished, will be identifiable by a different colored texture on the ground.
When the character is inside one of these big boxes, a few things happen under the hood. Switches are toggles and the digging functions are made available to the player. To actually burrow underground the player has a few different choices, however only one is available as of writing this.
While the character is crouching the dedicated drill button needs to be pressed. Once that is done the character will automatically transition in digging mode. In digging mode the player does not move around as he would normally but rather needs to “rev up” the character’s drill.
Essentially, the faster the player presses the button, the faster the character will go in game. The reason why the movement works this way is very simple. Player testing showed that having the user more involved in the control of the character simply made the interaction more fun than just holding a button down. When the player has to do some more work to have fun, interactions before meaningful.
This took me so long to actually get working I can’t believe it’s finally done. I had to do so much complex trigonometry and math that I don’t think I ever want to do it again. But at least the effort was worth it and digging now fully works.
As mentioned at the start of this blog, the main movement gimmick I wanted to add to the game was burrowing underground and allowing players to move alongside walls. While the burrowing was fairly easy (mostly just a model replacement) it was the moving on walls that gave me a lot of trouble.
What I had not considered while doing this is that I would need to rotate my entire character to make this viable. While rotating itself is fairly easy, problems started coming along once the character was vertical on a wall. For example, the previously mentioned movement vector would not rotate with the character, which essentially meant that once he was vertical and horizontal movement needed to be replaced by vertical movement that was just not happening.
I also needed to make this as easy to understand for the player, which meant that the direction the character needed to move in needed to be in reference not only to the position of the camera, but also to where the character was on the wall.
I tried fixing these problems for weeks, I almost gave up about 10 times but in the end I managed to figure it out. I had to rewrite some of my code but now all Vectorial rotations are handled by an invisible object that rotates depending on whatever ground is under the character’s feet. If this sounds simple it’s most likely because it actually was and I was originally having so many problems because I was trying to solve this in a very roundabout way.
Anyways, here’s an example of wall digging and transfering from wall to wall.
Continuing with the streak of general fixes, I made some changes to how my character is grounded.
In case you didn’t know, grounding determines if the character is on the ground or not. If the character is on the ground he can move, jump and do many other things. It’s extremely important to the functionality of a game.
Up until now my method for grounding my character wasn’t very smart. Using a raycast I checked the character’s distance from the ground under it. This worked okay, but just was not precise enough to the point where I am right now.
My solution was to add a sphere collider (the one right under the character’s feet). A collider can basically understand if it’s going through other colliders, in this case the ground itself. If the collider is currently intersecting with the ground, then the character is grounded.
I’m very surprised how well this solution worked out, it’s extremely simple but doing it this way had never crossed my mind up until now.
I kind of took a break in the past few weeks, I needed some time off to keep working. I just got extremely burnt out and couldn’t really stand making any progress.
While nothing new has been added in the meantime, a lot of small fixes have been made. The camera now doesn’t phase through walls but rather gets pushed against them. Animations have been moved around and the transitions between them work better. The script’s readability is much better and easier to edit.
It’s not much but it will probably make the rest of the work easier.
With the core movement options done, I decided to move on and extend what was already there with non-essential but still useful skills. The first I added was grabbing ledges.
As you might wonder, in a game that is primarily focused on jumping, many of those jumps might not land exactly where the player wants. Or even worse, they might just not be able to jump high enough to reach their objective. Because of this, the ability to grab a ledge and hoist yourself up is extremely useful.
The script for this is quite complex, but not very interesting. Essentially the character checks if there are any walls in front of him while jumping, if there are, he checks if there are any ledges that he can reach. If all of that is true he proceeds to grab on. Once he is grabbed, he can just jump up and reach the platform.
Early in development I realised that while my movement worked just fine on flat surfaces, the same could not be said about moving on slopes. This particular problem stumped me for the longest time and I was extremely happy when I figured it out.
Now this will require some specific language that might be hard to understand, but I’ll try my best to explain it. My character moves in whatever direction the Vector 3 connected to his movement tells him to go. A Vector3 is essentially a piece of data that contains X,Y and Z coordinates. This means that my script essentially takes where the character is, looks at which direction the Vector is telling it to move to and moves it.
With a joystick, it is extremely easy to give the character X and Z values. If the stick is pushed up, you will ad Z values to the Vector. If it’s pushed to the left or right, you will ad values to the X value in the Vector. However, as you might have noticed by now, this does not consider Y values at all.
Essentially, what this means, is that when my character walked up or down slopes, the movement vector was always straight. This caused him to detach from the ground when going down a slope and walking straight into one when going up.
To fix this, one must understand what a normal is. Essentially a normal is a Vector that will always point in the opposite direction from the ground a character is standing on.
If a character is standing on even ground, the normal will always point up. If they’re standing on a slope, the normal will always point opposite the direction the slope is facing.
Why are normals important? Because we can essentially use them to rotate our character depending on their values, and by doing so, we also end up rotating our movement vector, allowing the character to traverse slopes without problems.
While this was already shown in previews blog entries, I thought it would still be interesting to talk about as there is a lot of work put into it.
After testing an early prototype, I received a few complains about how rotating the character felt “Strange” in a few situations. At the time I had my character facing whichever direction the player was moving in, however the complaints came from when the user wanted to run in the opposite direction from which they were currently facing. This was a problem not only for aesthetic reasons but also because the character would just sprint full speed in whatever direction, regardless of rotation.
After much trying and failing I finally managed to implement what I call “pivoting”. Pivoting is essentially translated into the character doing specific animations in case the direction he wants to move in is a certain angle bigger than the one he is currently facing in. Not only does the animation make the movement have more “weight” and feel more responsive, but the character’s speed can also be diminished to give it even more realism.
As you can probably imagine, Jumping is also essential to 3D platforming. While making a character jump isn’t very hard by itself, there are many things that need to be considered while implementing this.
First of all, the player must be able to marginally control the direction of the jump after pushing the button. This was shown to particularly help with the gameplay as users wouldn’t need to do 100% precise jumps every time. After jumping, by moving the movement stick, the character can inch closer to the direction it is pointed in.
Also important to mention is that the jump needs to depend on how long the jump button is being pressed for. This is extremely important because if the character always jumped with the same strength it would be extremely easy to miss many jumps. At the moment, if the player stops holding the input button while they are performing a jump, the jumping arc will be cut short.
Lastly, the camera behavior also had to be changed. As you might notice from the video itself, when jumping, the camera does not follow the character in the air. This was deliberate, as early testing showed that having the camera move so much in the Y coordinate with each jump was jarring and some players complained about it. Now the camera always stays where the character would land unless the character moves up or down too much.
The first steps of making this are not particularly hard, they are however fundamental to everything else. During this first week I implemented simple animation and simple movement. When the player moves one of the joysticks on the controller, the character moves in that direction.
(Edit: I should probably warn that from here on out a lot of these blogposts are very technical. These contain a fair amount of trigonometry, programming and explanations)
While movement and controls are extremely important in a platformer, neither can exist without a good camera that allows the player to see where they are going and what their character is doing.
This camera took me quite a long time to make but it should be mostly futureproof, meaning that I won’t have to go back and change it in the future. The camera, controlled with the right stick of a controller, can move in closer or farther away and rotate around the character at different speeds depending on how far the joystick is held.
It also allows the user to go into a first person perspective to get a better look at their surroundings.
I have encountered some problems. About a week ago my HDD died, and with it all the data I had, including what had been done of the game.
I had been waiting to have done enough to separate a lot of different things in many blogposts but it looks like that is not going to happen. I do remember how most of the code used to work so I’ll try to reconstruct it and post about it as I make it.
This is a pretty big setback but there’s not much I can do about it.
Luckily, model and animations were not lost as they were hosted online. This is also the second iteration of the model, the first one was replaced because of a few problems with its design and animations.
I’m very glad I started working on this early. I might have underestimated how hard it would be to actually code a game from the ground up.
I chose Unity, a very popular free game engine, as a development platform. The choice was mostly done out of ease of access and because of the large amount of tutorials and support available online. I’d like to be sure I’m not going to get stuck halfway through working on this and not knowing how to progress.
For those unaware, a game engine contains a few pre-made mathematical functions that cut some time off development. While the game still needs to be built from nothing, a lot of the more tedious work has been already done, which makes the process slightly easier.
I’ll try to post updates as the game progresses.
Following the insights I received, I finally felt comfortable actually moving into the ideating stage. After many discarded concepts and quick ideas, I finally settled on choosing a theme for the game.
After observing that many games in the genre seem to have their own “gimmick” as far as movement of the character goes, I ended up settling on a character that can dig underground at will. This allows him to climb up vertical walls and to go extremely fast.
The main character’s design was also worked on:
I’m happy to present Drill Boy. His design was derived from many similar mascottes from games my users talked about. There’s a lot here to talk about so I might just leave all the explanations for his design until I collate everything about the project together.
I’ve spent the past week playing games, trying to put into perspective what my users liked and disliked about each of them. It’s been very eye opening.
The most interesting thing is most likely that each one of them seems to shine in different aspects. Many praised the Mario franchise for its controls, some praised the Crash Bandicoot franchise for its art direction. There’s a lot to learn from each one of them.
I’ve got a long list of what to take from each of these titles. I haven’t really put it down into writing yet but I now have a pretty clear idea in my mind on where to start. I think it could probably be a good idea if, alongside the game, I presented an in-depth documentation of all my findings for each game and step I take during development.
It’s been a little over three weeks since my last post. I didn’t feel like writing something new as, up until now at least, I still hadn’t finished my interviews and I wanted to wait until I had all the information I needed before updating this blog. It took quite a bit longer than expected to finish all the interviews, turns out it’s quite hard to agree on a time to meet with someone, who knew.
I do have good news however. My original plan seems to have been mostly on the right track as I have pretty much received all the information that I wanted. I was forced to make a few corrections regarding the people I talked to and what I talked to them about, which was the only thing I hadn’t planned for.
First of all I had to decide on a specific game genre to study. Very early it became clear that I would not have been able to just ask people about their generic experiences with games. While the information might have been generally useful, I need something more focused to be able to actually use it to design and build something. I decided to study 3D platforming in particular, as I am not only very passionate about it but it is also a relatively easy genre to build.
Of course deciding on a specific genre means other changes need to be made. For example, I can’t just talk to whoever I want no matter their age. 3D platformers were extremely popular in the late 90s and early 2000s, this means that the people that had experiences with these games during their childhood were born in the early 90s. This change in particular limited my pool of interviewees quite a bit, but I was luckily able to still find enough people to receive all the insights needed.
I also had to make sure that the titles the people I talked to liked were different. Luckily there were plenty of extremely successful games that defined the genre, so I received plenty of different opinions without really trying.
What did I learn?
First of all, the most interesting thing that came out of this is how these interviews quickly shifted from interviews to just talking about old games and childhood memories. I feel like this helped a lot making the user feel more comfortable, which in return helped with the insights they gave me.
What I basically received was a list of reasons as to why my users used to enjoy, and still enjoy in some cases, a variety of games in the genre. These range from how the game feels, the flow, the art, the sound everything about them.
I’ll be completely honest, I’m not entirely sure what I’m going to do with these insights but I think my next move will be to play some of the games my users mentioned to me. Maybe it’ll help put the data I have into a new perspective.
I don’t have much information to add at the moment but I have outlined how my interviews are going to work. My main goal is to receive as much information as possible about how my interviewees have experienced games during their childhoods, hopefully each one of them will have different tastes which will allow me to receive as much information as possible from many different types of media. Whatever information I receive I will try to contextualise in my own project, hopefully mirroring many of the favorite things the people I interview enjoyed in the past but with a completely fresh spin.
I have also started looking for people locally and internationally. Bolin’s paper illustrates how different countries seem to have extremely different media experiences for both movies and music, I thought I might as well broaden my research scope by seeing if that is also true for games.
So far I’ve asked people from the Dundee Video Games Society, close friends in Dundee, close friends from Italy and on a few online communities.
At the moment I’m very convinced on following the course of action I explained in the last entry. It’s very unconventional, I’m completely aware of that, but I think I should work on something I’m passionate about and I really cannot spend another year working on designing apps that don’t actually work.
I’ve spent the past week rationalising if I should or not choose this as my final project but I’m completely set on it now. My main goal with this is to have something people can actually play with during the exhibition, I’ve been there the past years and while there’s always some incredible stuff in the Digital Interaction section, it really bothers me that most of it is never functional. I want something people can interact with that has some complexity, rather than being different interactive layout pages.
I think my first step now should be looking into how exactly I’m going to receive information from people, what to ask and how to use that information. Once that’s done I’ll try to find candidates to interview.
While looking through articles and papers on a subject I have become increasingly interested in, nostalgia, I found one wrote by Goran Bolin titled Passion and Nostalgia in generational Media Experiences. The paper explains in length how media (mostly movies and music, the article is fairly old) people experience during their formative years (late childhood/teens) is an incredibly important factor that will shape how they act and perceive the world as adult. In the paper Bolin interviews many people from different generations and all of them are able to recall very ancient memories about specific medias they consumed when they were children once presented with them.
This is particularly interesting for me because I’ve been very interested in looking into how old games could shape new ones but have not been able to find a way to bridge the gap between people and design in the context of creating a game. This is a very generic problem, game design really only follows its own rules and is largely disconnected from the people centric design we are taught at DJCAD, it could be interesting to find a way to finally have the two meet.
I’ll try to create some kind of plan to follow through with this.
This blog is going to contain a week by week (or close) progress for my work on my 4th year project for DJCAD. I’ll try to keep it as updated as possible as I go along.
It is a bit early at the time of writing this to start working on my fourth year project (it’s the 16th of April 2017) but I thought that since I don’t really have any other important projects I’m currently working on, I might as well get a head start on my final project.
I haven’t really looked into anything in particular so far, however I am very partial to try and make some kind of game. I’ve been wanting to break into the gaming industry for a while and it would seem like a waste to throw away a year I can fully dedicate to one project for something else. Only problem with this is that I don’t think any of the lecturers would really care that much about a game, people usually just make apps or interactive products for their fourth year.