adventures in gaming

Curious Games: I Broke It

adventures in gaming, curious games, indie, Process Writing, research

Last week, I was considering different solutions for altering the conditions of play and mood in my game. Pippin suggested that I use attributes, which can save certain information across scenes and across play sessions. What I decided to do is create different scenes and make them virtually identical to the initial scene, the only differences being the mood music and anything that I choose to add to increase the atmosphere of either euphoria or fear. I realized that it doesn’t even matter if you can play Tic-Tac-Toe in those versions of the scenes as long as the countdown is consistent across them and so is the number of games won. That seems doable.

However, after I duplicated the scenes and the code and made sure that code was pointing to all the right objects within the world, I somehow broke the other scenes (which means that really, they weren’t working in the first place). In the first instance, the console no longer appears even though I have visually placed it in the environment as an actor. Also, I am unable to move the actor that is supposed to move the camera around the level. The other level has the same problem, but compounded: neither the inflator nor the console show up in this level.

I’m going to debug by enabling and disabling parts of the code and seeing what I can do. Not looking forward to this! But that’s all part of the process, right? Then again, so long as I can get the camera to move, I am thinking that perhaps there’s a certain logic to not having those elements in those levels.

By the logic of the game, a euphoric person thinks that there’s nothing wrong in the world, and wouldn’t be concerned about readings on their console that say that they only have so much air left, or are at a certain depth. Similarly, in the “fear” level, the loss of the inflator could be considered a kind of loss of control over the player’s circumstances. But I still want to figure out what’s wrong. If I end up leaving them in, I want it to be intentional, not because I couldn’t figure out how to fix it.

I’m also getting very close to the point where I can no longer put off adding Tic-Tac-Toe to the game because a lot of things (like testing that score stays consistent…unless I want to program artificial scoring conditions) will only be able to be properly tested once I do that.

The rest of my work will involve adding more and more – Tic-Tac-Toe is the last absolutely essential element. That means more crazy euphoric animations of dancing fish (I have decided that this needs to be a thing in my game), more flashing lights, more bizarre decal-style photoshop brush effects appearing in level, more ominous things like perhaps dead fish floating around…More camera shake!

Please enjoy this picture of a fish. More soon.
sunfish

UPDATE: I appear to have fixed the motion problem (I just had the actor’s speed set too slow) but apparently my sound is creating some of my bugs.

Curious Games: Novel Design Ideas

adventures in gaming, curious games, Process Writing

Think of an object that you’ve been using more or less your entire life. It’s better if it’s an object that uses electricity/has some complexity, but any object will do. Now, in two minutes or less, develop a new use for that object.

This is an exercise that we completed in class this week, first with a keyboard as our object, then with a trackpad and mouse. One of the ideas that my group came up with for the keyboard was the most interesting to me. It involved swiping the keys on the keyboard from one end to the other in order to accomplish something on-screen – perhaps something like shooting in a first person shooter, where the rate at which the player swipes affects the rate of fire, the charge of the weapon, etc.

I have a picture in my head of this actually being for some kind of magical ability – maybe like shooting a fireball or some other kind of magic missile. I think that there is a “sweet spot” rate of swiping, probably the longer that you press, the more charged that the projectile is (meaning that it does more damage), but the faster that you press, the farther the projectile goes (meaning that it goes less far if you take the time to charge it). It would have to be a chain of key presses and releases that sets off some kind of timer that sees how long it is between when a key is pressed and when it’s released, and what the time is between the first and last keys being pressed.

I think that it would be neat if the keyboard were a separate PC keyboard rather than one integrated into a laptop, that the player held at a right angle to themselves and strummed like a harp or something. Maybe a wireless keyboard, so that the player isn’t tied to the desktop.

Although it sounds like a tedious thing to debug, even I can see the glimmer of how to make something like that work on a limited scale in Stencyl, which has “button down” and “button released” behaviour.

Curious Games: Musical Adventures

adventures in gaming, curious games, indie, Process Writing

