Whoops?

So I’ve spent the last few weeks making the game actually look like a game.  Usually I’m fine just having random cubes everywhere up until the last week or so because I can usually see the final product in my head. But since I can submit video to a showreel I figured I should probably have some graphics in there by then.

So here’s the difference! First what it looked like 2 weeks ago:

And now with actual things!

Yay!

And that’s what I’ve been doing the past 2 weeks. Also here’s a closer look at the enemy, I call him ‘Tomeyeto’.

Get it? Cause he’s a tomato but he’s also a cyclops.

I’m good at making videogames you guys.

I knew I forgot to do something last night.

So this week was nothing to do with programming and was all to do with the character itself. Modelling, texturing, skinning, and stuff like that. Now this is the first time I’ve used a modelling program in like 3 years or so so I knew this would be fun times. So yeah, lets see what I did!

First off here’s the character, designed by Steve Holt.

Her name is Kayuki, and in accordance with the original post is a shy vampire girl who gets cold easily and dislikes tomatoes.

And here’s the model!

And that’s pretty much it! There’s no real need to go into detail on the model itself or what I did to make it since this is primarily a programming thing, but I’m fairly happy with how it turned out! The facial expression will hopefully be animated via textures and stuff like that so she won’t always be a Nichijou reaction image.

The render technique to get the drawn effect doesn’t work in Unity, so maybe sometime down the road I’ll be making a blog about how I fixed that. Or at the very least came up with another cel shaded-esque effect. I say maybe, because that seems really complicated and I don’t like shaders. Ah well.

Probably the best part about programming is fixing a thing. But sometimes things can break and they actually look cooler broken. This week was pretty much that, as I fixed something, preferred it broken, and came up with systems to break it again.

But, you know, break it in a manageable way.

So, in week 1 I talked about how new levels are loaded. The camera zooms in on the player, and as the camera zooms out, it reveals the next level has loaded in space behind the current level. The camera then zooms over to the new level and play starts anew. It’s a really cool system but due to the nature of rotational matrices, the rotational value of the new level was hard to calculate, and thus sometimes the camera would have to pass right through the room’s floor to get to where it needed to be. Obviously, a problem! A problem that I fixed with way too much maths. So here we go!

Here is a new very basic level, the ending position is in the top right corner. Once the player gets there, the camera zooms in and turns 90 degrees, as the level exit is on the right hand side wall. But, when the camera pulls back, the new level is right behind it!

This gives the illusion (or, rather, will give the illusion) that the player character is just moving through a door to get to the next room. The entrance and exit positions are lined up in world space to give that illusion that the rooms are connected.

Unfortunately, that’s boring. Here’s the same pullback with a few more elements added to it.

Here you can still see the new level being generated behind the current one, but it’s not lined up correctly. It’s slanted and rotated slightly and just a slight bit further away. It adds a little bit of style to the level transitions themselves and allows a certain level of abstraction, and other words I’m using to justify this other than “it looks cool”.

So what’s happening here? First, the ‘fixed’ version.

When the level is completed and the data is getting ready to be overwritten by the new level, it saves a few crucial bits of information. It saves the level position (which is the position of the center of the level), the level width and height, and the position if the player’s ending position. When the new level is loaded in, it also gets the new level width and height, and the player starting position.

With all this data, the code calculates where the new level should be, and I’ll demonstrate that with these hastily drawn images in MS Paint.

So the old level on the left has a width and height of (3, 10), and the ending position of the player is at (2, 0) (positive Y goes down because programming). The new level has a width and height of (10, 8) and a starting position if (9, 5) (9 is the max as 10 is actually a range of 0 to 9 because programming)

The blue points are the room’s positions in world, the one on the right is the one the code figures out, in relation to the one on the left.

First! The code finds what side the starting position is on the new room. The starting position is on the right hand side, so the room is rotated 180 degrees.

It then sets the new room position to the old room position.

Then it minuses the difference between the new start position and the old room position.

Then it adds the difference between the old end position and the old room position.

Finally it adds the size of the walls to the difference, and the rooms join together perfectly.

As simple as it sounds the actual code is rather complex to account for the various combinations of  rotations that can happen. But hey, at least it works!

So now it’s time to break it!

The actual breaking of the code isn’t really that interesting, it adds a random value to each rotational axis within -10 and 10, moves it down a bit and rotates it a bit more in the direction the room is rotated.

Since I can’t explain it well, here’s a few last screenshots, here’s it fixed:

