Get Water! launches tomorrow!

indie, playthroughs, Process Writing

You might remember that, a couple of weeks ago, TAG playtested Decode Global‘s Get Water! at one our our 5a7s. TAG and Hexagram have had the pleasure of hosting Decode Global at Concordia for some time now, and we’re very happy to see how well Get Water! is doing. The project, for example, won the Create UNAOC Award for 2012. Tomorrow, on World Water Day, Get Water! is slated for launch and here’s a little bit about what to expect. I also recommend watching the trailer.

Get_Water_gameplay3

The heroine of Get Water! is Maya, a little girl from India who is pulled out of school to fetch water after the pump breaks in her neighbourhood. As I mentioned during my writeup for the playtest: A few of the dangers that she has to avoid: peacocks, who will scare her into dropping the water, turtles that she might trip over, errant footballs that might knock over her jug, and of course, the very real threat of contaminated water. She is armed with boomerangs and other unlockables that will send her enemies running or improve her ability to get water.

So, when I last played Get Water!, it was on an iPad. I played the current build on my little old iPhone, and I have to say that that switch made a pretty big difference for me. Playing on the iPhone was, for me, a lot more difficult because my drawings had to be much more precise – I found that I was doing the same kind of drawing that I did on the iPad, but not getting the same results (probably because the displacement of a few millimetres matters a lot more on the smaller interface). I also found drawing Maya’s trajectory a lot easier on the iPad because I could draw shorter parts of her path and wait to see what was coming (a technique that didn’t really work on the iPhone’s smaller screen). So, if you have the choice, I’d really recommend getting it for the iPad. Otherwise, I got used to playing on the iPhone after a while.

One of the highlights of the game is that it’s a story-driven endless runner, which is not something that I’ve seen too often. During the playtest, not all of the cut scenes when the player unlocks parts of Maya’s story were implemented yet, so it was with great pleasure that I watched the new cut scenes, which allow the player to get to know Maya and her environment and see how the consumable items in the game were actually born of Maya’s innovative thinking about the world that she lives in – such as finding a new way to get around the turtles after watching her friend cross the water on some rocks, or using the rubber from balloons to block up the holes in her water jug. The scarcity of water has forced Maya out of school, and the game makes it clear that she is an obviously intelligent young woman who deserves an education.

I still love the idea that it is the cumulative effect of the player’s efforts that leads to rewards and changes in the game – an idea that is reinforced by the way that levelling up works in the game by adding up the percentage of progress from each individual run. Everything is just a drop in the bucket, but those drops in the bucket add up! So, as a message for social change, that kind of thinking is definitely appreciated. If we took the same approach to social change that we do to crowdfunding and kickstarting, we’d start to see some definite results come out of those drops in the bucket.

What I enjoyed in this final version was that the player gets to hear Maya’s voice – it’s a small change, but I felt a lot more connected to her because of it. (I’m not completely sure if this was in the play test version or not, just because the room was full of people and the sound may have been turned down – but even if it’s not new, it’s new to me!)

Overall, this is a game with a great message and a fun interface that has, to date, kept me busy for about four hours. Water is a universal need, which makes Get Water! a very relatable game that’s also just a lot of fun to play.

You can visit Decode Global’s website or follow them on Twitter (@decodeglobal). Get Water! launches tomorrow for iOS.

Playtesting DECODE GLOBAL’s Get Water!

indie, playthroughs, Process Writing

Get Water! Playtest at TAG

So I was one of the many people who turned up at yesterday’s 5a7 to try out DECODE GLOBAL‘s Get Water! with the specific request that we try to break it. I had some idea of what to expect, but since they’re releasing the game trailer today (or sometime very soon), I had only seen a few stills here and there.

Maya is a young girl from India. When the town pump breaks, she’s sent on a mission to collect water in this endless runner with a lovely interface for the iPad. A few of the dangers that she has to avoid: peacocks, who will scare her into dropping the water, turtles that she might trip over, errant footballs that might knock over her jug, and of course, the very real threat of contaminated water. She is armed with boomerangs and other unlockables that will send her enemies running or improve her ability to get water.