After finding out about Wolfram Tones, I was adamant that I wanted to use it to make music for the game – specifically, during the “euphoria” and “fear” parts of the game, I wanted to have appropriate music. Well, it turns out that Mac no longer supports the QuickTime plugin in-browser. Wolfram uses QuickTime, so I couldn’t play anything on my Mac as I composed it. That made using Tones pretty much impossible, so I went over to my desktop, made some awesome music, then sent the midis to my email and tried to open them on my Mac. On to the next adventure: the midis can’t be played in Audacity, which is the audio editing software that I’m using. So, at first I tried to find a midi to mp3 converter, but couldn’t find a free one and am too cheap to pay 30+ dollars for something that I likely won’t get much use out of. Instead, I updated QuickTime to QuickTime 7, opened the midis there, and recorded them with the computer’s microphone directly into Audacity. Since I don’t have a recording studio, I had to restart several times as my fiance chatted to me, not realizing what I was up to, as people passed by our open window, and as my future in-laws moved about their house. But, at last, victory is mine!

I now have “Happy Music” and “Sad Music”! I’ll try to eventually get them up here for you to listen to. Meanwhile: Wolfram Tones is awesome, but much easier to use on a PC. Give it a shot!

Thinking about how to implement some of the randomness: I’m thinking that the easiest thing might be to set timers and have the scene change for some of the more complicated of my “special effects” – like the euphoria/fear effects. It would also fix my fish problem (that the character needs to be created in the scene to be able to follow a character in the scene). I’d just have to find a way to keep the score for the tic-tac-toe games consistent across the scenes. That’s probably more trouble than it’s worth, but this is not actually a game about playing tic-tac-toe (did anyone think it was? okay, maybe it is). If I can keep the game board and score consistent across the scenes, then this is the perfect solution (if a bit complex. I’ll of course be looking into other solutions).

Curious Games: Planning Ahead

adventures in gaming, curious games, indie, Process Writing, research

medical malpractice lawyer says: “very nice post, i actually love the web site, keep on it”

Looks like I’m on to something! You keep on it too, medical malpractice lawyer!

So what I have been doing this week for the game is creating assets and continuing to think about design. So far, the very basic Stencyl file has a custom cursor, screen shake that simulates poor motor skills (but there will be much more to mess with the player’s motor skills if I have my way) and a health bar that starts at 2000/3000 PSI.
(Why 2000? Because in diving, it is recommended to reserve 1/3 of an air tank for the descent to a destination, 1/3 exploring that destination, and 1/3 for the ascent.)

Here are two of the lovely art assets that I’ve made this week: the buoyancy control hose and the console – hand-drawn in Photoshop. (I’m not yet sure if I’m going to have the console have static dials, animated dials, or just numbers).

These are modeled after my own BCD, which the player will be wearing.

These are modeled after my own BCD, which the player will be wearing.

I have this desire to make most of the effects in the game randomized or happen at more or less random intervals… I’m sure that this is relatively simple, but I have to look up how to do it in Stencyl. That can make simple tasks seem daunting — kind of like Nitrogen Narcosis! — so I tend to plan things out in detail when I could probably just start implementing features and see what sticks.

Here’s my game plan (or really, a list of tasks that I need to accomplish and features that I want to include):

– because people with nitrogen narcosis have problems multi-tasking/tend to focus very narrowly on one task, I want a fish to swim by sometimes and for the camera/player’s view to follow/pan on the fish. I want the player to have to find their way back to the game board.

– because of that same narrow focus, I want the buoyancy of the player to occasionally cause the player to start to sink down past the game board, and for them to have to adjust the buoyancy to regain the board (and if they over-inflate, they may end up shooting to the surface — I don’t THINK this is too ambitious).

– because nitrogen narcosis can come with feelings of euphoria or fear: I want to adjust the brightness of the game in tune to either a very happy soundtrack or a very unhappy soundtrack. Preferably either can happen at random from a baseline. I may also include some bizarre actors like dancing fish or divers, or decorative decals.