Here’s it with a few extra flourishes:

And finally here’s it with some extra random:

And that’s what the room placement looks like! Hopefully next week I’ll have models to show you. I say hopefully because I haven’t modeled in over 3 years! Uh oh!

Because updating on the 2nd week is for chumps!

So last week I remembered I had a completely other module to create a program and write a report for and it was due that Friday, so I had to focus all on that. Ironically enough it was an AI module, and had to stop working on the AI scripting for this project to go do that. It was stressful and I still don’t really know what the hell I even did for it, but I still got an A+ for the program thanks for asking.

But enough of that stupidity, this is what I’m managed to do this week!

Enemies!

…Sort of!

Here you can see two enemies, one at the top and one in the bottom right. These enemies are scripted to walk around the level based on a string input I give it when the level is initialised. The strings themselves are below.

This means the top enemy (at position (3,2)) will move down two spaces (D), turn to look left (J) move right 5 spaces (R), turn around and backtrack to its start position (TFN), and repeat.

The bottom enemy will move right three spaces (R), turn to look right (K), move right two spaces (R), move down one space (D), backtrack to its starting position (TFN), pause for a brief second (P), look left (J) and then repeat the pattern.

The single character inputs are rather straight forward, but the backtracking code requires three characters for various effects. First off the (T) represents the backtrack itself. What this does is that it looks at all the commands before the T (and back to the previous T if there has already been one) and reverses them. Up becomes down, and so on, to lead the enemy back to its starting position. The second character can be either Y, N or F. This effects the turning commands. A (Y) means the turning commands will stay the same. A (N) means the turning commands will be ignored, and an (F) means the turning commands will be flipped, which means on the backtrack, turning left changes to turning right. The final character represents misc commands, and can be either a Y or a N. Y for the commands will stay the same, N for they will be ignored. Misc commands are any other commands, such as (P) for pause.

This may seem a little crazy and don’t worry it is, here’s a slight example.

RRRJDDLTFN (right 3, turn left, down 2, left 1, backtrack) will translate to:

RRRJDDLRUUKLLL (right 3, turn left, down 2, left 1, right 1, up 2, turn right, left 3)

Whereas:

RRRJDDLTNN (right 3, turn left, down 2, left 1, backtrack) will translate to:

RRRJDDLRUULLL (right 3, turn left, down 2, left 1, right 1, up 2, left 3) (since the character after T is N, the turn is ignored)

So that’s how the back end of the AI works! You may also notice in the image above the enemies have a red cone in front of them, this is the area they can see. If the user walks into this area, the enemies stop their commands and go to where they saw the main character. The enemies can also bump into walls if they somehow end up in the wrong position.

So that’s where the project is at right now! Enemy AI is rather crazy, but when it works it’s kind of magical. Unfortunately is isn’t quite working as well as it needs to just yet, so the enemy AI will be what I’ll be working on still this week. And knowing me I’ll end up completely rewrite the entire code at some point because that’s what I usually end up doing.

Programming!

Since this blog is about my honours project, and because I haven’t really found anything monumental to talk about in terms of design lately, I decided I’d post the progress of the actual honours project now! As the title indicates I’m hoping this will be a weekly check-in, but who knows, I don’t control the future. If I did I’d give myself more than 3 months to make this project. So without further ado, here’s what my project looks like right now!

Look at how majestic all of those Unity primitives are! Gaze in awe at how I’m currently only using cubes for almost everything!

This is the basis of the room. The game will be sectioned off into room ‘puzzles’ if you will, completion of the current room will get you to the next room, and you do that until an arbitrary ending.

The room itself is generated based on a text file, I figured this could be interesting to some people so I’ll go through what each thing is.

Starting with the most logical number, 8. 8 indicated the players starting position.

After 8, it’s 3. 3 indicates where coins should be placed. Coins will be very important in the final project, as it is one of the few methods of luring the player through a certain path I have at my disposal.

The number 4 represents a key, the user can walk over and pick up a key. Keys can be used to open doors. This may take some time to get used to but trust me on this one.

The number 5 is the ‘locked door’, if you try to walk into this space without holding the key, it acts as a normal wall. With the key, however, the wall vanishes like magic! Or rather less like magic and more like I haven’t done any animation work yet because this is the first week.

The cold-hearted number 1 represents walls, and on that note the empty 0 represents empty floor. Very basic stuff!

Number 2 represents trap doors, though it’s not too obvious this early on! If you walk on these spaces, the player cube falls through the floor and lands back at the starting position (number 8).