Get Water! is a game for social change, and the developers have done an excellent job of integrating their message into the mechanics and interfaces of the game. There is room for some tweaking: for example, since Maya is school-age, pencils are the game’s currency but, for most players, the Pencil icon didn’t really scream “Store!” There is also one or two timing issues: with the warning that is supposed to appear before a peacock appears, for example, or with the occasional lag. The peacock warning shows up quite early, which leaves the player waiting to react to a threat that won’t appear for quite a while. None of this interfered with my enjoyment of what’s overall a great app game.

There are also some really beautiful examples of form suiting message (like form suiting content but for awesome games with a message). For example, even if the player doesn’t do so well on the individual runs of the game, each run is given a percentage which progresses a bar to the next “level,” making the individual runs add up in the long run to unlock different abilities and items. It reminded me of how wrong the expression “a drop in the bucket” turns out to be in situation like this – especially since Maya is collecting water droplets. Those drops come together to make something a lot bigger, and quickly (as anyone who’s ever had a leak in their home can probably testify). The larger message, for me, was then that if everyone adds a couple of drops to the bucket, we can create change. Nice!

My favourite part of the game was probably just the means by which the player guides Maya along: by drawing across the iPad in any shape that they want, so long as they keep the beginning of the path under Maya’s feet. I played for over an hour yesterday (and was a total iPad hog, ask anyone) and I never got tired of drawing a path for Maya through the city. The trail that the player draws in front of Maya is visually attractive and can be corrected pretty easily by drawing another path from underneath Maya’s feet. Okay, I lied, I actually played for almost an hour and a half. It was fun.

DECODE GLOBAL will be launching Get Water! on March 22nd, which is also World Water Day and you can expect to see a trailer from them soon. Check them out at http://decodeglobal.org/ or on twitter (@decodeglobal).

Pixelles: A Pre-Showcase Retrospective

adventures in gaming, indie, pixelles, Process Writing

Now that the Pixelles Incubator is over, and that we’re about to show the games next week, I’ve been thinking about the experience. Off the top of my head, it’s hard to say what I learned. However, since I kept a record of my progress each week and uploaded work-in-progress versions of the game to the internet, I do have something concrete to look back on and tell me what actually happened while I was busy not noticing.

In case you haven’t heard anything about this yet, there’s an information page here at the Pixelles website, and I’ll tell you a little bit about my project. I made a game called Diver Quest, where the player is a scuba diver who wants to dive safely but also take advantage of the most opportunities possible while under the water. Players interact with wildlife and their environment to gain a score, and they can also collect lost objects that other divers have left behind, which is just generally a nice thing to do. The lost objects, however, are cumbersome, and so having them depletes the player’s air more quickly. The diver’s goal is to leave the dive site with at least 500 psi of air, which is a safety margin just in case something were to go wrong, and to follow the diver’s motto: Take only pictures, leave only bubbles. That means cleaning up lost diving equipment and not interfering with the environment.

An archive of my weekly posts and those work-in-progress games is available here, where this post will also be eventually archived.

The things that seemed insurmountable challenges at the beginning of these six weeks are now a matter of course. In the first two weeks, everything in Stencyl was a struggle. Everytime that I wanted to create an event, I thought that I would have to reinvent the wheel. Once I discovered StencylForge and understood the syntax of Stencyl, especially in regards to what types of events I should be creating (trust me, there’s a huge difference between ‘When Creating’ and ‘When Updating’), things started to fall into place. I started to be able to predict problems in advance within my events, and to be able to fix them before I even tested out the game.

One of the most fascinating revelations for me was learning why, especially in programming (not that pulling blocks around in Stencyl is on the level of the amazing programmers that are out there), there’s a way to do things that works, and a way to things that’s the right way to do things.