– I want to blur the edges of the screen somehow (the camera shake effect does somewhat do this at higher intensities) to mimic tunnel vision (another symptom).

– I want to find other ways to mess with the player’s motor control — since I think it will be point and click, maybe I can find a way to at random reverse the mouse tracking (I know there’s a way to do this on consoles with the joysticks…I’m hoping there’s a way to do this in stencyl).

– Continuing with motor control, I was thinking that the placement of the pieces on the board should have to be quite specific – that the collision area of the piece should be quite small relative to the entire size of the piece, making it harder to place each piece.

– Because poor judgment (and, at much deeper depths, hallucination) is one of the major symptoms of nitrogen narcosis, I want to perhaps screw with the player’s perception by making the game board appear different than from how it actually is, or maybe make some game board pieces that can’t be dragged, or that can only be dragged so far.

– Because people experiencing nitrogen narcosis can experience slow thoughts: I want to find a way to slow down the player, perhaps by slowing down the controls or the speed at which a game piece can be moved. I don’t know if this is possible with stencyl. Maybe I can do this by creating a mechanic where the player clicks a piece then clicks the place on the board, and the piece travels at a predetermined speed towards the board. I could set the speed of individual pieces to different values, thus making some relatively easy to place, and some more difficult.

– I want to implement a 3-minute time limit on the game in which the player has to win a certain amount of tic-tac-toe games. How many will probably be determined by a lot of playtesting…

– I also want to have there be the chance that the player experiences some of the other minor annoyances of diving, such as a foggy mask or a free-flow (basically when the regulator gets stuck open and starts to spill out precious air — this is usually quickly fixable). I’m not sure if these will make it into the final game but as soon as I figure out randomization, they’d be easy to implement.

– Obviously, I have to program tic-tac-toe. Pippin has told me that he will help me with this. I was thinking that it might be interesting to have the program have some of the same handicaps as the player as a rational for the program making mistakes in the placement of their pieces.

Where I foresee some challenges is in randomizing these behaviours. I know that I can make the camera track a specific actor (the fish) through an environment. (I don’t know exactly how to allow the character to move the camera back.) I know how to make music play at specific times. I also know how to set collision areas and the movement speeds of actors. Largely, learning how to randomize the behaviour and learning to do it within appropriate parameters so that things aren’t totally at random, seems to be my biggest challenge. There are plenty of Stencyl tutorials about this, though. (Although learning to program Tic-Tac-Toe will be another kettle of fish.) I also foresee that I might have some difficulties with making the character navigate the level with the mouse, but I’m already thinking of ways around it.

I’ll keep you posted, Internet!

Curious Games: Tools and Neutrality

adventures in gaming, curious games, Process Writing, research

This past Wednesday during the Curious Games Studio class, we talked about the neutrality (or rather lack thereof) of software and other tools that most people use on a daily basis. Most tools are designed with the expectation that they will be used to create some fairly specific output with some fairly specific methods. The example that we discussed in the most depth is PowerPoint, which encourages an element of performance to the presentation of information and gives users all the tools to create punchy, attractive slides that privilege design over content. Here’s Edward Tufte on PowerPoint – and of course we can do this kind of analysis for nearly any kind of software.

When asked about the software and other tools that I myself use on a daily basis for content creation and how it affects my process, I immediately thought about a relative newcomer in my array: the cellphone, and, more specifically, the Apple iPhone 4S. Having only gotten a cellphone what is now almost six months ago, I can directly trace what impact it has had on my work and on my life more generally.

Now, before December 2012, I had never owned a cellphone and barely had any contact with them – if I had to borrow a phone, it was limited to a few minutes to place an urgent call and that was about it. The iPhone 4S is my first cellphone ever, and it was fairly easy to get enamoured with. It’s also easy to trace how it’s affected my practice and my day to day interactions with people. I decided to get a cellphone because I was home a lot less, I was about to begin a job working with video games, I was under the impression that a lot of indie games are released on iOS (which is the case but most are now pretty quickly ported to Android, so the joke’s on me – but honestly having gone from no cellphone to a 4S, a lot of what my cellphone does still feels incredibly sophisticated to me) and that having a smart phone would be great for live-tweeting journalism.

