lokythievery

[lokythievery]

Post Mortem

This will be the last entry (for now at least) to conclude our project.

First I would like to discuss what our intended goals were for the end of the assignment and what we planned to have implemented by the end of the twelve week period.

We wanted to have an infinite runner the procedurally generated platforms (check), with procedurally generated obstacles (check) where the player would have to use certain mechanics to avoid them.

The mechanics we planned were jumping (check), sliding (check), attacking (check), swinging (check) and gliding (check). We also had plans to implement a drop mechanic that would cause the player to quickly fall to the floor, but this was scrapped as we deemed it unnecessary.

Being able to succeed at implementing these core mechanics and then playing and having fun with them in the final build is a very rewarding experience. However due to time constraints we were not able to properly implement the store and have potions in game. We also do not have a small tutorial for players to play and instead opted for a tutorial for the main menu. The How to play screen turned out great but it is a complaint that we are having that people would prefer to see tips come up on screen whilst playing instead.

Next I want to talk about the team and how well we worked together these past few months to create this game that we’re all so proud of. 

First of all our project manager Ciaran was amazing at keeping us organised and delegating tasks to everybody, making sure that everybody knew what and when everything had to be done by. He was also great a communicating with the artists and everyone else, making the whole process a lot more easier. He also did a great job at implementing his own mechanics into the game, like the biom generation and was always generally helping wherever he could.

Next we have Bogdan who has been one of the main driving forces of the game, being lead programmer and doing an incredible job at implementing the many features and mechanics of the game into a workable build comprised everyones code. His knowledge of both C# and unity have been an essential asset to the team, and the game simply wouldn’t of turned out the way it did without him.

Last but not least when have the art team Hanin, Max and John who were working hard with us to create colourful, stylish, memorable and just beautiful asset for the game. The assets they they created were one of the most important features to have in the game as they are what gives the game character. Going so far as to create back storeys and personal profiles for each character. It’s hard to get people to care about a game without a griping narrative and thanks to the artist, we believe that we’ve now made it that much easier.

I think I can safely say that everybody involved is extremely happy with how the game turned out and we have all also decided to keep working on Loki Thievery throughout the summer with the eventual goal of releasing is on IOS and Android. Had we had the chance to start over again I would of worked on my own time management skills as there are still thing that need to be put in the game that we simple didn’t have time to do. I have also learnt many new thing in C# and unity that had I know at the beginning would of made a lot of thing a lot less painful and time consuming, but I now know these things for future projects and cant wait to get into the next one.

[lokythievery]

Main Menu - Part 5

Since my last blog the art team has been hard at work yet again, giving us more unique, original and inspired assets to add into the game. I will go through all of the additions to the main menu that I have made with the artists help.

First off in the Start Menu we have added new button textures with their own unique font, to have them stand out more and look less generic. The direction planks on the side of the screen have also been updated with the same aesthetic.

Next we have an updated version of the Leader Board, while it was nice to be able to create my own layout with the assets that I had previously, it also had its draw backs. 

I was running into an annoyance where I would try to rotate one of the sprite assets and it would distort and twist the image, I tried my best to re-scale these images to look normal again but they still looked a little off. Having the artists create the layout in Photoshop and simply send me one singular image made this a lot easier and made for a far more authentic look. Not only this but as I used to have many objects on the Leader Board screen that would be moving with the menu this would cause more stress on the CPU and a performance drop.

We also received a pre-made layout for the options menu as well, a big step up from the original options menu which was just a simple orange background.

The How To Play screens have also been simplified with the assets, although even though that’s the case I much prefer the newer version. In the images below we have multiple screens that show Rubio holding pieces parchment. The drawings and texts are now separate objects, which makes it a lot easier to size everything into a much more pleasant and easy to read form.

On a side note, although I cant show you, the swipe fingers are also animated and swipe up, right and down. I did this the same way that I move the clouds in “Main Menu - Part 4″.

Lastly we have upgrades to the in game shop, no new items yet but I have added a coin counter in the game which adds the coins that the player has collected and gives them their total. This was done by adding the coins collected in any given run to an integer in the binary file where we save our high scores. Simply load this integer and we have our coin total which is now display in the top right corner.

We have also add a place holder piece of dialog for the play testers to enjoy.

With each passing day the menu is looking more and more polished, and not just that, my colleagues have also done an amazing job at implementing their mechanises and ideas into the game as well. We are very close to completion on the 12 week assignment and I could not be happier with the progress we have made. There are a couple things that I would like to fix and add (one of which is adding a credits sequence to the menu) but so far so good.

[lokythievery]

Post Mortem

Hello everybody,

Are you ready for the last entry? Time to conclude this project.

So I talked last time about the team and how we worked on the project, how the roles were distributed and how communication was crucial. This time we’re going to have a look at the finished product and talk about what could be improved in the future.