Finally, you have number 9, the end goal. When you step onto this space, the room is finished.

The camera zooms in on the player character. The player character is probably super happy at this point. Just look at that cube it’s stoked. After the amazing level end animation the camera zooms out to reveal…

…The next level is suspiciously at the right of the screen!

The camera zooms over to the next level, and the gameplay resumes. The more eagle eyed viewers will notice this is the same exact level,.Since the focus of this week was on actually getting the room to generate properly, having different rooms will be a later thing.

So that’s what a week of my bashing my head against Unity looks like! Hopefully for next week I’ll have enemies patrolling the level in some fashion. Man that’d be nice.

I wanted to have a short update about something that’s close to my heart, money.

Something I couldn’t help but reference in my Project Proposal draft was an example of amazing game design in Super Mario Bros. 3. The first level is designed specifically to teach you the new game mechanics in three very simple steps.

1. This is a Mario-ass Mario game.

Look at that goomba, look at those question blocks. Straight away this is a Mario game. Goombas hits you if you don’t move, you die, don’t touch goombas. You can hit the question blocks to get points. Hitting question blocks are good. Awesome lets play some videogames.

2. The smartest koopa placement in history.

This koopa is teaching you so many things man. First you can walk through the sides of these coloured platforms. This is also shown by the shadow effect, and the mushroom placement earlier entices you to walk through it. And then you’re like “Wait a minute, that question block is on the ground, how am I meant to hit that?” You almost quit the game, utterly defeated, but you decide instead to hit the koopa. The koopa in in the perfect position to kick the shell and hit that question block. Since it’s a Mario-ass Mario game you except a coin or a fire flower, but no, you get a leaf. Something completely new! But how does it work? Well guess what the game teaches you that too!

3. Get the gold

Walking to the end of that platform with your new tail and you’re met with floating coins. You can jump and grab the first, but what about the other two? They’re out of reach! You try a running jump, because the level is designed with a completely straight path just before it, and BOOM! Your P gauge hits the max and you’re flying around. All of this is instinct brought upon by the game design itself and the preconceived notions of the game being a platformer or, more specifically, a Mario game.

Speaking now more in depth about the last image of that group, coins are used as an incentive in many games. In fact they may not be coins, Crash Bandicoot has ‘Wumpa Fruit’, the original Jak & Daxter has Precursor Eggs, Sonic uses rings, and so on. These incredibly fruitful collectibles are there to inform the player that they’re doing something right. If the user sees a line of these items, they know that’s the direction they should be going in. In a sense they served the same purpose as an annoying sentence in the top right of your screen shouting “FOLLOW THE GENERAL” or whatever, which is accompanied by flashing lights on the mini-map and dots in the center of your screen telling you about the objective. The only difference is the coins at least assumed a base level of intelligence in the player that they won’t forget what they’re going in the space of 2 seconds.

Just remember guys if there’s an obvious path of coins going in one direction, there’s probably a secret in the other. Those game designers sure are smart!

An application that ventures into game design can only really be fulfilled by actually making a proper game. And as a result my time more recently has been actually designing said game to fulfill two distinct yet incredibly important tasks.

First of, the game has to demonstrate and answer my honours project question. This may seem like a very obvious thing but it is something that has to be at the forefront of every design choice I make. The second, is to make the game fun. Again, something that has to be at the forefront of every single design choice I make. These two concepts will constantly switch from helping each other and hindering each other throughout the course of designing the game. In the battle for the more fun idea and the more relevant idea, I’m honestly having  hard time deciding what should win.

I feel that when my tutor looks at this, his answer would be whatever choices help the honours project, yet I do not think that is strictly true. As an individual who has been designing games for a fair number of years, I have always regarded whatever is fun to be the most important aspect, even when it hinders the project, in the case of university work. A few of my university projects were impressive in some aspects and lacking in others. When asked about this I replied that the ‘game did not need those other features’, despite the fact that added those features would have gotten me a better grade, simply on the fact that it would have demonstrated that I was capable of adding them. I’m sure a lot of people would see this as a flaw in my character, even an arrogance, but unfortunately that is the way it is.

Enter now my honours project, a game that I must make in a few months. I have to make sure to design the game to be able to answer the question I have put forth about game design, while also making the game fun. I feel that this game is the one I can argue about this philosophy the most, for one very simple reason.

In order for this project to be a success, the user most not know what it’s about.

