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...
For August the theme for the Dublin One Game a Month group was “Give Up”, a topic near and dear to my... slightly malfunctioning head.
I had written a little bit in the past about my then recent discovery and self-diagnosis of Social Anxiety Disorder [in brief: Social Anxiety can be considered the irrational fear of public embarrassment/being judged in a negative way way. Everyone experiences this to one degree or another, which is perfectly normal. It is when it becomes persistent, affecting day-to-day life over a long period that it gets classed as a Disorder; anxiety over anticipation of social interactions becomes debilitating]. I've since had that diagnosis confirmed, been prescribed medication to help, albeit the smallest of doses, and come to realise just how much I've allowed it to take such a firm grip of my life. It has affected my capacity to work (directly and via a knock-on impact on self-confidence in my abilities), I've allowed friendships to evaporate and it generally has made me stall in many regards. Oh, woe is me, etc. etc.
This is something I obviously want to change, although irrational fears are not always so obliging. I figure one of the best ways to start is to rob it of one of its most potent weapons, the reluctance to even acknowledge its existence to others. So when the theme of “Give Up” came around, I saw this as a chance to create a game featuring Social Anxiety, at least in part. I wanted to have a character that can become so overcome by anxiety that they have to quit that game and run away, thereby achieving a “hollow victory”; they feel the relief of avoiding their fears but ashamed of having run from them (thematically at least) and therefore causing the other players to fail at their group task. A slightly superficial representation, but enough to get the point across and give the player a taste of the experience.
So along the lines of “write what you know”, I decided to make a game called “Game Jam”; a cooperative tabletop game where the players have to collectively complete their game projects before the end of the day. But some of the players could be playing for their own personal goals that could prevent the group from winning, with different character types having different types of goals, one of which being the Socially Anxious player type.
This wasn't just a #1GAM game, I was also doing it as part of a game design workshop I was taking part in. So that and the fact that this was a somewhat personal project, I kinda went all out on this one. A lot of coloured paper and printing and gluing to mounting board and cutting, so much cutting, hundreds of tiny pieces worth of cutting (and one finger). If nothing else, it looks pretty.
It'd been half played in the workshop without characters and goals, and it felt a bit stale (to be expected) and half played, at the #1GAM meetup at dubLUDO, with everything more or less in place. There the players seemed to like it, pausing only to go play some Johann Sebastian Joust, which ended up taking so much time - because it was so much damn fun! - so we never got back to the game. What was noticed was they the players were rapidly approaching a point of stalemate where it would have been harder to make progress. So changes I'd probably make would be to accelerate advancement in the later half of the game, which would also simulate the mad rush near the end of an actual game jam to get your game finished.
But there probably won't be much more work done on it; August and workshops are over, so it's on to other things. What I'll likely do is make a few tweaks at some point and bring it along to the next Dublin game jam event and see if anyone is interested in having a go.
Here's the rule sheet I had typed up for the game.
You are attending a 24(?)hr game jam event
Your goal as a group is for everyone to complete their game project before the end of the day (one turn for each hour of the event)
At the beginning of the game each player blindly selects:
A skill point counter for each of the 4 skills, Design, Code, Art & Audio.
A Charisma counter
A game board
A character sheet
A Goal card
At the beginning of each turn players choose to 'work' one of their four skills, taking a number of skill tokens for that skill equal to their skill points plus any modifiers.
They then all select turn counters from the bag; these will indicate the play order for that turn.
On their turn, a player can choose to apply their skill tokens to their game board or trade them to another player who has not yet taken their turn.
If a players Charisma score is at least 2 greater than the Charisma score of another player, then they can force that other player to trade, otherwise the other player has the option to refuse to trade.
If players trade, then both players will have used their turn (returning their turn counters to the bag).
After trading the players apply the received tokens directly to their game
When applying a token to a game, if a highlighted marker is filled, then the player will take a chance card and follow its directions.
If a chance card makes the player miss their next turn, then their current turn ends (cannot take additional chance cards)
Each skill bar on a game card has two Polish markers. These can only be filled by obtaining Feedback from another player. This requires the player to trade with another player, receiving the appropriate skill tokens and then changing them for Star tokens.
Some players will have received Personal Goal cards, this allows them to win the game for themselves, instead of the group. A player can 'win' a personal victory by fulfilling the indicated requirements on their Character card.
Dublin GameCraft 3, the 12 hour game jam, was held yesterday, and this time the theme was "Non Violent Exploration".
Here is the game I made...
The object is to grab the orbs that match the colours of the beacons and bring them to the centre before the big red timer reaches the centre itself.
It borrows a bit from the Radar prototype with the fog and sensing, although the opaque/visited aspect of the fog was maybe unnecessary as there is no terrain to navigate. I was initially was going to place it in a maze of rooms, but I felt it added little and so ended up going for simplicity to get something done.
I'm quite pleased with this one and I got a lot of nice comments from others who tried it.
I made it as part of One Game a Month Dublin, a group that loosely follows the format of One Game a Month (aka #1gam), where you have... wait for it... one month to make a game. I decided to do this has it's been ages since I've actually finished a game.
For the Dublin group there is an optional theme and then you get together at the end of the month to play each others games. There were a number of interesting games made this go around, including a dungeon explorer, pirate space invaders, an intesting boss fight mini game [win32, OSX], a stock trading card game and others.
For my own game I decided to ignore the theme of "Rogue" and instead have a go at adding gravity to my game engine and make a platformer.
That went in easily enough, although I had initially just added in the acceleration due to gravity and not the velocity it acted on (I've defined gravity as a separate 'force speed' that then modifies the overall object speed, basically using what I had already put in place for handling slopes). This meant that at lower frame rates you couldn't jump as high, which i noticed when trying to play on my phone. Oops! Easily fixed.
I wanted to have the camera be a bit smoother, as it gets very jerky with all that jumping (although the jumping in the actual game is a bit smoother than portrayed in the videos), and I got some good suggestions from other members of the group on some simple code to make the camera lag behind the player.
Code: camera.X -= (camera.X - player.X) / N;
//(the higher N the higher the slower it gets to the player)
I then went about creating background parallaxing, a new set of tiles, some basic character animations and added in some simple colour blocks and a block spawner. The aim of the game is simple enough; combine four similarly coloured blocks to create a bigger block. Then combine four of those bigger blocks to make an ever bigger block. The goal would be to get a large (level 3) block for each of the six colours, but each block has a limited lifetime (according to it's size) and there are also bombs to add in a bit of friction.
With a bit of extra work put into my object collision detection (it wasn't really up to handling multiple objects at once) and getting it to work on my Nexus 7 pretty smoothly I was more of less done for the month.
I actually like the game! I found that taking one minute to test a bug fix turned into ten minutes playing. So after the month was over I decided to keep on going and turn it into a finished game. This means I have to polish it up a bit; adding in the goal (which was missing), cleaning up the collision detection a bit (including stopping blocks from hanging in the air) and adding some character and animations to the blocks.
A bit of Polish and Tint
Following the universal law that all inanimate objects should have googly eyes, I created some simple animations for the blocks. To make things easier on myself I decided to make them greyscale and tint them at runtime. Trouble is if I do this the easy way with blanket tint using a colorTransform then it tints the eyes too, which I don't want. So I need to tint only selected pixels. Of course the obvious answer that immediately sprang to mind was to do exactly what Metaplace did (again!); alter the tintable pixels of a png so that (red-1) == green == blue (where red==green==blue is greyscale), then at runtime check each pixel and if it matches those conditions then multiply by the tint colour. So I wrote a quick Paint.NET plugin to reduce red channel of selected pixels by one and then tested it in Flash. But I found that some pixels that should have been tinted weren't.
After much testing I discovered that the BitmapData of the png when it ends up in Flash is not the same as the data in the original file. Specifically for pixels that had some transparency the data could be off by one in one or all of the red, green and blue channels, which would screw up the very precise conditions of r-1==g==b. I spent a couple of days trying to get the exact data into flash by various means (ensuring no compression on Embed, using a loader, loading as a ByteArray, saving in different graphics program like gimp or even creating in php to ensure some png flag is set, pouring over the binary data with a hex editor etc.) to no avail. Something just happens to the data and I never found out what (I have a nagging feeling this is one of those areas where gaps in my self-taught knowledge are tripping me up, and someone could just say "Duh! Of course that happens, you didn't set your foo to your bar. Every n00b knows that!"). So I decided to see how Metaplace actually handled that by decompiling the client. Turns out I was being too restrictive with my r-1==g==b. From the looks of it maybe they ran into the same issue too; they had an allowable offset of 3 (although they went in the other direction). So changing my pngs to have an offset of 2 instead of 1 in the red channel and using the following appears to account for all cases...
Code: if(green == blue && red < green && red > green - 4)
This would appear to allow the red to be off by one in either direction, while the original offset of two leaves the green and blue intact - or at least equal to each other - when embedded.
Of course the real power of this type of system is that it allows you to use three tinting colours, one for each colour channel, on a single image, which is overkill for this project but may end up being useful later down the line.
The game still needs a fair bit of work but I'll likely keep it very simple; simple goal, single map. I'll then put it up on FLG and finish the android version. If it performs modestly well I might expand upon it. And I just might get to call myself a Game Developer again... maybe.
Just writing this down in order to think my way through it.
So I'm building levels for the game and I've gotten to this point where I want to have the player climb up a spiraling tower. As the player ascends, the areas at a higher elevation, i.e. beyond the cliff face, will remain hidden but the areas on lower elevations can be seen (within the players current light). Also if the player walks off the cliff edge then she will fall over the cliff (without player control) and land on the flat lower floor.
I took part in the 12 hour Dublin GameCraft 2 game jam yesterday. The theme to use to make your game was the colour blue and a picture of a bird on a branch
I decided to take the branch, make it blue and so turn it into a river.
This was a result of my "effort"...
Controls:
WASD or Arrows to move
Space to drop bombs
R to reset
If the ships reach the power plants, pollution increases and so more black clouds are produced, which (if I had finished) would be harmful to the bird, so you as the bird want to bomb the ships. Unfortunately I didn't get to finish, so there are no win/lose states.
I'd wasted a lot of time messing around with the ships and their pathfinding (tracking down quirky bugs in my frankenstein of a custom game engine) and only added the bird, clouds and bombs in a mad dash in the last two hours. Also working on my own without an artist is quite telling :) (I downloaded the bird sprite).
I'm sloooowly but surely making progress on my next game, in fact I beginning to build up a bit of momentum as I start moving over from engine/mechanic creation to level building. I still haven't quite nailed down the main mechanic(s) yet but I want to build some levels first to get some play-test feedback.
Here's a video of the first level I've been playing around with. It is just a simple starter level to introduce some of the main mechanics.
Here is how that level is defined in the level file...
Finally getting back to putting together a prototype for my next game. Throwing in rough first passes on some stuff that would be needed for a simple level; like doors/locks/keys, some extra AI behaviours, etc.
But mainly I'm trying to give myself a bit of encouragement to press on with it. :)
)
RSS Feed