My “favourite” bug was where I realized that my character wasn’t getting damaged by an object, checked the settings, and realized that there was a time period where the player was invincible after being damaged. Since my “air” is technically a modified HP bar that is decreased every second by a damage command, my character was constantly invulnerable to all other forms of damage – including, it turns out, damage that should have been happening at a timed interval to decrease the air bar. Once I made the character vulnerable again, it turned out that not only the rate at which she was being damaged was far too fast, that rate was getting exponentially faster because, instead of a time event, I had the damage as a ‘when updating’ event. Her air was depleted in seconds, and it took me about two days to figure out what to do about it. But I did figure it out, so, for me, it was a bug that allowed me to gauge my own learning curve, my own progress.

My least favourite bug is one that I have no idea how to fix, and seems to be inherent to the fact that Stencyl is flash-based. When I sent my game off to Pixelles, half of the features of the game didn’t work in the .swf but worked fine if tested through Stencyl in-browser. I have no idea why this is and there’s no mistake in my code…It seems that it’s just one of the idiosyncrasies of what’s an otherwise pretty decent tool for a beginner who wants to make games but doesn’t know how to code and it’s available for mac and PC (since I use both interchangeably but don’t have a windows emulator on my mac, this was important to me). The basic version also happens to be free. So while I’m definitely not trying to knock the software that allowed me to make a game, this bug was a total mystery to me and I have no idea why it happens. We got around this by means of a cheat: I sent the entire Stencyl project over to the ladies at Pixelles and they were very good about it.

This is almost my first game: as it turns out, I ended up participating in Global Game Jam 2013, and made a game as part of a team. I started this game first though, and it’s my first solo game. Global Game Jam turned out to be a huge boon to me, because, at GGJ, I learned the basics of how to mix sound there, and how to use the texture stamp tool in Photoshop. These skills made Diver Quest much better, because without them, Diver Quest would have had no sound and a much less nice level background.

This game also used almost none of the skills that I would have expected to be my talents as a game maker: I’m a writer, so I thought that I would have used that much more than I did. There is one screen that’s rather text-heavy, which is the instructions page. I also love to draw, but the aesthetic that I chose to go with was 16-bit, so I didn’t end up doing a lot of character sketches or concept art – I just drew my pixel art directly into photoshop. I really like the aesthetic – drawing fish and safety cones pixel by pixel was a fun experience. Designing a simple pixel-version of a diver was also a challenge that I gleefully accepted. Most of the equipment is pretty accurate, in the end.

I think that spending so much time with one game, it becomes difficult to judge it for yourself. I would love to hear some opinions about the game – if you’re in Montreal, you should consider coming out to the showcase. If you aren’t, after the showcase I’ll be finding a place to host the game online (assuming that I find a way to upload it as a .swf where the regions work!).

You can expect to hear more from me about the actual showcase experience! With photos!

Pixelles Week 6: Game Over!

adventures in gaming, indie, pixelles, Process Writing

So, I just sent in my game to the ladies over at Pixelles. I have an essay to write and I can do no more! So I figured that it was best to ship it off and then take a quick break to write to you about the past week’s experiences.

This week, I implemented a larger level in the game and tried to make the rules work towards an at least slightly challenging gameplay experience. What I found this week were bugs, bugs, bugs! There were events that contradicted each other and a lot of interdependencies where if I changed one thing, I had to change a whole lot more. My biggest problem is timing: I realized that my character was invincible for a small margin of time and so wasn’t getting damaged the way that they were supposed to. When I removed the invincibility, all of a sudden the player’s life was depleted in seconds! I had to entirely change the type of event that I used to create my decreasing air bar.

I also ran into a problem where, in the screen with the larger level, I couldn’t just tell the actors not to go off of the screen width. I needed the characters to be able to move around in a larger scrolling level – but not just a scrolling level, one where you had to exit back from where you came from.

It also took me a long time to tweak the level score to make sure that achieving the high score was doable, but not too easy. I don’t know if I’ve quite got it perfect, but I keep having to remind myself that the project was, in around 4 hours a week, for six weeks, to make a basic game. It’s short, but it’s got basically all of the elements that I wanted to include except for multiple levels and a couple of the more challenging conditions of diving such as currents, dangerous objects like fishing line, etc. I also had a weird bug where if the player got caught between two other actors, the game would freeze. I hope I’ve fixed that by making one of the actors a sensor that the player can pass through.