It used to be that I would fill up the small notebook that I carry in my bag with me about once every three months, taking down appointments, phone numbers, ideas, for writing down what my friends and I wanted to order out, that sort of thing. I also had larger notebooks for taking notes in class and for writing out those ideas in their larger forms. (Oh, incidentally, in January 2013 I acquired my first ever laptop, meaning that in two months I jumped forward about a technological decade.) Now, I’ve had my present notebook since December and there’s barely anything filled in. I’ve begun to take notes on my phone and laptop.

It also used to be that I would spend any traveling time reading books, but now I’m more likely to fiddle with a game or check in on work that needs doing. I used to read about a book or two a week just on transit. Now I’m still stuck on Padgett Powell’s The Interrogative Mood.

My iPhone also dictates, in some ways, what tools I will use on it – certain apps are free for Android but cost money on the iPhone, and vice versa, and since I’m a student, I don’t usually want to pay more than a dollar for an app that I may or may not end up using/liking/needing, etc. – and even then, the apps that I usually don’t mind paying for are things like critically-acclaimed indie games or…well, yeah, mainly those.

Having any cellphone at all has also changed the way that I communicate: it used to be that people could either call me at home and either reach me or leave a message or they could email me. I really liked the fact that if I was out and about, I was incommunicado, untethered and unlikely to be disturbed. Now, I can get called by work while I’m out at social events and of course I get way more text messages than phone calls.

In terms of productivity, my having a cellphone makes other people’s jobs easier – they can contact me when they need something and I can act right away, and they can contact me in real-time to see how the job is going. In terms of my personal productivity, what a terrible thing having a cellphone is! I’m not terrible about the whole obsessively checking my phone thing yet, but I have definitely played ‘Hanafuda’ more than I have read in the last six months, and I think that I can no longer really call Hanafuda “research.” I also waste time that should be spent writing checking things on social media and such, which was less the case when I was limited to my desktop.

On the other hand, and this is a bit of a sidebar, having a laptop has increased the speed at which and the number of places where I can write and accomplish other work. It permitted me to attend a conference the other weekend without any fear of missing important information and updates on my projects, and I am able to write much more quickly than with my pen and notebook since I type much faster than I handwrite.

So, in sum: having a cellphone has changed the way that I communicate and the kind of cellphone that I have has determined what products I use. It has made me more accessible to other people but has made my productivity decrease by quite a lot (I’m currently fighting to push the balance back in the other direction by simply taking the time to think about ideas while traveling instead of playing iPhone games). I do use it for work, having played games that I wanted to research on it, recently recorded an interview with Lynn Hughes and Bart Simon, live-tweeted talks and events, and done some writing/note-taking on it, but the ratio of work to time-wasting that I do with my cellphone is absolutely shameful. On the other hand, going mobile in other ways has had its advantages. I guess that as long as I can work on limiting my time-wasting activities, I’ll survive this personal technological revolution.

Curious Games: Brainstorming

adventures in gaming, curious games, indie, Process Writing

So I’ve decided to make a game about performing a simple task under unusual conditions. The task will be to play Tic-Tac-Toe 130 feet underwater while at least slightly under the influence of nitrogen narcosis, which is basically like being drunk underwater. This usually becomes at least slightly noticeable when divers go below 100 feet and the symptoms disappear when the divers ascend.

Here’s a link to my “Your World of Text” World (be careful: if you edit anything, it’ll be saved) where I’ve been working on a brainstorm that kind of shows my process a little bit. I’m starting to think about mechanics that should be simple enough to code but that will transmit the experience effectively. Ideally, I’d like to switch up some of the mechanics while the player is in the process of playing. I’m not sure if I want to have the controls be based on keyboard or on mouse. There are advantages to both: I can make the keyboard controls be flipped and might be able to actually make the controls switch mid-game.