First, let’s see how much of the initial design was achieved.

The main idea for the design and the theme of the game was to be an infinite runner that depicts a thief who escaped from Asgard with a bunch of loot, and who is running away from mythical guards.

Well, we now have Rubio who is definitely running away with his nicely animated sprites, jumping around on floating platforms in front of the great Yggdrasil. SO, I’d say check for that one.

Then there was the idea of the four main mechanics that allow the player to navigate the level: Jump, Slide, Attack and Swing. All of these were successfully implemented and integrated into the procedural level. There was also the idea of a possible ‘Drop’ ability... but it ended up being scraped. So, overall, I’d say check to this one, too.

Now regarding the multiple biomes... it’s quite 50-50 on that one. We do have multiple types of tiles that are spawned based on a biome system, but I would have liked the obstacles to be biome specific, the background should change maybe and even the time of the day could be changed - at least that was the original idea. So the game isn’t at it’s full capacity on this front, but we keep learning every day.

The obstacles that we ended up introducing were very good in terms of aspect, the artists did a tremendous job on that. But we, as programmers (particularly me), fell a little short, as they were able to add ‘breaking’ animations by the end of the semester, feature which did not have time to be implemented. So the attack obstacles should have a breaking animation (like the pots and pillars) but they don’t.

Last but not least, the UI looks great. I remember the initial design for the menu, and I can say loud and clear that the final result surpassed the design by far. I mean, yes it is based on a ‘swipe to change screen’ principle, but with Alex’s implementation and the great assets from the art team, we were able to achieve an amazing Menu. I am very proud with the first impression that the game gives when it is opened.

You can’t tell from here, but the menu has a fully animated background, as well. So there is nothing that could be improved here... at least in my opinion. Big check on this one.

Finally, the game was supposed to be distributed on mobile devices, which was actually done. We haven’t published it on the market, but we do have an Android Build ourselves, and let me tell you... it looks and feels awesome. Playing our game on a tablet feels extraordinarily smooth. One last issue that we found on the final build... there’s no exit button. Yeah.. so there’s no nice way to close the app, you have to force quit. Live and learn, live and learn.

That’s all folks! I hope you enjoyed this development journey that you went on together with your favourite programmers. And I hoped you learned a few things with us.

Keep on developing,

Bogdan

[lokythievery]

Final Pitch