So, while it’s not the most challenging or sophisticated game yet, I did make it all myself. That feels good. And I feel like people seeing it for the first time might feel differently than I do about it, since I know every detail and objective and a new player will have to discover it for themselves.

If you want to play the final product, come to the game showcase on March 9th! I’ll see about finding it a home on the internet after that.

I couldn’t leave you with nothing, though! Here’s the background of my one working level:

The Background of my one working level.

The Background of my one working level.

Pixelles Week 5 Homework

adventures in gaming, indie, pixelles, Process Writing

This week is Concordia’s Reading Week, so I took off to a cabin in the woods for a few days and didn’t have internet access. So, late post! The Pixelles homework this week was just to work on our games. Out of my new goals for last week, here’s what I got done:

– The aforementioned feedback page/end of level/score page needs to be created.
I created a very simple end of level page that displays the score. I wanted it to count the number of objects collected and the amount of HP left and add that to the score, but I’m not sure how to do it. This is a stretch goal if I have the time.

– Now that I have a functioning score system, I want to add more challenges, obstacles, and ways of earning points to the level. Time will be a factor but right now there’s nothing preventing the player from collecting points. I need things to get in the way!

I didn’t get the chance to do this but found the levels too small – so I remade everything in 800×600 and kept the characters and objects the same size. This did introduce a problem though: my world-map stuff isn’t where I placed it, and even when I replace the objects, they always end up to the left of where I placed them. I need to figure out what’s going on there this week.

– Linked to the above is level-creation. I have a pretty-much empty test level right now. What I want to do is add objects and backdrops to that – hopefully implementing these as part of the challenge of the level.
Still working on it! Limited internet access meant limited means of looking up solutions to my problems.

– Colouring/refining my sprites both to differentiate them and to make them look nicer.
I did get to do this! I’ll save showing you guys until it’s time to show the whole game though.

– Creating at least one fully playable level with everything that I want to implement.
This is not yet done – I think when I’ve accomplished this, I’ll have finished the simplest version of the game.

– Right now, there’s a small problem when you exit the level (which should be fixed by having an end-of-level screen): upon re-entering the test level, the air for that level resets but the score doesn’t. So, that’ll need to be fixed.

This was fixed by means of a kind of “cheat” – now that there’s an end-of-level screen, exiting the level finishes the game and displays the player’s score.

Okay, so this week’s goal is to finish the game. That means:

– Fixing the bug with my map – I think I introduced this bug by changing everything to 800×600 res, but I have no idea why even recreating the level didn’t fix it. ???

– Creating a fully playable level with at least a little bit of a challenge to it – obstacles and such. Maybe some kind of maze or a stricter time limit will help.

My Stretch Goals (if I have the time) are:
– To add the air remaining at the end of the level to the player’s score.
– To add two more frames of animation to my diver’s motion.

Next week, this’ll all be over and I will have created a simple game in six weeks while juggling my other responsibilities. What a cool challenge!

Pixelles Week 4 Homework

adventures in gaming, indie, pixelles, Process Writing

So, the homework for the Pixelles Incubator Follow-Along this week was to continue making our games. Last week, I posted a list of things that I wanted to do and didn’t get the chance to, and things that I wanted to do but didn’t think I’d get the chance to. I’ve decided to check goals off that previous list (and report any other progress) and create some new goals.

Last week’s lists
What I had hoped to accomplish but didn’t this week was:
– Having a scene transition when the player pressed enter around an object on the world map – like the submarine or airplane, which are going to be my two playable levels for the purpose of the Pixelles incubator.
Instead of pressing enter, what now happens is that when the player enters a region surrounding (in this case) the airplane, they transist to another scene. Right now, that scene is my test scene. You can also exit my test level back to the world map screen.
– Having a second diver sprite who would follow around my main character.
Yes! I reused the same sprite, and for some reason the sprite can’t turn around (when I go to the left of my screen, Buddy follows me fin-first :/) but I’ve accomplished the following-around part!
– Having the fish move in a set pattern (right now you can push them around the screen if you want to be mean to them!).
They now move around like sheep would in a random pattern within parameters that I set.
– Assigning a points-value to the fish and some other objects that would then be added to the score when you interacted with them.
Yes! In fact, the fish have a points-value and you can only collect points once. The other objects also have a points-value but can also negatively impact your air consumption! (So some objects add to your score but decrease your HP…in this case, my air meter.)