One thing that I’ve definitely decided is that I like games like B.U.T.T.O.N that make the players enforce rules that can’t be enforced by code/programming/the game system itself. To that end, players of my game will have to wear some scuba diving equipment: a mask, a snorkel, a BCD (Buoyancy Control Device – a vest-looking thing), a regulator and octopus, and either a weight-belt or integrated weights.

Some goals this week: to create some prototypes of the “symptom” program effects and the timer and air limitations.

Curious Games – I wish I were the Moon

adventures in gaming, curious games, playthroughs, Process Writing

[A brief sidebar: I’m taking part in the Curious Games Studio/class with TAG/DCART’s Visiting Game Designer, Pippin Barr. Over the next two months, I’ll be writing about the experience, about my own design ideas, and about playthroughs/explorations of what might be called “Curious Games.” And I’ll be making my own curious game! Here goes.]

I wish I were the Moon by danielben

When asked to identify a Curious Game, I wish I were the Moon came pretty much immediately to mind because I had played it pretty recently back in January for the Pixelles Incubator. It’s a curious game for a couple of reasons. It has a small scale (it’s just this one level and one small frame) and unusual properties, like a curio (a small object – usually an art object or artefact prized for its unusual properties and its ability, through its general weirdness or beauty or something, to inspire thought or discussion or just a moment of pause – that people kept and still do keep in curio cabinets). It also has an interesting gameplay mechanic – the player moves objects in the environment around by taking pictures which can then be deposited in other places in the environment. It also doesn’t have any instructions except the unexplained frame of the box that is the player’s only visible tool (not that it takes any time to figure out how to use that tool).

This is a game with eight endings – as soon as the player finds one ending, the game teasingly (teasing rather than pleasing being another element of a curious game) tells the player the name of that ending and that there are 7 Missing Endings. It also reveals the second game tool: Pressing R to Rewind.

Finding the endings has a puzzle element to it – it’s not immediately obvious what manipulations will lead where and part of the puzzle lies in thinking up new things to do. Killing the characters in the game in a variety of ways leads to valid if not “happy” endings, inasmuch as the game seems to be asking the player to find all eight endings (most are fairly tragic). I refuse to look at a walkthrough and I still can’t find the last ending. The game is just too charming and I keep trying different combinations. (UPDATE: I’ve found at least 9 endings now.)

The fact that there is no “right” ending is reinforced by the emoting of the characters on the screen – when the human pair are together on the boat and the Moon is high in the sky, one character looks sad and the other looks worried. Actually, that ending is called “Lost Love” – and of course I can’t ignore that the game’s title is I wish I were the Moon. Who then, is the I?

NOTE: Please play the game before reading further on – there’s potential spoilers just in the names of the endings.

Replaying the game reveals a great depth of narrative – the names of the endings and the simply but clearly illustrated emotions of the characters seems to reveal a story of unrequited love: a woman, in love with the man on the moon – a man who is in love with the moon. If the man sends her away on an (albatross? that’d be symbolic bird), he is telling her to be free, but she cries into the ocean forever. If she tries to join him on the moon, it’s disastrous – she doesn’t belong there and they all sink into the sea. If either of them dies, it’s a tragedy. If they go down together, the woman is selfishly saying that if she can’t have the man, then nobody can. If the man comes down to live with her, the moon will return to its place in the sky, but he will always regret it, and the woman cannot comfort him. If she takes his place on the moon and lets him be free, she loses her reason to live. If she switches places with him, then the moon stays close, the man gazes up lovingly at the moon, and the woman can imagine that he is also gazing at her. So, then, for me, the I was definitely this woman, suffering through an unrequited love that she nevertheless cannot imagine losing.

(I also found an ending just titled “Sunk Boat Secret Ending” but it doesn’t really fit into my story.)

UPDATE 1: I discovered another ending where you can give the far-distant moon to the man to hold — but that doesn’t help our woman with her unrequited love much either.

UPDATE 2: There are actually at least 9 endings.

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.