Since the start of this twelve week assignment we have had an eventually goal to present our game to both or tutors and class mates and then to pitch it to them as if they were potential customers. Over the passed few days Ciaran has been hard at work creating a beautiful presentation which incorporates many of our artists assets, to not only make it stand out and be more memorable to everybody but also to fit in with the aesthetic of our game (as you will see in the images below.

As you can see we have reused many assets from our main menu. As the lead designer I was in charge of presenting the design aspect of the game and also the market research that we had done. My slide we as followed...

So I started off by talking about what an infinite runner was and way they are so popular, the reasons I stated were that they are very easy to pick up, hard to master and require little to no time commitment to play, this means that every kind of person is able to enjoy some aspect of it.

We then talked about other potential competitors, of which there are many for infinite runners on mobile but only one noteworthy one that shared a similar setting by the name of “Asgard Run”.

I went on to explain that even though the games shared the same setting they were far from the same game.

Then I got onto the design.

Talking about the main menu, with animations and colourful art style. It’s also worth noting that I decided to talk about the main menu before I start talking about the game as the main menu is what people will see first when playing.

Talking about our Leader Board.

Talking about the options menu complete with working volume sliders and also that the pause menu works in the same way.

Talking about the in game shop and explaining that we plan to add further items that will keep drawing people back in.

I then talk about the premise of the game and introduce the characters, starting with Rubio

Then the pursuers.

Then I talked about the different obstacles that Rubio would have to overcome.

And then explained how they could achieve that with our in game tutorial.

Then we showed the gliding phase.

And the different bioms that the play would be thrown into once ending the gliding phase.

We then explained that we had plans for the future to make way more noticable changes when entering new bioms, like changing the backgrounds and adding more floating 3D elements.

All in all the pitch went splendidly, despite an error we had with the presentation which cause the power point to crash for the first minute of or pitch, but we kept our cool and gave a very convincing and persuasive pitch that came back with good feedback and a round of applause. Some criticisms were that the background didn’t match the rest of the game and also that the swipe controls were not as responsive as they could of been. These are thing that we shall work on to create a great game that we can hopefully one day release to the market.

[lokythievery]

Programming Final - Part 13

Hi all,

I’m back with some more info on our Game Design and Development Project.

I know the post is titled ‘Programming’, but it’s not going to be programming this time. I do this out of consistency - since this is my role. In reality, I want the readers to be able to tell, right away, who is writing this post, as we all publish to the same blog.

This time I’ll be talking about the overall evolution of the project in the last Sprint. As you know after the three prototypes that we developed over the first six weeks, we moved on to a Final Stage, where we had to create a vertical slice of the game that we incubated initially. A six-week sprint, to take over the world, right?

In short, the project went smoothly. I mean, the evolution of the project was constant and always in time. Besides the great work that all the members put in this project, I feel like the main aspect that made this game so successful is the Communication.

I cannot stress enough the importance of a collaborative team. I used to work for a small indie studio before I started my studies, and having all the people in one office, where they can instantly get ideas bouncing around and get immediate feedback from each other, makes a huge difference.

In our case, things were a little different, as we didn’t work in the same space and we had other modules and projects to tend to... But keeping in touch constantly, really showed by the end.

As far as the art team is concerned, I am more than pleased with their work. I think the right word would be impressed, but I don’t want to feed their ego to much. So, originally, there was a role amongst the programmers, which was titled ‘Art Coordinator’, who was supposed to keep the programmers’ team and the art team in touch, but that’s not how it happened.

I think the Project Manager is the one who got the ‘art coordinator’ title... so I have Ciaran to thank for his excellent approach regarding this matter. Instead of keeping the whole ‘meeting with the artists’ attribution to himself, he let us all have the meetings together, where we were able to discuss everything freely.

You might think that this way, you have three people attending the meeting instead of one, and it might be a waste of time... but in reality, this way, the ‘art coordinator’ doesn’t have to explain again everything discussed, once he gets back to his programmers... and this way everyone is on the same page. Not much room for misunderstandings.

All in all, our team worked excellently together. I was very happy to work with Alex as a Designer (as he did a tremendous job with all the menu mechanics and the UI) and with Ciaran as a Team Manager. He did a great job keeping everyone on track and handling those meetings and the preparations for the presentation. Again, it was a pleasure working with the Art Team: Hanin, Max and John.

We actually decided we will continue the collaboration over the summer, as we need to polish the game just a bit more for it to be good for release. Also, we decided on a name for the studio....

Are you ready?

It’s called ‘Space Corn Studios’, and this is the logo.

I hope you like our work, as we are closing in to an end in this dev-blog series. And I hope you’ll support us further down the road as we fly off into the Space... of Corn.

Till next time,

Bogdan

[lokythievery]

Programming Final - Part 12

Hello folks,

We’re getting closer and closer to the end of the semester and now it’s time to make a final presentation on our project. Remember we had to incubate the original design and then present it in a short pitch fashion. Well now it get’s a little more intense. We need to make a 10 minute presentation, and all of us need to take part in it. We also have to be very careful with the time as we are penalised if we finish too early or too late. Did I mention we also have a 5 minute Questions and Answers session at the end? Yeah, we have that too.

So, in short, we need to have an elevator pitch in there, a few marketing and design elements, as well as programming, testing and team collaboration.

After a few discussions with my teammates, we arrived at the conclusion that we should split the presentation equally based on our roles, so I had to cover the Programming section. It shouldn’t be too big of a problem, right?

Now, it might not seem like a big deal to you, but we took this matter very seriously and we had many discussions in order to get everything right. Our Trello and Facebook were on fire. We had daily meetings for about a week. We made sure that we know who goes when and we made sure that the images and the fonts are consistent. Well, to be honest, Ciaran took care of that. But everyone still had to provide the materials.

Before I go on with the programming section, I have to tell you that I also received the Elevator Pitch section, which is one hell of a bit to do. I ended up doing it, because I was the one who wrote it... but I didn’t think initially that it would be that hard to memorise the lines and also act out the presentation.

The reason I have to act it out is because it’s meant to be super energetic, with about seven slides in 30 seconds... so it has to be extra snappy and the one who presents it needs to be excited enough to draw everyone in.

This is how the Slides look like - just so you get an idea of the theme.

So, regarding the programming - I took some time to think what would be the best approach. One might want to cover some code or maybe a few of the methods written.. but I don’t want people to look at my code without understanding anything and then move on. You can’t really explain what’s going on in a few lines of code, because of the time limit... so what should I talk about?

In the end I decided I’ll have a few slides that cover the generic concepts that were implemented. So what are the essential mechanics and inner-workings that make our game tick.

Of course, one of the main points is the procedural level... quite an obvious feature for an infinite runner.

Then we have our clean and efficient Software Architecture. And last but not least, the crazy useful math that makes our game so special.

In terms of Procedural Generation, the key elements are the Chunks that spawn with the right mesh on. So that they look like they belong to the active biome. Then we have the Obstacles that are obviously spaced in a smart way, so that the player can clear each platform. And in the end, we need to make the level more and more difficult, aspect which we achieve by accelerating the movement speed.

When it comes to software architecture, we’re talking about a properly encapsulated code, that provides only the appropriate Methods and Properties from each Class. Basically, when you have a group of programmers working on the same source-code, we need to make sure we follow a strict set of standards. Then, we’re using some cool software design patterns - mainly Singleton, which is used for Classes like the GameManager or the LevelManager.

Then we have a few optimisation factors, the most important being the pooling system which allows us to recycle the tiles over and over. I talked about the pooling system in more detail in a previous post.

Than we get to the fun bit - the Mathematics. This is the area that is deemed the most difficult by most developers, but for me, this is the best bit. I mean computers already make everything into numbers, no matter how high-level of a programming you’re using. Then, the best way to optimise and write code properly is to talk in a language that is close to the computer... no, not binary, MATHS.

So, of course, the platforms are placed in a neat way, by calculating the time gap needed for a length gap, in respect to the speed of the player. Then we use a dope trigonometrical system that moves the player on an angle basis rather than a linear translation. And in the end, we have the coin system, which is the probabilistic wave system that I discussed before.

And that’s about it. Do you like my content for the presentation? I hope you do.

I’ll see you on the next post,

Bogdan

[lokythievery]

Programming Final - Part 11

Hello everybody,

Let’s talk some more Game Dev.

So remember we had some discussions with our Project Manager, Ciaran, about getting the game tested. So a few weeks ago he made a nice feedback form (everybody loves feedback forms - especially in University) and we sent out a build of the game together with that form to a team of testers. I think it was the first Alpha version that we had tested... which is ok because all the mechanics were implemented at that point.

So recently we got back the results of the testing and we made some reports of the feedback... you know nice statistical graphs.

We didn’t get as many responses as we would have wanted, but this is not a problem because we had the game played in our course and we were given plenty of verbal feedback to add to these results.

Long story short, the level was deemed too difficult for beginners. Meaning that the platforms are overpopulated with obstacles for the beginning section.

That’s not a big issue. The game is properly implemented so it is flexible enough to accommodate a greater minimum distance between obstacles, so that the players have a bit more room in the beginning. Of course, later in the game this distance will end up being shrunken down to the current one, as this is an achievable distance, as it it.

I can guarantee it, as I can clear all the obstacles. But then again, I’m the developer... so yeah.

The other big concern that was mentioned over and over again is the coin placement. You wouldn’t think that a small reward system like the coin system would have such a great impact. I mean the main goal of the game is to travel as far as possible - the coins are only for extra credit... maybe cosmetics and power-ups in the future, but still.

So what’s the actual problem? Well, the players are bothered by the fact that the coins are not spawned in sync with the obstacles and so they would have to break the natural flow of the level navigation to get those coins... Essentially they want the coins to emphasise the path that needs to be taken, rather than making the player go out of their way for them.

I have already talked about the coin generation system. You know it works on a nice mathematical wave probability system... And I was quite proud of it too.

But the client is always right so we’ll have to look into making the procedural generation more in-sync with the level. Now this is quite a challenge since the level is procedural... but, you know it, anything is possible. We just have to put our minds to it.

So what would the solution be, you ask? Well I was thinking of an obstacle driven system. Wherever there are obstacles, they would spawn some coins around them as well. Also, where there are empty platforms, we can have a nice line of coins to validate the fact that all you need to do on this platform is run on top of it. I haven’t written the system yet but here’s what I want it to look like.

This is how I think the players imagine it should be.

Talking about coins, we now have a Diamond implemented. It’s a rare treat and it’s worth 10 coins.

Well, as you can see, testing is important. Not just for functionality, but also for appeal. You never know what the players want, until you get the game in their hands. So keep in mind to test as often as possible and cast a net as wide as you can. Get everyone to play it. It does miracles, trust me.

I hope you liked this post on handling feedback. I’ll see you next time.

Bogdan

[lokythievery]

Volume Sliders

So before I got into the code I added the sliders into pause menu as a place holder for later.

A very simple design but it gets the job done.

So the issue I was initially perplexed by was how I would change the volume slider in the main menu and then have that set volume carry over into the next scene and vise versa. I thought about maybe using PlayerPrefs to store these values but then I remembered that we already had the infrastructure in place to save the floats for our volume sliders in te form or our binary file reader (Main Menu - Part 3).

By creating a method for the sliders to use (see image above), I was able to pass a float into the save method for our binary file. When we press the start button all we need to do is load the binary file, check what the volume value is and set the audio source in that scene to be the same.

[lokythievery]

Pause Menu

Hello again. This will be a small blog to show the implementation of the pause menu that I have been working on. All games need a pause menu and infinite runners are no exception, after all you wouldn’t want to ruin a good run because you had to urgently do something else quickly.

Once fully completed this pause menu will include features like changing the music and FX volumes and returning to the main menu. Returning the player back to the main menu is simple enough this small bit of code.

but the volume is going to be a little more complex (I will talk about this in my next blog), for now I am going to make sure that we can actually pause the game.

In any normal project I would usually just set Time.timescale to 0 when paused and then set it back to 1 when we resume. but in in our game we gradually accelerate the time scale over time meaning that it is not equal to one.

This is fine as all we need do wrap the acceleration code in an if statement like so.

By using some art assets that our artists had created and making the aprropriate code to set the different objects to be true or false, we now have a pausing game. Although a simple feature it is definitely a necessary one and I will be making further progress on it in my next blog.

[lokythievery]

Programming Final - Part 10

Hi all,

We’re back with some more mechanics! Are you ready?

So, last time we discussed about the movement of the background and I even mentioned the fact that it should move slowly as it is the furthest plane of the view.

Well now it’s time to continue with some more elements in the background, for a more immersive experience. We’ll add some Hills, some Fog and some Clouds. Remember that the movement speed is a key element? Well, what I’m talking about here is the Parallax effect.

As you can see in this generic GIF, the objects that move slower give the impression of being further in the distance. So, as I said earlier, the singular background image should be moving at the slowest pace.

Now, for the rest of the elements, they should move faster and faster with each layer, and , eventually, if we get to foreground elements, that are closer than the player, they should move faster than him.

A good example of foreground elements can be seen in this extraordinary 2D pixel art game “Into the Rift” - absolutely amazing.

Stunning work... now let’s see how this effect should look in our level.

So we have clouds, fog and hills, all on different layers.

Now, I actually placed those layers at different points in space, specifically for this shot. In reality, thy don’t need to be. That’s the trick with the Parallax Effect. The object are not actually further away, they are at the same distance, just moving with different speeds.

Now, that’s quite easy to implement with the offset mechanic that we used last time for the background image. And that’s exactly what I did for the fog and for the hills. And I took the shortcut because they don’t need to move vertically and because they will always be at the same Y coordinate. But for the Clouds?

Now this is where things get tricky. I don’t want the Clouds to be a simple scrolling layer. I want the sky to be more dynamic. So how do we do that?

Well, we need the clouds to be individual objects that can take ‘distance’ as a parameter, and then, based on that, they would adjust the scale of the sprite/image and the movement speed, but not the actual distance from the camera.

So all we need now is a Manager, that has a reference to a whole pool of Clouds and who is able to tell when a cloud is out of the view and reassign it. Very much like the tiles that are recycled in the main level. It’s quite straight forward, right?

This is the ‘BackgroundManager’ that deals with all that. And what it basically does is: it takes every cloud in the scene and checks weather is gone past a left limit, then it chooses a random value Y from a given range, and it teleports it there. Clean and to the point!

The result is as expected. No problems whatsoever.

In all honesty, I did such cloud systems and Parallaxing backgrounds before, when I was working on a Point-and-Click adventure game. There, everything is a 2D illusion of space.

That’s all for this post. I’ll see you on the next one.

Bogdan

[lokythievery]

Programming Final - Part 9

Hello everyone,

Let’s get back to some more programming.

The next feature on the list is the moving background. Essentially, we need to move the background image from right to left, in order to create the illusion of movement through the environment. Easy enough... but there’s a few tricks that we need to look into for this feature.

First, since the image will move continuously, we’ll eventually run out of background. I mean the painted background can be so long. Solution? We have the same background loop over and over again.

Won’t this be obvious, you’re asking? Well if we move it slow enough, since it is the furthest plane in the scene, it should look fine with a slight motion applied. Just enough for the player to feel a sense of progression.

But there’s a catch to this... for the loop to be seamless, we need the asset to be perfectly tileable. And that’s exactly why we asked the art team to fix the edges of the background so that it fits perfectly on the sides.

Have a look at it.

So how are we going to make it move? Well, we could simply translate the plane in the scene space, with a short piece of code. But will this work?

Sure it will. The only other aspect that we need to consider is the fact that we need a second background that comes from the right to complete the missing content from the first background that is exiting the view.

And when the second background runs out of content? Well, then what we usually do is teleport the first background, that by this point is completely out of the view, in the right position on the right-hand side of the view.

As you can see in the right corner, the camera is basically rendering both planes in the same view, each of them completing the other.

This mechanic can have a slight issue when teleporting the planes. Since Update() is called at different times, depending on the CPU frequency, the decision to teleport the plane can be made at various times. So If you teleport it back on the right side, at a very specific position, you might end up overlapping them, or leaving a gap... due to the lack of precision. This can be fixed by translating the plane by it’s width rather than using a fixed position, this way the planes will always have the same offset in between.

I have learned everything about this mechanic from a really good book for Unity Beginners, a few years ago. The book’s called “Unity 3 Blueprints” by Craig Stevenson and Simon Quig and it’s a very good read for starters. The problem is that since Unity is constantly updated, the book might not be very relevant considering it was published in 2011.

But it’s been years since I’ve learned how to implement this mechanic, so how can we make it better and more optimal with all the new knowledge of the past years?

Well, the immediate approach is to have a background that is not moving, and just has the pixels rendered on the other side, once they exit on the left side. This way we kinda play with the source of the image. Which is in the realm of Shaders.

One way to go about this is to write a custom shader, but that would take a lot of time and patience and a lot of explaining to do. Luckily, we have a few parameters that we can tweak on a standard shader. Let’s have a look at that.

First we need to make sure we’re using an Unlit/Texture shader.

And there you can see that it uses an Offset parameter. This will move around the pixels in a scrolling fashion, which is the desired result. Good thing is we can do that from the code as well, so we can automate the offsetting.

Then we need to make sure that the texture is imported with a Repeat - Wrap Mode, so that the pixels are indeed moved on the other side, when they exit on one side... much like the snake game, remember?

Now all we need to do is constantly change the offset in a script, and voila, we have a simple scrolling background that never fails to display the right content.

That’s all folks, I hoped you enjoyed the post. Have a good one.

Bogdan

[lokythievery]

Programming Final - Part 8

Hello folks,

Are you ready for some frustration? Crazy Bug Time!

You know how I have a secondary role as a Tester, right? So, the other day, one of my colleagues - Alex, told me that he’s implemented the Menu Scene, and he’s been playing the game through it’s natural flow: Menu - Play Game - Start the Level... easy right?

But every time when he starts the scene from the menu, the first platform is out of reach.

You instantly die, you pres restart... and, Lo and Behold, the platform is now within reach. Great! When we restart, everything is normal. So where’s the problem? Why does it occur only once?

Let’s play and play and stare at it... maybe I’m missing something.

This is how it should normally look. A reasonable distance, easy to clear.

Playing the game scene is how I’ve been debugging for a good while. As I am working on the main Mechanics of the Game, I’m mostly playing the ‘Main Scene’. So I didn’t bother much playing the game from the ‘Main Menu’ once it was implemented.

But once you start from the actual beginning of the Application...

The distance is too big. I know it might be hard to see. And I know it looks like a game of “Spot the Difference”, but thrust me, it’s too big of a gap. And, essentially, you can’t clear it.

But why?

These types of bugs drive me up the wall. Same code, same scene, same assets. No options or parameters changed... it’s just that the scene is played from the Menu, instead of on its own.

I spent a good day analysing the situation. Looking at all the factors... It took a while to even diagnose the issue. I went through the base code left and right... and I couldn’t find anything. A bug like this can really get on a programmers nerves.

Code looks fine. Here’s the Generator.

Clean and constant. Nothing should be different.

So after a good day of debugging I have arrived at the conclusion that there is nothing to be fixed... nothing to fix at all. So what’s the solution? Well, let’s make the initial platform a tad bit longer, so that the gap is not “un-clearable”. This fixes the issue of the initial gap, and it even looks good the first time you play the level. On the flip-side, when you restart the game, the gap is smaller than a usual gap.

Damn... we’ll just have to accept it. There’s no other way!

And trust me! I’ve tried EVERYTHING!

This is the sketchy result.

Smaller gap, as I said. It’s not the end of the world, but still... why did it have to be there?!

So my guess, regarding the issue, is that the time starts flowing (and therefore the platforms start moving) before the Pooling is done. Since there’s a bottleneck on the CPU when we instantiate the whole pool of assets, the Generator will take a while to prepare the platforms, so it will spawn the first platform later, thus making it impossible to reach.

When you restart, Unity might be smart enough to not destroy the pool from the memory, recycling the objects and avoiding the bottleneck. And so, that issue is gone in the second run.

Also, when you play the Scene directly, the time of the Scene might not start flowing until the pool is done, and again the issue is avoided.

But still, that’s just my theory. I have no idea if that’s true... just my best guess.

That’s it for now. Keep away from the bugs.

Bogdan

[lokythievery]

Programming Final - Part 7

Hi all,

Time to look at some more mechanics. Are you ready?

So recently we received the Spritesheet for the guards animation and now it’s time to make the Guards an actual thing.

The idea is to have the Guards chase the player, and as the player hits an obstacle, the Guards will get closer. Much like a health system, but in a threat-level fashion.

Here are the Guards we’re talking about.

Pretty cool, right? I mean, let’s not forget about the Flying Goat - the real threat in here.

Now let’s get to the mechanics. So what we need is to have the Guards get closer and closer. Alex already implemented the threat system, which is basically a number that goes from 0 to 3. It increases when you hit an obstacle and it decreases after a number of second, if you have a clean run. Pretty simple, right?

I would also like to mention now the importance of such an approach. When you’re working with a team of programmers and you implement a mechanic that you know it will have to be elaborated at a later point, either by you or a different programmer, it is absolutely paramount to leave such outlets. It’s like leaving a socket in the wall when you’re building it. You might not be building an appliance right now, but you know it will go there at one point. For programmers and game devs in particular, it is crucial to have such a good foresight.

So far, we only had a flying rectangle, which became known in the class as the “Scary Red Rectangle”. It’s finally time to change that placeholder.

Simply enough, we’re going to make a Script called Guards and attach it to the object in the Scene. Now we want the object to move to certain points, but more than that, we want it to move smoothly, kinda like easing in and out of the motion. This is achieved by making the object linearly interpolate between it’s position and the target position.

This is what I’m talking about. A linear interpolation that shows three steps with a 0.5 interpolation argument. As you can see we always go 50% of the distance, this way we get closer and closer, but slower and slower. The problem is that one can go on and on forever. Since you never travel the whole distance, you’ll never get to the destination (I think there was an ancient philosopher called Zeno that explained this concept with a turtle race, and it blew everyone’s minds). But yeah, that’s why we need a condition that says, ‘if you’re really close to the target, consider it done’.

This is what’s going on here.

The second ‘if’ is basically adding a sin wave to the object’s position... so that the Guards will fly in a nice wavy pattern.

Now that the movement is defined, we need to give the object the actual targets. We could do this by requesting a list of Transforms (which are used to extract the Vector3 positions) in the Inspector in Unity, essentially using the Scene references as the targets... but we’re too good at maths to do it that way.

So what we’re going to do is take the ‘ThreatLevel’ that we have from Alex’s code in the GameManager and use that as a factor in the target. If we play with a few Vectors and a few Coefficients we can arrive at a formula that defines the desired position of the Guards.

This is how it looks like... and it basically drives the whole mechanic, as expected.

Long story short, we have a left displacement that places the object outside of the view and then we add a right displacement that is proportional to the threat.

All this is possible with a simple call to the guards’ method SetTarget() - talking about proper encapsulation.

That’s it for now... I hope you liked this short trip to the land of Maths.

Till next time, yours

Bogdan

[lokythievery]

Programming Final - Part 6

Hello everyone,

It’s time to resume the work on the game development.

This time we’ll look at the asset importing pipeline.

Recently we had a few debates within the dev team regarding the pots and plants that we use as obstacles. The problem occurred when we played the last version of the game. Basically, the models were not suggestive enough, and even if we knew which were the jump obstacles and which were the attack obstacles, we still felt compelled to jump over certain obstacles during gameplay. In other words, plant too short - will try to jump over it.

And so, we requested a few other models from our awesome artist, and we ported them into the game. These models come as an FBX, which is quite a general format, so we can just drag them into the project and Unity will recognise them.

But then there was a problem, as soon as you’d drag one of the models into the scene... there was nothing.

After a few seconds of looking around, I realised that the first thing you need to do when importing an asset is check the import settings. And this advice goes for everything, not just 3d models. The issue here was that the length unit in Maya is different than the unit in Unity, so the models might come out at different dimensions. Good thing is that even if they have a different size, the proportions are kept intact, so it’s just a matter of scale.

After a bit of trial and error, I found that a size coefficient of 20 works perfectly fine.

Besides this, it’s always a good idea to check if the Rig is imported correctly, as well as the Animations.

Now that we have our objects visible in the scene, we can... wait a second, why are they all white?

Oh no... the models are in, but the textures are not. This is an issue.

We contacted the artists, we asked for a new export, making sure that they have the textures attached, as well. Reimport everything... and still nothing.

After an evening of frustrations and trial and error, I decided to create a new Material manually, and attach the png textures to it. Not a big deal, but now... will it work? Well, I dragged the new material on top of my object and there it was... working perfectly.

Luckily, the model kept the UV coordinates on the vertices, so the object was able to extract the right texture out of the material.

This method of using one texture for multiple objects is actually an optimisation method. It eases the load on the GPU by loading just one texture in the buffer, so it’s quite popular. I think it’s called an Atlas in Unity. This is how it looks like.

Shout out to our artists for their awesome work.

I hope you liked this showcase of the asset import pipeline and I’ll see you soon.

Bogdan

[lokythievery]

Main Menu - Part 4

Since my last blog I have added many assets that our team of artists have supplied us with, so the following blog will be a recap of everything that I have incorporated into the latest build of our project.

Firstly our extremely talented art team have made a new main menu screen for us, complete with it very own animation.

The animations which shows our two azgardians Quartzo and Verida looking out for our theif rubio is comprised of many images, by using Unitys animator I was able to play them all back on a loop (The as I did in my Programming V3 - Part 4 blog). We were also gifted some cloud assets which you can see in the background, by assigning them the appropriate layer and giving them a move script I was able to create a convincing scene. 

Once the clouds hit the box collider on the right they will be moved back to the other side of the screen, creating a continuous loop.

As you can see by the first image I have also added two more buttons, one is the Credits button which doesn’t do anything as of yet, but the other is our in game Shop.

By using the same lerping techniques I have used for the rest of the menu functionality the shop should swoop on screen, here (we plan to add more) the player will be able to purchase potions and other cosmetic items. In the top right is where the players currency will be shown and the cat in the bottom right will have speech bubbles to interact with the player.

Next we have the new and improved leader board screen, which again thanks to our artists is looking a lot more professional and like less of a placeholder.

Through user feedback we have heard that the text is too small which I will be changing once we move on to a newer version of our game, but apart from that its really shaped up well. Adding assets like these into the game really gives it a lot more character and make for a far more enjoyable experience for the player, especially with the last addition to our menu, the new How to play screen.

Here we have rubios make shift office where he makes all of his notes and leave all of his mess from his many heists. We decided to have the tutorial screens on different scrolls that look like rubio himself had drawn. In the future these will be animated and small tweaking to things like the text size and the object layout will be made.

You might have also noticed that we have installed a new font into our game which looks a lot more fitting then the default, apart from that you are now fully updated. The menu and the rest of the game is coming along nicely and is really starting to look like a finished product, but there are still thing to be done.

[lokythievery]

Programming Final - Part 5

Hi again everyone,

I’m back with some more programming stuff. Are you ready?

Last time we talked about carefully delegating tasks that don’t interfere with each other. Well my colleagues did a great job and developed their respective mechanics in due time, so now it’s my turn again to integrate the new functionality.

On Alex’s side of things there isn’t much work to do as he worked on the Main Menu Screens, which is implemented now based on a nifty swiping principle. The backgrounds are just placeholders for now, but I’m sure he’ll talk about this in more detail in his posts.

On Ciaran’s side of the project the things get a little more complicated. He’s task was to develop a system that reads the active Biome, which is being changed when the player reaches a flight section, and changes the platform set that is being spawned. This way the flight section will act as a separation between ‘episodes’.

So what exactly does that mean? Well, first we need a bunch of assets that look differently from each other. Not a problem! Our awesome artists have provided a very good set of platforms, all modelled and textured properly. Then we need to switch the actual prefab that is being spawned inside the code base. Ciaran did a great job by getting this mechanic to work together with my existing code inside the PlatformGenerator class, which ended up looking really cool.

Now, since I had to integrate all this stuff myself anyway, I decided to improve the mechanic a tiny bit. First I made sure that the functionality is encapsulated properly in a method, for a clean and neat software architecture.

Here’s the method that sets the Tile’s mode inside the Spawn Platform method:

You can see that the Tile is being activated based on it’s position in the chunk and the ActiveBiome that is available in the GameManager. This way we make sure that the actual tile is part of the relevant biome and also it is either the beginning of a chunk, a middle piece, or the end of the chunk. Cool, right?

Moreover, I was worried that if we create a new pool of tiles every time we change the biome (so at every flight zone) we might get a frame rate drop... especially on mobile devices. So I ended up creating a larger pool at the Start of the scene, which contains all the possible tiles that can be spawned. Optimisation to the win!

Here’s the final result.

Cool right? Oh yeah! I also added a new background from our very own artist crew.

I hope you guys enjoy the progress as much as we do over here!

Till next time,

Bogdan

[lokythievery]

Programming Final - Part 4

Hello everyone,

Long time no see! We got a little caught up with the development and didn’t post much lately. But here we are again, so let’s get started.

Last time we discussed about the integration and the enhancement of the mechanics developed by my colleagues. While I was dealing with these tasks, as a Lead Programmer, I decided to delegate the next set of features.

It might sound like all I do is give people tasks to carry out, but in reality my teammates are very happy to contribute, and since this is a Game Development Course, there’s plenty of focus on the Programming aspect, so everyone is expected to write some code.

Therefore, delegating the right amount of work and the right mechanics that do not interfere with each other, is my main concern now. The reason why the Scripts that separate programmers work on have to be different, is that conflicts arise when trying to push a Script that was remotely modified since the last pull. There are a few Programming Tools that can help one merge large bits of code, and even Unity plug-ins like Tortoise SVN, but I chose to avoid this part of the process all together, by delegating distinct tasks and offering exclusive access to specific files.

As you can see my ‘to-do’ list is not very well organised. At least not for everybody... for me it makes perfect sense. The important bit is right at the top where it says “Alex - UI and Menu” and then the files on which he has exclusivity: Player.cs, GameManager.cs and the Scene. Yeah... the Scene is also a file that needs to be edited by one programmer at a time.

Then, under that, we have “Ciaran - Platform generation Sets” with the relevant file: PlatformGenerator.cs. Don’t worry, these task end up on Trello after I write them down like this.

Long story short, Alex will now take care of the implementation of the menu, which will be a separate Scene all together, while Ciaran will implement a system that changes the type of the platform based on a Biome factor that I have implemented right before this.

The end goal is to have a game that changes the environment of the level as the player progresses.

That’s it for now, see you on the next post.

Bogdan