What I didn’t expect to accomplish but still need to figure out (and that I expect to be fairly challenging):
– Assigning different rates of air consumption at different assigned “depths” – I might just make it vary with the level.
So far, my solution for this is to make it vary with every level. The levels are going to be relatively small until I do something about it, so I don’t think it’s worth worrying about.
– Assigning a faster air consumption rate when the character is carrying something (oh, and making those objects carriable, period).
Instead, I’ve made the objects disappear like coins when you pick them up, and they automatically decrease your air supply but up your score.
– Actually creating a decreasing air bar!
I did it! What I did was create a health bar, and every second as the game updates, the health bar takes damage, thus decreasing the air.
– Actually creating a way to accumulate points.
Yeah, this was primarily about learning to use the Stencyl resources – it’s strange to me that they can all be opened in several different views. But now you can indeed collect points in my game.
– Creating a feedback page after each level where The Divemaster tells you what you did well and assigns bonus points and such as described in my design document.
This is the only one that I didn’t manage to do, and I imagine that it’s going to be fairly simple once I figure out how to end a level properly. Right now, you can die though – and there’s a quick message which then takes you back to the title screen. I need some kind of score-saving tool/points screen.
Oh, and I also decreased the level of text at the beginning down to two screens…hope that’s short enough.

Okay, so new goals!

– The aforementioned feedback page/end of level/score page needs to be created.
– Now that I have a functioning score system, I want to add more challenges, obstacles, and ways of earning points to the level. Time will be a factor but right now there’s nothing preventing the player from collecting points. I need things to get in the way!
– Linked to the above is level-creation. I have a pretty-much empty test level right now. What I want to do is add objects and backdrops to that – hopefully implementing these as part of the challenge of the level.
– Colouring/refining my sprites both to differentiate them and to make them look nicer.
– Creating at least one fully playable level with everything that I want to implement.
– Right now, there’s a small problem when you exit the level (which should be fixed by having an end-of-level screen): upon re-entering the test level, the air for that level resets but the score doesn’t. So, that’ll need to be fixed.

Here, have a test-run of what I managed to implement this week!

My Take on Gaming Beyond Screens

indie, playthroughs, Process Writing, research, talks

So, I didn’t take place in the two-day workshop before the Gaming Beyond Screens symposium and arcade, but I was privileged to hear four great gamemakers talk about motion gaming and then had the chance to play their games. Here are some thoughts.

(If you missed the Symposium, there is a video here – if you missed the arcade, I can’t think of any other time that these four games will be presented together in the near future – sorry! Lucky for you, I took pictures, and there’s also this great video of some of the gameplay, but as we’ll see, it’s the opinion of at least one motion game creator that you can’t judge a motion game by watching somebody else play it.)

SYMPOSIUM

Jim Toepel

First up was Jim Toepel, one of the lead developers of Dance Central 3, and also actually an ex-rocket scientist. I thought that was pretty cool. Jim’s talk focused primarily on the actual development of motion gaming: common pitfalls, misconceptions, what makes a motion game fun, and quite a few tips on how to develop one that won’t drive the creators crazy while they do it.

Jim emphasized the challenges that motion gaming controls present, because the kind of input that players are, well, putting in, is much more complex than it ever has been before. While many people complain about the input devices themselves, the truth is that the range of movement and possibility attached to a human body is about a thousand times more complicated than pressing buttons with your fingers and thumbs. This problem is compounded when we consider that, while mostly you can expect everyone to be able to press those buttons with their hands, there are a lot of different levels of ability just when it comes to moving our bodies.

