Programming Conclusion / Game Art Initial Thoughts

I thought I'd take the opportunity to really reflect on the last 4 or so months. The main thing to say really is that I'm rather appreciating the break at present, it is giving me time to unwind (despite not knowing how on edge I'd become towards the end of the semester).

Overall, it was a very insightful glimpse into the world of coding for games, and I found myself taking to it a little more easily then I took to Quick Basic back in my college days. I continue to find Futureworks to be an absolutely amazing place to study, almost entirely practical and when written work IS involved, it remains relevent to what we're doing. So no learning about french flaneurs while studying film.

For the most part, I found the lessons to be well paced, although reflecting backwards, we possibly spent far too long working on the text adventure assignment, which made the following lessons seem a little too rapid in comparison. I know I started stumbling and no longer understanding the work quite as deeply as time went on. I also know that the tutor did strive to help us out at all times, which to go back to the theme of the previous paragraph... is a vast improvement over being told to simply look in a book of the work we were doing in Computing. Understanding why something does what it does is a good thing, and fortunately for the most part, it segued into XNA admirably.

And again, as in a previous POST, I'm still not entirely sure if I'm going to consider working much deeper into programming as a career choice. At heart, I'm more of an ideas person as well as an 'artist'... but on the other hand, I'd love to be able to work on my own ideas and create working concepts. My goals have shifted since I started this course in Games Development, and I'm slipping from wanting to work for a larger company to being capable of popping out smaller games that are simply fun to play. I feel I'm learning the importance of games simply being fun, and that there is still a tonne of potential for new ideas and mechanics even within the restrictions of 2D or lower end production. I've always believed that good art design and good gameplay should be valued when designing any sort of game, and to be able to put those ideas into practice would be a dream come true.

Assignment 3 - Magic Conclusion

Because I didn't get much chance to even announce the last assignment, nor go through the work process. Something about programming has made keeping this blog up to date surprisingly difficult. Then again, I suppose there isn't really a lot you can show/demonstrate when it comes to programming besides the finished project. Oh well.

But regardless. Our assignment was pretty much a task of expanding upon some XNA based code work we've been doing in class. Adding a healthbar and an option to restart or quit the game, stop the player moving offscreen et cetera.

I've somewhat felt over the last few weeks that we have covered far too much ground in a short space of time, and as a result it was difficult to get to grips with the task at hand. But by plenty of internet searching and assistance from a programming acquaintance, I was just about able to achieve all of the above tasks in the nick of time, along with the inclusion of an additional platform (Seeing as I opted to make the project into a platformer rather than a four directional game.)

I haven't got a lot else to say. I'm going to go back and try to learn all of this work properly in my own time. While I'm not sure whether I'd ever want to focus on programming as a career choice, it maintains a hold on me due to the possibilities of someday being able to produce working concepts of game mechanics and ideas I've been jotting down over the years (more so since I've been on this course).

I digress. Have some screenshots.

Such an imaginative title screen. As with the previous assignment, I included the controls here for the sake of clarity.

This is the entire game right here. A floor, one platform. No items, Fox only, FINAL DESTINATION.

A jump animation was kind of included... and also demonstarting a functioning platform. I had a fair bit of trouble with said platform at first, from characters falling through them to characters walking on air beyond the platform if they did not jump.

I was too indifferent to make meaningful projectiles.

Demonstrating how the health bar reduces as players are damaged by the black blocks

Shockingly enough, there is a seperate game over screen for if the second player won.

 

Personal Blog - Basic Sprite Tutorial

This is more or less a poor tutorial about how I put together a spritesheet. For drawing spritesheets is one thing, but ensuring that each frame is in sync with the other frames is something else entirely. I'm going to stress that there is probably a quicker and easier way then the way I'm going to be showing today, but providing a starting point for further exploration is beneficial in itself, so~

This will also feature some animation principles which I think will prove useful and informative.

Starting out

Right. So. Sprites. The first thing I'm going to say is to start out with considering the size of your game window and how large you want your sprites to be. Working with pixel art, a single pixel is obviously going to be tiny.

As you can see, this is my first sprite drawn with single pixels. Far too small.

 In my own effort, I decided to work with 3x3 pixel squares to maintain a simple look while increasing the size just enough to make the sprite look right. You don't want to make your sprites TOO large for your game window size, otherwise you'll be limiting how much screen the player can see beyond the player sprite (and enemies, if applicable)

