Another semester done and dusted. Here’s some of the stuff I've made in the three modules of Game Systems, Narrative Design and Game Programming in my part-time BSc Honours Degree in Computer Game Development course at DIT.
Most recent first.
Game Programming: Pac-Man Finished just this last weekend and presented in the first class of the new semester this week was our Game Programming assignment. The brief was relatively straight-forward; make a 2D game in Unity, taking inspiration from a classic game, creating as much of the game in code as possible. I took that as a challenge! I decided to revisit a past failure in order to make a pixel-perfect procedural Pac-Man. Not quite inspiration, but a full out clone.
The only Unity primatives I used in this project are Quads, and they're just to there to hold the textures. Those texture don't actually exist until the game is running
To give an example here is Pac-Man's death animation
There are 11 distinct frames of animation there. Here is how those 11 frames are represented as data in code.
And here is how that data is past to the custom "Painter" function that creates those frames, using the first and last frame as examples...
Code: Texture2D f1 = Painter(pixelDeathData, new int[]{1,2,3,4,5,8,9,10,15,16,17,18,19,22,29,30,31,32,33,34,36,37,38,39});
Texture2D fl = Painter(pixelDeathData, new int[]{30,31,32,33,34,35,36,37,38,39});
All perfectly clear, right. Right?!
Okay, so that may need a little explanation. Lets take the case of a very simple 2x2 4 frame animation
Starting with the first frame (yellow on top row) we define our two-dimensional array, pixelArray, as:
{1,1},
{0,0}
If we were then to use our Painter function now we'd get back that first frame
Code: Texture2D frame1 = Painter(pixelArray, new int[]{1});
But we can't actually use the function yet as we need to enter the data for all the frames beforehand (which is the entire point, use one array instead of four).
So on the next frame there are four different states a pixel can be over the two frames:
{1,2},
{0,3}
0 off for both frames
1 on for first frame but off for second
2 on for both frames
3 off for first frame but on for second
This means the function call for the first frame changes slightly
Code: Texture2D frame1 = Painter(pixelArray, new int[]{1,2});
Texture2D frame2 = Painter(pixelArray, new int[]{2,3});
And so on, until we have all frames. For this simple example it only take one extra step
{1,2},
{4,3}
so all four frames can be defined
Code: Texture2D frame1 = Painter(pixelArray, new int[]{1,2});
Texture2D frame2 = Painter(pixelArray, new int[]{2,3});
Texture2D frame3 = Painter(pixelArray, new int[]{3,4});
Texture2D frame4 = Painter(pixelArray, new int[]{1,4});
For such a simple case that is pretty straightforward, but for eleven 16x16 frames it gets really unwieldy, especially if you need to debug your mistakes. If I were to do it again (and I might just do that to try and complete the game) would be to treat the binary version of the integer values in the array as a third dimension (where each bit represents the state for a particular frame). Then bit-shift off each bit one frame at a time.
Overall I'm really happy with what was submitted. I followed the Pac-Man Dossier as closely as I could trying to replicate everyting from Ghost AI to Pac-Man turning around corners. I even coded in the effects of a buffer overflow from the original arcade cabinet (where when ghosts are attempting to find a spot x tiles in front of Pac-Man, that spot will also be x tiles to the left if Pac-Man is facing up).
But as a port it is not feature complete (missing bonus fruit, warning flashing on ghosts exiting frightened mode, ghosts do not use a pseudo random number generator with path finding in frightened mode [they just use their scatter home target], no cut scenes). There are also a few bugs, the most noticeable being if ghosts are in the middle of exiting the ghost house when Pac-Man eats an enigizer (causing the ghosts to enter Frightened mode) then those ghosts won't move at their full speed for that level on exiting Frightened mode.
Can you spot the differences? There are many
So I may revisit this one to finish it off. And it's something I'd recommend to anyone who is starting to get in to making games; as a Journeyman exercise try and recreate a classic game as closely as you can, replicate everything from movement and scores to menu screens (though not necessarily procedural asset creation). It gives you a good appreciation of what it takes complete a game (without the uncertainty of your own game design decisions getting in the way).
The game can be played here, and the source of the unity project can be downloaded here.
Narrative Design: Saturn Descending
Next up, Narrative Design. For this module we had to create a mini text adventure game using a program called Twine, which makes these types of text games.
Twine games are somewhat known for more personal or thought provoking games (like Depression Quest). So I wanted to take this opportunity to kind of do the same and create a main character that experiences social anxiety, so that the player gets a feel for what someone in that situation might go through (although it may be a bit over exaggerated at times, or drift off into general anxiety). There are elements in there that reflect me of a few years ago and even the slightly better me of today (stutters are annoying!)
The story/game itself is a bit so-so; pacing is a bit off, some character interactions aren't earned, and there isn't enough for the player to do to direct the story. But I guess it is what it is... a product of a deadline.
Takes about 5-10 minutes to play through, with different content in places depending on the choices you make.
Saturn Descending [Warning! Contains trace amounts of Science-Fiction!]
Game Systems: Prototypes, oh so many prototypes!
This module started out by introducing the basics of Unity and then quickly moving on to making a prototype to a set theme each week.
But before the avalanche of prototypes we had to make an atmospheric environment, with a beginning and an end. So I decided to try a low-poly volcano, where you can see your destination from the start but not the full path you have to travel to get there.
There is no game here, just an environment to travel through, hopping from one pad to the next.
Peace: Then came the prototypes, first up was the theme "Peace". For this I decided to make a game about the apparent 'keeping the peace' or maintaining equilibrium in the nuclear arms race.
Playing on the side of the US (didn't have time to set up the USSR to be played) you have to assemble your ICBMs in order to maintain your stockpile of warheads, but if you work too fast, or too slowly, you'll tip the scales and trigger a nuclear war. This was the most 'complete' of the prototypes as a game.
Oppression: Next up was Oppression. I'm marking this one down as a failure, due to limited time, and not much worth sharing although I did demo what little I had in class, which can be seen here (may or may not display correctly due to shader shenanigans).
Change: This was by far my favourite as it combines two things I really want to learn more about, Shaders and real-time mesh deformation.
This is one I'll be working on more in the Game Production module this semester, fleshing it out in to a real game.I'm thinking it'll be one where you have to stretch or compress the terrain in order to create veins of resources within the mountains
The Sun/Son: Next was "The Sun" or "The Son" if you preferred. I decided to go for Son and made the beginnings of a simple game about inheritance.
Here you combine two shapes to create a child shape that takes properties from both. Missing from this is a target shape that you would try to create after a number of generations from the supplied starting shapes.
Completeness: This was another relatively simple one due to lack of time. Completeness brought to mind diminishing returns. The goal here is to try and fill the screen with the circles before they turn yellow. Growing the circles slows the rate at which they change colour, but the larger they become the less effective they are at slowing the change.
There is no victory condition so you just 'play' 'til you lose.
Wrath of Kitty! Last, and not quite least, is week 6. For this we could take the theme from Ludum Dare, Dublin GameCraft game jam (both of which were that weekend) or... some other theme that was mentioned that I've completely forgotten. For Ludum Dare it was "Game all on one screen" and for GameCraft it was "Wrath of Kitty". Since I was attending GameCraft I went for the Kitty.
This wasn't too successful a game jam for me (yet again), so this is pretty simple. You play as the baby and you have to pull the tails of the cats, without letting any of them see you otherwise they all startle and run away.
So that's it. All the stuff I made last semester. Some a bit meh, others I actually liked how they turned out for the most part. On to another 3 months of making!
This past year I've been doing a one-year part-time ordinary level degree (level 7) in Game Development in Dublin Institute of Technology. It covered a range of topics, including game design, programming, entrepreneurship, production, asset & narrative design and culminating in a final project over the summer months.
Here's a few of the things I made over the year.
Programming
As many people on the course had no previous coding experience we started with the basics, starting off with Lua and the Corona SDK then moving on to Processing (basically Java) for some Object Orientated shenanigans. We made some simple games over the course of the year for assignments.
We started out simple, a one-player battleships game in lua (source). I made only minimal additions over the base requirements by adding some feedback taunts at the bottom of the grid.
Next up was Pong in Processing (source). Had a little bit more freedom for adding in extras here, so after quickly implementing basic Pong I added in a secret bonus mode that could be accessed by inputting the Konami code on the menu screen.... TURBO PONG!!
The last programming assignment was to make our own version of Asteroids in Processing.
As there were a bunch of other assignments due around the same time as this I didn't get as much done as I would've liked. That being said I'm not unhappy with what I ended up with; I got in randomly generated asteroid shapes, asteroids requiring multiple hits on multiple faces beforing splitting/destroying, and proximity based visibility (source).
All those above should be playable by simply copying the source code into a new project in the appropriate SDK editor.
Production
For the Game Production module we had to make a team game over the duration of the module, taking a classic game (preferably from the libraries of the likes of the Spectrum, C64 et al) and remake it in the engine of your choice. However since there was going to be a prize for the best game made in GameSalad there was only one choice :D.
GameSalad is a horrible unstable monstrosity that doesn't use any coding but a drag-n-drop system of behaviours. In order to do anything remotely complex you have to take their limited number of predefined behaviours and stack block after nested block whilst gently caressing its nervous wreck of an interface so that it doesn't have a stroke and destroy your entire project. I was tasked with wrangling this beast.
The other members of the team were Seamus Hickey, who did all the lovely artwork, and Esteban Moreno Valdés who did all the sfx and composed some original soundtracks (you can find them all on his site).
We decided to tackle a classic DOS game Paganitzu.
For my part I quickly realised that trying to make tile based levels in GameSalad's hopelessly imprecise drag-n-drop scene editor would've been madness (would have had to manually edit the x & y coordinates for each and every element... ugh). So I opted for a different flavour of madness and made my own editor, as you do, which would allow us to quickly build out levels and then get it to output the xml that GameSalad uses to generate its scenes.
After much blood sweat and tears (oh so many tears!) I'm really happy with that we ended up with. The only playable version (because... reasons) is a Mac app that can be downloaded here. Otherwise you'll have to make do with this play through video.
Oh and we won the prize for the best game! €100 gift voucher for each team member! Who knows, we might even get them some day. (do I get to call myself an award winning game developer now?! )
Asset & Narrative
For the asset & narrative design module we had to create a Sci-Fi setting for a game with a character that would exist in that world. I'm afraid to even go back and read the 3 page report for the written half of that assignment; I had suddenly come to the conclusion that it was absolute garbage about five minutes after I had submitted it (but that might just be my hyper self-criticism I seem to develop when showing a creative work to others). But hey, I passed so it couldn't have all that bad!
For the asset side of things we had to create a character walk cycle along with a scene mockup. I was relatively happy with this, considering I'm not a pixel person.
Summer Project
Then, finally, there's the big'un. The Final Summer Project. Duh Duh DUNN!
For this I was on a team of four, with Seamus again, Emile Quigley and Leigh O'Brien.
After a false start or two we ended up deciding to try and recreate my old 'Radar' flash prototype but in 3D with Unity. You play as a space fisherman whose boat is damaged while hunting a space whale. You have to go from island to island to collect replacement parts before you can go on your way again. Similarly to the flash version you have a pool of light that alerts you to nearby dangers (Molemen lurking in the darkness, who if illuminated by your light will instantly knock you out) and that you can transfer to and from other light collecting objects to help you navigate puzzles.
As shadows were such a big part of the visibility systems of the original prototype I was disappointed that I could not implement a lighting setup that allowed for the same type of shadows (issues cropped up when shadows overlapped from multiple light sources). The only good solutions are to use RenderTextures that are limited to Unity Pro. However I was happy with the custom shaders I had written to help reinforce the flat-shaded visual style we were aiming for (and somewhat successfully achieved). There was still massive room for improvement with those shaders, and I might revisit them to see how much better I could have made them had I the time (oh how much better the game would've been if I had some more time... or if I hadn't wasted so much time at the beginning I should probably say).
I was also mostly happy with the custom camera setup I had created so that I could create specific camera tracking for different areas of the levels (of course there were a few little bugs that made it go a bit wonky in specific edge cases).
Design wise, it was a bit of a mixed bag. It starts out relatively straight-forward but then becomes needlessly complex by the time you get to the last portion of the game (I'd be surprised if anyone could figure out that whole crane power puzzle without prompting), but there is potential there to be built upon (a lot of which is present in the original prototype) although I don't think I'd be taking it any further (I think I've developed a distaste for building static level based content).
The game can be played HERE (with keyboard or gamepad), or have a look at this playthrough...
)
RSS Feed