Jim’s point about the difference between playing a motion game for yourself and watching someone else play was also extremely well-taken. It is almost literally the difference between being out on the field yourself in a team sport versus sitting the bench and watching other people play. We enjoy movement – and we also enjoy learning. Those are two things that motion gaming combines very well – learning how to play is part of the pleasure of motion gaming – and of course there’s no such thing as motion gaming without movement.

The other points that I took away from Jim Toepel’s talk were about avatars and voice commands. Not to be oversimplistic, but avatars can make people uncomfortable as there’s a kind of uncanny valley feeling to watching an avatar move with you on-screen. Also, Jim says that people who play motion games like the idea of being themselves, so avatars may not be working to a game’s advantage – there’s the risk of alienating your players. And lastly, on voice commands: the Dance Central team found out fairly quickly that if they told people what to do via voice commands, they were a lot more likely to correct the aspects of their play that the voice commands told them to correct. And so, Boomie the anthropomorphic boombox was born, voice-acted by an in-house artist from Harmonix.

Kaho Abe

Next up was Kaho Abe, creator of Hit Me (amongst a slew of other amazing games including Ninja Shadow Warrior, where you get to hide behind things and your score is posted to a tumblr, and one called Mary Mack 5000 where you get to play patty-cake games to rock versions of the songs that go along with them). Kaho’s topic was Costumes as Game Controllers.

To start off, Kaho discussed how she built Hit Me out of hacked doorbells and cameras, and her interest in face-to-face games such as Hit Me.

Kaho talked about where her inspiration for her games comes from, especially for her upcoming game about lightning bugs. There’s a Japanese children song about lightning bugs that was the genesis for the initial idea. She talked about the gesture of handholding that persists throughout a game like ICO, an art installation about becoming a bird, cosplay/LARP, and also about shows like Kamen Rider, where putting on a costume, coupled with acrobatic feats, signals transformation. Kaho discussed how when people put on costumes, they become powerful – as in the case of Wonder Woman or Iron Man.

She also discussed her prototyping process for the glove from her upcoming game. She showed off the prototype at different stages – and it was really, really neat-looking. Kaho also talked about her interest in cooperative gameplay between people wearing different costume parts. The example that she gave was one player wearing a backpack that acted as a powersource, and the other player carrying a gun that is powered by that backpack. The players would have to collaborate to be able to shoot.

Doug Wilson

Doug Wilson of Die Gute Fabrik and one of the creators of J. S. Joust. Doug talked a lot about folk games, the playground, and subversion of the intended use of games technology. In an auspicious start, Doug talked to us about Dark Room Sex Game, which was a game that he and a team created for a game jam a few years ago. He told us that one of the greatest successes of the game was the awkwardness that it created without the release of catharsis. Dark Room Sex Game is a game that has basically no graphics – and Doug says that that helped increase the awkwardness. Since there was no cheesy animation to laugh at, catharsis was blocked by the fact that the action of the game took place within the mind’s eye, making it all the more effective.

One of the highlights of Doug’s talk was when he discussed new folk games that are coming out of Denmark, such as “Sneaky Lance” – a game where two blindfolded players move in super-slow motion until one of them is able to whack the other with a wooden spoon. You can bet that I’m going to give that one a try.

On the subject of subversion, Doug talked about the rhetoric of progress: how technology (such as motion gaming technology) is often marketed as making things (especially games) ever-better. Doug seems to think that technology is maybe taking itself a little too seriously. He prefers to think of motion gaming as slapstick comedy. The thought is appreciated – it’s true that motion gaming can put us in awkward positions, and that’s part of the fun.

For Doug, part of the fun of creating games is subverting technologies and their intended use. For example, in his game, B.U.T.T.O.N, he has turned a non-motion gaming Xbox controller into a motion gaming controller just by telling people to leave the controller and walk around doing what the game tells them to – eventually, they are all called back to the controller and the first person to press their button wins the game. Naturally, this creates a mad dash to the controller where people might bodily throw each other around or get into a fight in their attempts to reach their button. Lately, he’s been working on a trampoline game – which he says is cheating at game design because trampolines are already so much fun on their own.

Bart Simon