The very idea that the player knows what the game is about with taint the results I oh so desperately crave. This means anyone I talk to about the game, be it friends or classmates, or anyone who stumbles upon this blog, should be exempt from the final data gathering, in order to get a pure result. I realise, of course, this is almost impossible, as there will be people wanting to play the game especially if they read about the concept of it and get interested. But the only way to minimize the amount of tainted results is to design the game with the question hidden in the design.

And this is how I’m going to do it.

I will make a Flash game, tentatively titled ‘Instructable’, in which the user plays a 4 level game, with cutscenes book-ending each level. However, on the first play through, these cutscenes are corrupted. The cutscenes will only play one second or so before they cut to the gameplay, and the player must infer from the gameplay, what to do. Upon one completion of the game, the cutscenes are restored, and the player can now use those to infer what to do. Upon the second playthrough, the player gets another change (maybe being able to read the backstory, or the instructions), and can then go play the game with the further knowledge.

Again, going back to my research question, “how does game design affect what the user perceives as the main objective?”, the player, on the first run, will only be able to determine what they can do from the gameplay itself. The actual data collected will be primarily from their first playthrough, to see what the do.

Here’s an example in case that’s too vague.

The first level starts with a story section, the king looking angrily at a piece of paper, and then cuts to a Super Mario Bros. looking level. The first instinct, I predict, is to play it as a platformer. Once the level has been beaten, the king is even angrier, and it goes to the next level.

On a second playthrough, the story actually shows the king receiving a letter from an evil demon, who reveals she was behind a very recent attack on the kingdom. The king calls upon the main character to ‘help out the civilians outside who are running around in confusion’. The civilians look like the goombas from Super Mario Bros, or at the very least, are their equivalent. With this added information, the first level becomes an RPG, in which you talk to the civilians and help them out. By killing the civilians, as if the game was a platformer, the king gets mad at you, echoing the start of the second cutscene from before. By playing it as an RPG, you get a better ending to that level, and continue onto the next level with more information which will ultimately change how that level is perceived.

In terms of the honours project question, the only differences between the playthroughs is the amount of information given to the player. The player can beat the first level as an RPG without seeing the cutscene, it’s whether or not anyone will think to even do that. The game design will make them think, without any other information, that they need to play it like a platformer.

Or will it?

As insomnia sets in and my sleep pattern changes from something vaguely constant to something more resembling a seeded random value it seems rather appropriate that I talk about videogames.

As I’ve tried my damnedest to describe what I want to do for my honours project to various people, there seems to be a hive mind of general misinterpretation about how I’d be ‘tricking’ the player into assuming how to play the game based on level design. There have been a few games centered around this idea but they take it in the opposite direction. I shall talk about these two games and point out how my project is nothing like them.

The two games in question are Syobon Action and I Wanna Be The Guy.