Still not very large, but in a 800x600 screen, it'll be the right size.

Colour is very important to consider also. If you think about Mario or Megaman, those sprites feature very simple but contrasting colours, which is important to stop a sprite looking like a block of pixels rather than a character. I'm using largely monochrome colours, but I've made the shades distinctive enough that they don't blend together.

Starting to make your sprites

The next thing to consider before getting into the work itself is to consider in advance WHAT sort of actions your game will allow the player to perform. In this example, the player is able to walk and jump, as well as be hit by enemies or the environment.

At this point, I wouldn't be too precious about how aligned your sprites are. I tend to make copies of one sprite as a measuring point for height, and a line to keep the sprites on an even level... but that is about it.

An example of drawing most of the sprites I'll be using in my project. Also included are earlier iterations of the Bill Dup sprite.

Another pro tip at this point is to break up your sprites into seperate body parts on different layers so that you can experiment and recycle different pieces of body. This will save you time in the long run.

Animatimg Your Sprites

Ooooh. Animating. Because a single picture isn't going to be good enough in most games. This is where I will be hitting on some animation theory, so buckle up.

In terms of traditional animation, a rate of 24 frames is the standard for movie quality animation while modern standards mostly hover around 12 frames per second. Depending on how fluid and how quickly you want your animated sprite to be, you can easily get away with even less frames... for example, in the original Super Mario Brothers, Mario and Luigi only have three sprites to represent their run cycle.

In my case, I'm sticking with six frames of animation. Animated at a sufficient speed, it will still look fairly smooth without too much work. One must also keep in mind that making individual movements vary too much will make the sprite look like it is moving far too fast. Equally important is to remember to treat the first frame of your animation as also being the seventh frame. Because after the sixth frame, the loop starts all over and so to keep your animation smooth it should flow back to the starting image. Gosh I can't write.

This is also where having copies of seperate pieces of your character will come in handy. And again, I don't consider this point to be especially important in terms of syncing all of the sprites into precise frames. You will want line to keep your character's level consistant, but that is about it.

Animation in progress.

 And yes, the above should show why it isn't that important to keep your sprites in frames just yet. Some will take up more space than others. Hopefully it also shows why it is a good idea to draw an individual sprite for each state before you try and animate them - you have an automatic starting point to use as a basis for the rest of the frames you'll be animating.

Making Consistant Frames

Because it is really easy to end up with each picture accidently jumping left and right during an animation cycle.

My way of countering this is to find which of my sprites takes up the most space, which will then become the standard point for the rest of the sprites to fit into.

In photoshop, I cut and paste this sprite into a new file, and then changed the canvas size to the size I want to animate at. In this case, I'm sticking to 160x160 pixels. The sprite should remain in the centre of the file, and voila. I change the colour of the background so I can place multiple copies of the same image into rows and columns.

Then it becomes a case of aligning the other sprites over the newly created template. In my case, I mostly used the head as the basis for where I wanted to place each sprite.

This isn't 160 by 160. I can't seem to open the file with the correct size, but the principle remains the same.

With this done, I can then delete the template and be left with a clear background and all my sprites perfectly placed so they don't bounce about between frames. Success!

The mostly finished spritesheet

Of course, now you can stick it in game and see how it animates. You may find some small mistakes that need correcting or iterating on, but you know what to do now, so. V:

Personal Blog - An Aim For The End Of The First Year

Because I'm awake diabolically early today, and I have absolutely nothing better to do in a world where Visual Studio refuses to work on my current PC, I thought I might as well write this up.

I have a noble goal that I hope to achieve either by the end of the first year of Games Development, or maybe in the beginning of the second year. I wish to take an element of each section of Game Design, Programming, and Game Art to create a working one level game. Nothing elaborate.

So essentially, I'm going to take my level design from Game Design (As well as the game rules, so that would involve a character that goes from walking to running after a few units, sliding, and swinging), use C# and XNA from programming, and probably use some art from Game Art if it is applicable and/or possible.

Am I optimistic about it? No, I'll probably fail. But I'd like to at least try. It'll also be nice to use my unofficial mascot/alterego Bill Dup once again, a little fellow that tends to appear in my sketchbooks and some older projects.