Bart Simon is one of the developpers of Propinquity and of course the current director of TAG, as well as an associate professor at Concordia. Bart’s talk was about his impulses as a game creator concerning the kinds of games that he would like to create, and how he thinks about motion gaming in particular.

Bart began his presentation with this quote from Shakespeare’s A Midsummer Night’s Dream (which is, by and large, one of my favourite plays, and also a really excellent tea from DavidsTea):

And as imagination bodies forth
The forms of things unknown, the poet’s pen
Turns them to shapes and gives to airy nothing
A local habitation and a name.
Such tricks hath strong imagination,
That if it would but apprehend some joy,
It comprehends some bringer of that joy;
Or in the night, imagining some fear,
How easy is a bush supposed a bear!

By framing his talk with this image of “the bodying forth” of imagination, Bart reminded us of the visceral qualities that motion gameplay, in his opinion, could possibly have. For Bart, this “bodying forth” makes imagination seem like something that the body does as a kind of reaction or mechanism. The kinds of games, then, that Bart would like to produce, are those that would allow players to appropriate the game as a bodying forth of imagination.

Bart, like Jim Toepel, is interested in the learning curve behind motion gaming. Rather than the expert motions of someone like John Cleese performing a silly walk for a Monty Python Sketch, Bart is interested in the joyful motions of say, teenagers mimicking John Cleese doing a silly walk. Bart thinks that the second movements are much more fun, and much more interesting. Case in point: the Star Wars Kid, and the playground antics of basically every child who has ever seen a playground (or a Star Wars movie) and wanted to pretend to be a Jedi. It all comes back to the fun of joy in the accidental, and pushing the limits of our coordination and our daring.

I am really, really sad to have missed getting a shot of Bart playing with the retractable lightsaber that he brought along for the occasion.

THE ARCADE

Talking about these games is not the same as playing them, so I don’t know how much I can say that’ll be all that interesting to anyone who wasn’t at the arcade. I brought along my tallest friend (6’5″) to play Hit Me with, and he basically proved beyond the shadow of a doubt that Hit Me is the tallest player’s game. I also finally got to try Propinquity, which I have been wanting to do since I heard that it existed, and I really wish that I could own my own copy of the game. I had so much fun – and I would love to develop some alternate play conditions – or really just get the chance to play around with it again. Dance Central was excellent – it was a lot of fun to play as part of a crowd instead of just with a crowd watching. The same is true of Joust – I didn’t get to stay until the Joust-in-the-Dark part of the arcade, but I had a blast in the round that I did play.

In case you missed it, here’s a link to a video of the arcade. If you’re curious about the kind of live-tweeting that I did for the event, you can visit @jekagames.

Without further ado, here’s the gallery of pictures that I took during the arcade.

gbssmall-24

Pixelles Week 3 Homework

adventures in gaming, indie, pixelles, Process Writing

This week’s Pixelles’ homework was a lot less defined than other weeks and so I think my focus ended up being a lot more diffuse as well. I guess the easiest way to track my progress this week is to make a list of the things that I did and the major things that I still have to do before I have a working prototype of the game.

This week, I worked a lot on art and basic movement. I made a title screen, a set of instructions, a world map, and an interim level (not one that’s an actual destination but one to test). I also made several sprites – the animation isn’t perfect but I feel like that’s in the details. I made a scuba diver who moves in two frames, a pike, a sunfish, a weight belt, a snorkel, a submarine and an airplane.

For your viewing pleasure, here they all are:

My animated diver.

My animated diver.

My weightbelt object viewed at 1000%.

My weightbelt object viewed at 1000%.

My sunfish sprite viewed at 1000%.

My sunfish sprite viewed at 1000%.

My submarine viewed at 1000%.

My submarine viewed at 1000%.

My snorkel viewed at 1000%.

My snorkel viewed at 1000%.

My plane viewed at 500%.

My plane viewed at 500%.

My pike sprite viewed at 1000%.

My pike sprite viewed at 1000%.

On the world map, the character is able to move around without going out of bounds and the same is true for the diver in the interim level.