First off, Syobon Action, also known as Cat Mario. As you can probably assume from the alternate title alone, Cat Mario is a game that looks and plays like Super Mario Bros. The objective of the game is the same, to get to the end of the level in a very platformer-esque fashion  This game very much plays with the player’s pre-conceived notions about how to play a platformer  with blocks flying away from the player as they try to jump and hit them, blocks falling out of the sky as obstacles, and so on. I Wanna Be The Guy takes this concept and amplifies it with a multitude of other games and genres in the loudspeaker. Fake walls, apples that fall downwards (and then upwards), and spikes appearing out of nowhere just to mess with the player. These games are fun, but they are not what I want to do with my game. Far from it. I classify these games as ‘£*($ you’ games, or rather to be appropriate for a blog like this, ‘trial and error’ games, a phrase that I’m sure does describe the game in question, but leaves out all the pent up frustration it causes the player.

So what do these games do? They annoy the player by letting the player assume a lot about the game based on previous gameplay experiences, and punishes them for it. These games give the player a pit to jump over, and midway through the jump drops a spike on them. The player, going on their past experiences, makes the assumption that the pit is the only obstacle. The game dashes away this confidence by introducing more obstacles that they weren’t expecting. This ultimately results in two outcomes. First, the player just remembers all of the extra obstacles. This turns the game into nothing more than simple memory game. Instead of teaching the player how to play the game in such a way that the difficulty increases solely on applying these fundamentals to different situations, each encounter is unique. The other outcome is it makes the player incredibly cautious. Instead of tackling each situation head on, they remember that each situation is unique, and are incredibly slow on their approach. These games have their place, but that’s not the mentality I want to approach this from.

So what does, hopefully, my project do? It just plays as you’d expect, I guess. The best way to describe my approach is with an example, and since it seems to be a theme, lets go with platformer. If the user was given a game that looks like Mario Bros, chances are they’d play it like Mario Bros. And that’s completely fine. My project would allow the player to play, and finish, the level as they would a classic Mario game. However, on top of that, colliding with the first enemy wouldn’t damage the player. In fact, what if then, a speech bubble popped up, and he sent you on a fetch quest? The idea of my game is not to punish players when they assume what genre the game is, but rather, allow the user to do just that, but have the hooks in to let the player realise on their own that there are multiple ways to beat each level.

Maybe, like Nebulous Hero, the game will tell the player after they have played every level that there are multiple ways to beat each level. But that’s me coming from the ‘fun game’ angle, I’m not too sure what that’d achieve in relevance to the question at hand.

I’d say given a Mario looking level, maybe 95%+ people would just play it like a Mario game. But I guess that’s why I’m doing this project, so I can know for sure.

I may as well jump in the deep end and explain what I’m hoping to accomplish over the course of this… course.

My main fascination with games is the gameplay itself, and while a lot of honour projects usually veer towards more technically challenging questions, such as how can you replicate life in a program and whatnot, I’m more interested in actual games. I feel this is mostly because I’ve already been making games, and thus instead of wanting to prove myself in a technical sense, I’d prefer to prove myself in a design sense. What is it about the design of games that make them what they are?

The main point is summed up incredibly well in Egoraptor’s Megaman Sequelitis video, talking about how the game, Megaman X, is designed in such a way to teach the player how to play the game just by actually playing the game.

In a similar sense the first Goomba in Super Mario Bros. is positioned in such a way that jumping over him can result in hitting the first ? block, teaching you to hit ? blocks.

The reason you know why you have to hit the ball back in Pong is because it goes right, and you see the ball bouncing off the other paddle first… Probably, I haven’t seen an original Pong cabinet in years but that should be how it works.

Nowadays you have to assume everyone playing your game is mad stupid, and include tutorials everywhere and instructions on how to play the game wherever you can. Otherwise the player might have to explore, puzzle things out and actually have some form of challenge and you can’t have that.

I tried both approaches in Bullet Bill 3. The main game has four pop-ups explaining how to play the game in the first four levels. But on top of that if the user chooses not to read them, the gameplay itself tries to teach the user about how to play. The level creator doesn’t have any instructions when you load it up, in the hopes that the UI itself is simple enough that people can pick it up with a little experimenting.

However, teaching users how to play the game based on game design isn’t what I want to do. I feel that has already been proven with a lot of games from the past. What I want to do is explore the opposite.

My main inspiration for my idea is a game from the Molyduex Jam called Nebulous Hero. This game, presented as a normal platformer, was made under the idea of “creating a game where the tutorial is unlocked after the credits.” After jumping on the enemies and collecting the coins, you beat the game, and the tutorial reveals “don’t kill your friends and steal their money!”

This sparked an idea in me, and it’s the idea that I hope to explore in my honours project, about how can a game’s look and design dictate what the player thinks the goal is.

In other words, how does game design affect what the user perceives as the main objective?

In Nebulous Hero the fact that there were characters walking about and coins in the air, thanks to games like Super Mario Bros, subconsciously told the players that the objective was to kill the characters and collect the coins. Thanks to the games we’ve already played, the brain is programmed into assuming a lot based on the look and design of a game, but what happens if that’s not the case?

How would someone who has played a lot of games react to that scenario compared to someone who hasn’t played a lot of games?

How can this assumed objective idea be applied to different genres, such as RPGs or fighting games?

I feel this is an area I could have fun exploring and hopefully will provide interesting results.

Lets hope I feel that way after I spend months and months working on it.

Hey everyone, my name is Ian Kelly, probably better known as my online handle Psycosis, and I’m a programmer.

You may know me from other kinds of work, such as flash movies or mashups, but programming is my one true passion. I may flirt a little on the side but I always know who I’m going home to.

I’m currently in my 4th and for all intents and purposes final year of university, where I am tasked among other things to make an honours project. A project that I have to come up with and answer a research question.

It was also recommended that I maintain a blog detailing my thought processes about said honours project, so that I can point to something when I get called out for copying other people. Though annoyingly this blog will probably just dictate the direction to point the finger in as I talk about my inspirations.

Tumblr seems to be either the best or the worst place to have this blog, I haven’t really decided yet. But I guess there’s only one way to find out!