So this week has been interesting, if not, frustrating. Before I explode your minds with the issues I have been having, let's just take a step back and enjoy the little victories. Firstly, I've managed to implement a few small 'juicy' elements for the 'Puncher' as well as adding a few more animations to the character. The punch effects where fairly simple to implement.
Firstly the dust clouds. To increase performance, rather than creating two different dust clouds (one for left, and one for right), all I did was create two of the same actor, and just flipped one -100% along the horizontal axes.
As for the camera shake, less is more, too much, and it's over kill. Playing with the subtle amounts really worked for me to find a happy value.
I had also create some simple death animations which I would really love to push throughout this game. I feel that having funny deaths of a character gives the game not only personality, but some moments as well. Death animations really take me back to 'Crash Bandicoot' days, so implementing something like that would really top it off.
The first death animation implemented was for the 'Puncher' mechanic. If the player was in a certain location above and below it's starting location from when the puncher trap impacted, the player would die.
This was actually quite tricky to set up. Firstly, I needed to check whether or not the player was roughly around the area where the 'Puncher' impacted, otherwise, the player would still die even if it was a lot higher up since it still technically 'collided' with the trap. So, I needed a reference point from where the player characters X, Y coordinates were when the puncher trap first spawned. Then once the trap fell to the impact point, it checked whether or not it collided with the player's top collision point, as well as checking whether or not the player was still in that same location.
The other problem I was having was the player essentially had to stand still in order to die. So i had to widen the 'touch' location, so then if the player had moved slightly up or down, then the collision would still happen (roughly 20 +/- in the Y direction from the original location seemed like a sweet spot).
Basically, whether I moved slightly or not, I would die if I didn't move completely out of the way.
So once I had a grasp of the 2D-flat-detection-collision-location-stuff, it was finally time to move on to something fresh. A new mechanic! I created the 'Buzzsaw'! I viscous saw-blade which pops out form the ground. The... only... thing I still need to do with this is to actually get it to work... Which is on my to-do list! I still need to implement a death for that, as well as make sure it constrains to the boundaries of the game environment. Easy fixes, but ones which still need to be done. Also, let me know what you think about the colors; will they stand out, will it be funny enough, or whatever. Let me know!
After all this success, reality had to come back for another round. There was still something that was 'urking' me, and that was the layer ordering of each asset. What's that you ask? Welp, essentially layer ordering (or z-layering for short) is a type of thing needed to move an actor or image up or down within a particular layer without adding a crazy amount of new layers. The problem with this was that each asset within the level moves. And this being a 2D game, with basically zero 3-dimensional space, was quite difficult to figure out. Trust me, I spend ages on trying to sort out when and how these assets should work with layering. I did however manage to find a useful resource which helped understand how I could approach this. Now, without going fully into technicalities, I'll try and explain the process:
I firstly had to make an array (or list in my case) which was empty.
Then, from that list, I had to identify each actor within the layer I wanted to affect
I needed to add that actor to the list, and if it was the first actor added, then be done with it. However, it this wasn't the first actor in the list, then i needed to create a 'zIndex' attribute (integer variable)
I also needed to check each actor in the list before it and check whether or not it was lower or higher in the Y axes (Up axes).
If it was a higher value, then do nothing, but it was lower value, then decrease the Zindex by one for each actor in the list.
Then finally, insert that new actor into the correct index within the list.
And since each actor moves all the time, I needed to have this in an updated event.
Yup, fun. But I eventually got there. There are still a few tweaks to push out, but it is working at a fairly good point.
Overall, I'm pretty happy with this progress. I'm hoping by the end of this week I will have the Z-Layering under control, as well as the Buzz-saw mechanic.
That's about it for this week. Stay tuned for more next week!
Enjoy, and thanks for reading.
It's that time again for another installment of "Hey something worked!... Oh wait, never mind..." with yours truly. This week I've been quite busy with reapplying all of the character animations, as well as implementing the first game trap mechanic. Below is the final result of my character animations. To be honest, I'm pretty happy with the result, but, early days still.
Once I completed the animations, I then moved on to tweaking the controls a little more. I added my own joy-stick display to make it even more transparent and less intrusive. I also made it so that if the player touches the other side of the screen, then the controls will appear on the opposite side instead. I made this decision so that the controls aren't always locked in one location, and that any player, left or right handed can enjoy.
Then lastly, it was time to add in the first mechanic: The Puncher. This deadly trap will flatten you like a pancake if you are not careful. Yes there are a few kinks I still need to remove from this trap, but the overall idea is coming along nicely.
That's basically it for this week. Hopefully I will have a little more to show you all next week. I do however head back to work, so it may not be as much as I would like, but hey- a man's gotta eat!
Until next week!
Another week down, and I must say, I have managed to get through this section fairly quickly, thanks to Spine2D. Very useful tool when animating in 2D. It has saved me countless hours of key-by-key drawing. All I really needed to do is draw up each section of the character in all direction, and let spine2D do the rest. Now, I know you must be thinking that I'm a promoting powerhouse, but seriously, I'm glad I choose this route. I would suggest, if you are working on a game which uses a number of 2D animations, I would highly recommend using a program such as Spine2D, super useful.
Really, the only confusing part was knowing when to use 'Left-Up-sword' and 'Left-Down-Shield' for this guy. Word of advice; Always label your sprite sheet assets as clearly as possible, my god! The amount of times I used the wrong asset was incredible. There's really not much else I can say for this particular phase, All I really did was break apart the character into it's own components, named them as best as I could, and put them together.
So yeah, super quick devlog this week, But I really would like to add a few more key frames in each of the animations for the coming week. I also plan to start implementing the actual game mechanics such as a few of the basic obstacles, and traps. So stay tuned for more!
With the first week down, I was hoping to have a few more things under way. But of course, development doesn't really work like that. I thought I had fleshed out my game design document as much as I could, but there has been a few hiccups i had never really thought about.
The first hiccup was the controls. I knew I wanted an on screen joystick as the main control, and a 'tap' mechanic which would slide the player to quickly get out of harms way in the direction of travel. Now the tapping mechanic wasn't the problem. That was actually quite simple to set up; basically, I just needed two different ID's for when the player has their fingers down on the screen. The first being the movement, and the second being the tap mechanic, since, well, you need to be moving in order to dive, I figured the movement would be the first ID and the tap being the second. No, the tap mechanic wasn't the problem, the problem was the movement and the joystick configuration.
I initially wanted the joystick to be fully transparent when the player presses the screen. I wanted to have as much game space as possible without crowding the stage up with the controllers. In theory that sounds good, but the problem is that the player would have no clue where they initial pressed when moving the character around. If they wanted to turn the character back in the opposite direction, they would have to essentially 'guess' or 'remember' the initial location of when they first pressed on the screen, which, for a game that requires an incredible amount of concentration, is something you wouldn't want to care about. So, I decided to drop the transparency of the joystick to a point where you can still clearly see it, but not too much that it crowds the game stage.
The second problem I had was deciding whether or not to have the joystick move to the pressed location, or to anchor it to the corner of the screen (either left or right). I thought about this a lot, but ultimately decided to keep it anchored to the bottom corner of the screen. I thought "nobody would really tap in the middle of the screen in order to move the player around right?". Players who have used joysticks in the past are used to having it in one location, whether it be on screen or on a controller, so why change something that ain't broke.
Once I "kind of" sorted out my controls, I decided to move on to implementing a background. Now I know it's way to early to implement a full background at this stage, but there is a reason for this. Since I'm trying to accommodate a number of different devices with a number of different dimensions, I needed to make sure that not only the background was still visible, but the game mechanics weren't out of the screen bounds. So I decided to make the background larger than it needed to be, and center the games camera to the middle of the background. This allowed me to know exactly how much screen space was needed for the smallest screen dimension, and build the background out from that. So far, it seems to be working well, but I need to test this on a number of different devices, so stay tuned, this still could go up in flames.
The last thing I struggled with was the walls of my background. The ground was fairly simple, since I knew the style I wanted. But the walls of an 'orc' arena are actually quite difficult to think about. Not only did I need to consider consistency with the style, but I also had make sure that it wasn't to distracting, nor was it too bland. That it wasn't too dark, or too light, and consider what an actual orc arena would look like. These things were hard to think about, but I eventually found a style of wall which I like. I may change this later down the track, but for now, it's a good placeholder. Handy tip; Referencing is your friend!
Besides these tedious hiccups, I've managed to actually get the ball rolling with this. I hope that in the coming weeks I would gain a little more momentum. The goal next week is to implement the character animations for 8 different directions. Again, ambitious, but do-able. Until then, enjoy!
Over the past few years working on Slidey Feet, I have come to realize a few things. Things in which I never would have considered. Things that most schools or university don't really teach you. Sure, some of these things are quite hard to teach such as self preservation, determination, and any other '-ations' you can think of to get you over that development finishing line. No, the main 'thing' that I had over looked during my development process was a thing called 'community'.
Community is one of the most important aspect of game design. Without a community, your game would most likely fall into the endless void of forgotten games. I know marketing can also play a massive role in bumping up your game's existence, but without your community, your game would get minimum amount of exposure. Not ideal especially for making money.
That's why I have decided to create a Devlog, so that people new or old to the industry can follow my journey through the up's and down's of creating a small mobile game from start to finish. I wish to not only build a community of my own, but to also let other learn and see the inevitable mistakes I make a long the way so that they can avoid them during their development process. I'm hoping this Devlog will be intuitive to a lot of people (including myself), so that I can also learn from my mistakes and grow to become a better game developer.
Your first game is more or less like your first born child; You think that it is the best thing in the world, that nothing else you could produce could ever be as good as the first. Welp, most of the time, it's not the case. Once that second child comes in to the mix, it's down hill for the first one. Sure, you still might care for it and nurture it, but not as much as the second born.
The first idea that you come up with is almost guaranteed not to be your best. Now I'm not saying that you shouldn't work on it -by all means, develop that first idea, it will give you some very good experience- but, you shouldn't just stop there. Be creative, be experienced. Doing this will give you the knowledge and understanding on what you will need to do in order to produce better ideas, and higher quality of work. And yes, there is a point to these ramblings about children and favoritism. The point is that I did exactly that; I thought that Slidey Feet was going to be a big success since it was my first game idea, my first born, but it wasn't, and I know that now. But, it was something that I got off of my chest. Something that I wanted to create, purely for myself, and yet, I can say that I have my first published game out in the real world. So yes, develop that first idea, see where it takes you, but don't just stop there, be creative, be determined.
Now that my self-absorbed ramblings have come to an end, I'll be happy to share my journey of my game development process with you. I hope that this journey will be intuitive not just for me, but for you as well. So to start of, let me share what this game is basically about. The game is called 'Just Survive: Arena'. Hopefully the title alone gives it away. The genre is basically an 'obstacle survivor'. It is a small mobile game designed for the casual audience. You play a dopey orc who has been thrown into an arena. Your job is to avoid all traps and dangers that are presented to him simply by moving him around with the touch screen controls. Now I know that joy-sticks aren't ideal for mobile devices, but I guess that's where testing comes in to it. I hope to keep this game fairly simple and avoid any complex feature creeps, but i'm sure there will be changes. Simplicity is the goal, so hopefully I can stick to that.
I'm hoping to keep these blogs not as long, but as frequent as possible, to keep you up to date with what I have been doing and what I plan to do. I'm hoping to release these roughly once a week, maybe even twice a week. Now, i'm sure life will throw some heavy curve balls at me while developing this game, which is expected, so if I do fall off the radar a bit, it's for a good reason. Regardless, I will try to keep you in the loop with the 'happenings'. Anyway, I feel as if this first Devlog has been rather 'different' than what I actually expected to write, so hopefully I haven't discouraged you from following along. Again, welcome aboard, hopefully this will be as intuitive and exiting for you as it will for me!
Thanks for reading.