I’ve uploaded the game here so that you can give it a shot. For the first couple of screens, click through with the mouse. But don’t forget to move around and run into my submarine and my airplane on the map!

I also made a sound effect – it’s a scuba diving regulator and then the expelled bubbles. I used resources from creative commons and freesound.org and a program called Audacity to adjust the pitch, tempo, speed, and the fades.

scubabreathing

What I had hoped to accomplish but didn’t this week was:
– Having a scene transition when the player pressed enter around an object on the world map – like the submarine or airplane, which are going to be my two playable levels for the purpose of the Pixelles incubator.
– Having a second diver sprite who would follow around my main character.
– Having the fish move in a set pattern (right now you can push them around the screen if you want to be mean to them!).
– Assigning a points-value to the fish and some other objects that would then be added to the score when you interacted with them.

What I didn’t expect to accomplish but still need to figure out (and that I expect to be fairly challenging):
– Assigning different rates of air consumption at different assigned “depths” – I might just make it vary with the level.
– Assigning a faster air consumption rate when the character is carrying something (oh, and making those objects carriable, period).
– Actually creating a decreasing air bar!
– Actually creating a way to accumulate points.
– Creating a feedback page after each level where The Divemaster tells you what you did well and assigns bonus points and such as described in my design document.

If I can achieve this by the end of the Incubator, I will be ecstatic. If I have to simplify, that’s good too. After these goals, I think I’ll feel free to better the game art and animation at my leisure and create new levels when I have the time.

Pixelles Week 2 Homework

adventures in gaming, indie, pixelles, Process Writing

I got a bit behind on my Pixelles homework this week, but with good reason: I participated in the Global Game Jam this weekend! More on this in a later post though. I started the homework before the Jam, and this is initially what I had to say:

“The week 2 homework for Pixelles is considerably more involved than week 1. I like it. It comes at a busy time because of some of my classwork, the fact that Global Game Jam is this weekend, and that this Saturday is also my birthday. But, as usual, challenge accepted. Here’s the homework checklist which I’ve shamelessly grabbed from their post:

Homework

Pick a game-making tool for your game!

This was tough, because deciding which game-making tool to go with involves trying to use each tool and see which one fits. Until further notice, I think that the nature of my game will lend itself well to Adventure Game Studio. I want to be able to easily create environments that a character can wander through, without the goal being immediately obvious. From what I can tell, AGS will lend itself well to that.”

And that’s what I had so far. Well, since then, I purchased an old, beaten-up MacBook Pro for 250 dollars off of kijiji, and AGS is windows-only. That means I have two choices: work only with AGS at home (and work on other things when I’m out and about), or change engines. I don’t know what to do! For now, I’ve decided to stick with AGS and turn in my homework a little late. On to the rest of the homework!

Get your game environment set up — have the tool, basic scene, and your placeholder data ready to work on for next week. It’s OK if your character doesn’t move, for example, but have a placeholder image (if your game has characters) to represent it.

I have my tool ready. I’m planning on using AGS (and possibly Stencyl if that doesn’t work out). I’m working on sprites right now. Here’s a top-down view of my scuba diver sprite for the map, no colours, at 1300% view.

topdown view

topdown view


I want to leave some of this a surprise for when the game is actually ready, so that’s all you get for now!

Write a concept document for your game using the example template. Remember you can and should use lots of images, even ones from Google image search, to get your point across.

Here’s my game design document, but I’ve decided not to include images: DivingGameConcept
Writing this document went a lot more smoothly than I thought it would – I guess I’ve been thinking about it a lot!

Create a level from scratch in your game-making tool of choice (for example, Stencyl or GameMaker) OR create a short interactive fiction story! You can use Twine, Inklewriter, Story Nexus, or any other tool you like.

I interpreted this as meaning a level for my game rather than just a random level. So far, still working on this. But hey, GGJ 2013, amirite? But if it does mean a random level or an IF, then I’ve done both this week.

That’s all for now! I hope to be able to get more done next week, since this week was particularly busy for me.
Meanwhile, check out the page for my game, Legacy, on the Global Game Jam page!!!