Skip to content
November 14, 2011 / William

Real-time Multimedia – Final post

So: we come to the end of the mad journey that spawned Hydration, my somewhat stunted brainchild (like most of them, actually). I suppose I should go over the major points in this twisting tale. This summation and reflection will largely focus on the tail end of my process since that’s where/when most of my effort was concentrated.

 

As my earlier posts demonstrate, while it took some time to settle on the core concept for my game, I quickly came up with lengthy lists of possible features. This quickly became fused with the idea of incorporating a seasonal theme, which would colour (literally) elements of the game. As this was still the ‘flush with the infinite promise of new ideas’ stage, I did not think too much about the technical feasibility of many of these elements. This would later become a recurring theme in this project, with ideas not being tested until sometime later.

Essentially, the early phases of my work were heavily focused on designing new and interesting features, as well as thinking about the logical flow and coherence of mechanics (as opposed to feasibility). For example, I spent some time sorting said mechanics according to seasonal suitability; the ‘greatly reduced TTL in designated areas’ idea worked well as evaporation in summer, but didn’t quite make sense elsewhere. There wasn’t too much consideration of technical implementation to begin with.

 

The middle phases of my process (inasmuch as you could neatly split up and categorize the muddled steps I took, anyway) saw me working to check that my ideas could actually be realized. The main critique one could make of these ‘phases’ is that they came in dribs and drabs, since I had to split my attention between multiple assignments. That usually ends badly for most, if not all, parties involved, and this did not look like it was going to be an exception.

I did at least prove that some core mechanics could actually be implemented, even if that did occur quite a bit into the project’s life cycle. This, too, seems to be recurring theme. That is, most of my programming assignments tend to start out grand in scope, and have a great deal of their effort sunk into ensuring that the mechanics are feasible. Any remaining time (usually not a lot) is then spent polishing the (more or less) fully operational skeleton. While Hydration ended up looking more polished than my previous efforts, I’m not sure it counts as a success in that respect.

 

Anyway, on to my recount of the final phases. This is where the most effort and insight poured in. My penultimate posts, below, have already covered the final rounds of designing, the implementation of art assets and technical hiccups. So, I’ll go over my thoughts on the polishing and testing of the various aspects of the game, as well as stitching it all together and handing it in rather late.

Like the art assets, I’d dug a rather deep hole for myself with this. There was a significant amount of art asset creation and positioning, obstacle collision-detection area manual hard-coding and finally gameplay polishing to be done. Worse yet, even up to the end, there were still mechanics that had not been fully proven to work.

As such, the last few days were a wild mess of creating things and mashing them together. As I am a ruinously meticulous person, I went through and tested each component as I created it, ensuring that the finished product would be polished to a high sheen.

 

It was during my constant testing and retuning of the levels that I gained a sudden insight into the net effects of the mechanics I’d put together. Some aspects (like filling up the buckets with an often unreliable stream of water, or breaking a fragile surface by pouring water on it) took too long, so I cut down the numbers involved. However, after that, I felt that the game might have been made too short. That led to the question of, at what point does an obstacle, which is by definition something meant to slow you down, turn from a ‘legitimate’ challenge into simply a waste of time?

Further testing with some test subjects confirmed my suspicions that some of the mechanics (or rather, most, if not all) did not seem to really add any challenge, but instead artificially lengthened things.  Alas, by that stage, changing core mechanics wasn’t really an option.

Long story short, it seems likely that Hydration might not turn out as interesting and fun as intended.

On the upside, I did determine that much more instruction was required on the early levels to help acclimatize users with how the game handles.

 

Additionally, the aforementioned high attention to detail was also my downfall as owing to time constraints, I could not put in everything I wanted/originally intended. Consequently, several features that I had yet to develop (either due to difficulty or simply because I hadn’t got around to them yet) had to be cut, such as:

  • Several levels
  • Timers in later levels
  • ‘Extra evaporative’ zones
  • Correct differentiation between player-drawn surface types
  • A level select option
  • Background music

 

So, in summary, it was a bumpy ride (mostly towards the end) and, as time ran out, I had to cut out and leave behind material like the British at Dunkirk. That said, the resulting product still looks to be fairly interesting to behold, and looks nice and faux-sophisticated.

Advertisements
November 14, 2011 / William

(Belated) Penultimate compilation

This unforgivably late posting compiles progress reports on the things I’ve done since my previous post, not including the final summation and reflection on my process that will take place in the final post, above.

 

After the dust settled from my previous assignments, I launched into action and began working feverishly. Up until this point I had assumed that most of the technical work had been done, since I had proven that a great deal of the core mechanical concepts that my game relied on were feasible. Additionally, I’d already designed the levels and tested most of them.

So, I began this final round of efforts by focusing on the art. As I had been working almost exclusively on the mechanics up to now, the game’s skeleton had a very crude, basic appearance. Thus, I would essentially have to do the entire thing from scratch. This extensive prettying-up would have to cover:

  • Assorted textures for the background obstacles (to cover the four material types and four seasons)
  • Assorted textures for player-drawn surfaces (for each season).
  • New textures for the water.
  • The aforementioned oh-so-fancy soft focus backgrounds (one for each season)
  • UI elements, including the various buttons and bars
  • Shiny new buckets

A rather tall set of orders, as can be seen. Using my meagre skills with Photoshop and recolouring standard Office textures, I set about creating the immense amount of art assets I would need:

Sketches, penultimate

The green and blue coloured shapes seen above represent my early experiments with player-drawn surfaces and water. Those ended up having to be simpler than originally envisioned, since the way they were coded meant that each one would only have a single fill colour. That didn’t exactly allow for nice looking textures. Still, I did manage to make them alternate between two fairly similar colours so as to provide some variation.

 

However, as I went about blurring random swatches of colour to create fancy-looking backgrounds, I realized that there were still gaps in the technical side of things.

While it was simple enough to stick an obstacle’s graphic on the screen and the code already existed to ensure water bounced off it, I discovered that there wasn’t actually a provision for recognizing which obstacle the water was bouncing off.

I could not seem to figure out how to build a sort of ‘sensitive area’ into each obstacle so that collision detection was built-in – or rather, I could build it in, but they were wildly and seemingly randomly off the mark. So, I went about creating a second array, into which I manually hard-coded the desired collision-sensitive areas for each relevant obstacle.

Sketches, penultimate - 2

Obviously, this solution won’t win any awards for elegance or efficiency, but it was simpler to implement than grappling with its significantly more technically challenging counterpart. Also, it works, at least.

 

My time was spent in largely the same fashion as described above – alternating between hammering out art assets and wrestling with recalcitrant code. Somewhere through this process, I realized I’d bitten off more than I could chew, but I (foolishly?) soldiered on anyway.

I tried not to think about the marks I was haemorrhaging with each overdue day, and eventually put together an approximation of my original vision. More details in my final post.

November 1, 2011 / William

(Belated) Another compilation of things

Alrighty – the long overdue update is here. Firstly, I will cover what I’d done about 3-4 weeks ago, around the time of the mid-semester break.

In the lead up to the Week 10 progress presentation, I sat down and sketched out possible user interface and level designs:

Scribblings, 28th Sept

I went through several iterations of the user interface in my attempt to balance a simple, neat design with ease of use and visibility. The main questions were whether to make a primarily horizontal or vertical interface, and on which edges of the screen to place the elements. While I liked the look of vertical elements clinging to the sides, they felt a little too scattered and awkwardly placed, as well as possibly competing for the player’s attention with the game area.

The chief example of this was the resource bar, which was strongly considered to be placed vertically. However, the perceived elegance (if that’s the word) was offset by it appearing somewhat detached and too far away from the other UI elements.

In any event, at this time, I hadn’t quite settled on a final version of the interface.

Scribblings, 3rd Oct

Some level designs for Spring

Scribblings, 4th Oct

Level designs for Summer (top left), Autumn (right), Winter (bottom left).

Following closely on the heels of my preliminary UI designs were the level designs. I had envisioned 3 levels for each season, for a total of 12 levels gradually ramping up in difficulty from Spring-I to Winter-III. Working with a slowly expanding pool of additional mechanics, I attempted to create levels that were both thematically appropriate and sufficiently challenging.

I suspect that I may not completely succeed on that front, since I don’t exactly have a lot of experience with balancing puzzle games for players. That said, I trusted that my own experience playing such games would see me in good stead.

As you may have noticed, these sketches here may be a ‘tad’ undecipherable. In addition to experimenting with positioning for level elements, there are also:

  • Dotted lines indicating intended water travel paths
  • Penned-in elements to make them stand out
  • Shrunk down experimental sketches
  • Approximate coordinates and lengths to help me implement the elements.

After the presentation, I slowed down to deal with some of my other assignments, and things have been languishing somewhat since.

 

Antepenultimate aesthetic musings:

I also did some thinking about the aesthetics of the game. On the one hand, there was the original faux-sophisticated soft focus, artsy and pretentious-y image I had in mind. On the other hand, it had been suggested to me to keep the game looking sketchy (literally), and make it look like exercise book scribblings or a pinned-notice-covered corkboard come to life.

If nothing else, that idea would at least be easier to implement.

Regardless, I did put together some rough mock-ups of the UI based on my sketches, as well as experimenting with the aesthetics:

Sketches, antepenultimate

UI designs

Sketches, antepenultimate - 2

Level texture experiments

 

Yes, those are standard Office textures, just with some tweaking. They work nicely enough for this purpose.

October 2, 2011 / William

Feasible!

After long, arduous hours of experimenting, trawling (not trolling) Processing forums and squinting at undecipherable error messages, I have finally proven two key functions to be feasible (as well as ensuring they don’t crash):

  • The erase function, and with it, the ‘level reset’ function.
  • Getting Processing to accept different values for different material types, such as restitution (which controls how ‘reflective’ it is).

With a working framework in place, I can now move on to the more enjoyable elements of design and implementation.

 

On an unrelated note, it was amusing to see the effects of a high restitution value. The water particles would ricochet off these surfaces at high speeds like bullets fired from a machine gun. This could be taken to ridiculous levels by constructing contained structures so water would keep ricocheting off the highly reflective surfaces.

Restitution1.75
While the ‘release version’ of Hydration will not have water that’s this reflective, this is sufficiently intriguing to consider making another game somewhere down the line.

September 28, 2011 / William

(Belated) Compilation: art, technical detour

As of late, I’ve been wrestling with the technical side of things. Namely, trying to figure out how to implement a working erase function.

Seeing as the core of the game is about drawing things, it would seem rather remiss of me to exclude this feature. I had been toying with just making a ‘level reset’ function to correct errors, but I soon realized that the two were effectively the same thing. If I couldn’t figure out how to remove boundary elements from an arraylist for the erase function, I certainly wouldn’t be able to do the same for the reset function.

But enough of my rambling. As the title of this post suggests, I’m taking a short detour to compile the numerous ideas, thought processes and decisions about art and technical elements I’ve conceived.

 

So, first off, here’s a page of scribblings.

Scribblings, 23rd Sept

Scribblings!

As can be seen, I’ve actually had these ideas for a while, but I was caught up in testing the erase function that I haven’t uploaded them until now.

Anyway. These detail some of the ideas I’ve had for how I might translate my grand vision into the art elements for this game, as well as some of the potential technical points backing them up.

There are also some miscellaneous musings about things like level transitions and the like.

Since then, I’ve also come up with some more ideas. Unlike my earlier ideas, I am now on the verge of wrapping up exploration of concepts for obstacles and other mechanical elements. These ideas concern how I might go about implementing particular things.

  • Overgrowth‘ (as described under spring obstacles, below): while I had vague ideas of an unruly, organically growing mass, it occurred to me that I didn’t quite know enough to simulate that. As an alternative (or cop-out, I guess), I considered instead having a moving curtain represent the encroaching vegetation.
  • Racing fire (as described under summer obstacles): the above ‘moving curtain’ method would certainly match this better. I could use one of the prior particle systems examples to create a wall of fire.
  • Blizzards/bad weather and possibly falling leaves:  expanding upon the idea I had for using particle systems as a cosmetic effect, I toyed with using a billowing horizontal system to simulate these effects. This would work especially well for the ‘invisible barriers’ and ‘black box’ ideas I had, in that I could use a billowing, opaque cloud to hide an area. Barriers could then be placed inside this area, affecting the flow of water unseen by the player.

 

In addition to art, I’ve had a few thoughts about other matters in between grappling with Processing.

 

Background music

My original plan had been to create 12 levels, matching Vivaldi’s Four Seasons’ 4 concertos x 3 movements. In this manner, the background music could also be made to match the levels. After some thought, I decided to pare this back to having only one movement play for an entire season. This was done partially out of consideration for file size, but also because some levels might be too short to justify the full length.

However, this led me to realize I hadn’t planned for transitions. That is, when one reaches the end of a level and it’s time for the next piece of music to start up. The simplest ‘solution’ would be an abrupt cut, which isn’t elegant at all. Ideally, Minim would have some function that allows me to fade in and out. I will have to investigate.

Barring that, I had another idea (though feasibility remains up in the air), involving playing a soft sound that gradually grows louder, then fades again, as the level transitions. The idea is that this sound (probably something like a soothing wind chime type thing) would mask the aforementioned abrupt cut, without need for fading.

 

UI design

This is another element I haven’t really thought about until now, despite its importance. For a while, all I had were sketches for the icons that would represent the four material types the player would have to work with:

Icon sketches

From top: regular, reflective, absorptive/(undeveloped), fragile

I eventually sat down and worked through several layouts that would not only incorporate all the elements, but also still give off a polished, sophisticated appearance.

To this end, I plan to enlist the aid of various wood textures and give everything a vaguely ‘soft focus’ look. Nothing says (possibly pretentious) sophistication in a game like soft focus.

 

Anyway, that concludes my detour into art and other things. When I next post, I should have news from the coding front.

September 21, 2011 / William

More on themes, and solidification

Behold – the results of my rummaging around and playing with ideas!

 

After more thought, I believe I have a workable theme to structure the game around. I will proceed with using the four seasons to provide distinctly separate but still unified themes.

An additional advantage of choosing the four seasons as my theme is that it conveniently solves the background music issue: I can use Vivaldi’s Four Seasons violin concertos. I recall being advised that we could use external materials, as long as they are properly credited and they help complete the game. So, I’ll take that to heart and… acquire some renditions of the concertos.

But first, of course, I had to listen to them to get a feel for them. So I went off to Youtube, and found some performances.

In hindsight, I should probably have chosen four that were performed by the same people. Perhaps something to think about later. Anyway, approximately 40 minutes later, I determined that they suited my purposes perfectly. If nothing else, they’ll lend class to my creation.

The first movements of Spring and Autumn are especially nice. You’ve probably heard them before as stock pieces of ‘upper class classical music’. Summer and Winter are rather less lively, but I suppose they’re intended to come off as bleak seasons.

This ‘research’ (I guess you could call it that) also revealed some sonnets written to accompany the concertos. They contained imagery to go with each season, and provided more ideas for game elements.

 

Of course, all this excitement about fancy classical music won’t amount to anything if I can’t actually put it into my game. So, after some more poking around on the Processing site, I found the Minim audio library. With some fiddling around and reading their quick-start guide, I was able to get Processing to play and stop specific pieces of music (provided they were in the data folder, obviously) at my command. So, the technical hurdle(s) of including the Four Seasons looks to have been solved.  There’s still the issues of sound volume and length/size (since each concerto is about 10 minutes long, their combined file size may well be greater than the rest of the game put together), but I’m sure I’ll think of something.

 

Anyway, onwards with my possibly ruinous fascination with design. Working with the general flavour of each season, aided by the aforementioned sonnets, I then came up with more ideas for mechanics and elements to match (as well as organizing and repurposing some of my previous ideas). These are still a work in progress, however.

They are largely broken down into one of three categories:

  • imposing a time limit
  • serving as materials or obstacles for the player to deal with
  • providing secondary objectives or goals.

Spring

  • Fill bucket before spores/plants overgrow (time limit/race)
  • Fill bucket before winter ice melts and floods (time limit/race)
  • Leaves: extra reflective surfaces (materials)

Summer

  • Hydrate plants (secondary?)
  • Cool down overheated people? (secondary?)
  • Shaded areas to shelter from the sun
  • Surfaces that are too hot or ‘thirst’ (parched plants?): absorptive (materials)
  • Race fire (secondary?)
  • A pool that flashes brightly when hit, eventually reaching blinding intensity (obstacle)
  • Going with Vivaldi’s movements: incorporate storms?

Autumn

  • Falling leaves act as barriers? (obstacle)
  • Fallen leaf beds acting as slowly forming barriers? – gradually increasing rate of blocking water flow through them (obstacle)
  • Fill hollow of rotten wood with water, causing it to break and allowing you to access the area beyond. (obstacle)
  • Going with Vivaldi’s movements: incorporate harvesting, hunting?

Winter

  • Time limit to complete level before water freezes (time limit/race)
  • Blizzards/bad weather block areas from being ‘drawn in’ (i.e. you can’t draw slopes to redirect water within them) and obscure vision: invisible barriers and ‘black boxes’. (obstacle)
  • Thin ice that breaks after X quantity of water has struck it (material and obstacle)
  • Extra reflective ‘hard ice’ (materials)
  • Avoid drenching something or it will freeze (secondary?)
  • Extra-cold stretches that freeze some of the water flowing on it: ‘absorptive’ (materials)

Other:

  • Source of water randomly changes position (link to summer storms?)
  • Mechanics could be re-used and cosmetically altered to serve as progression of difficulty (i.e. say, break rotten wood and thin ice in autumn and winter).
  • Consider allowing the player to switch between different material types to draw with (standard, reflective, absorptive/filtering and fragile). One incentive could be to make the less desirable or efficient ones (like the absorptive one) cost less of the limited ‘material points’ given out per level.

 

So far: music is largely settled. Art to be decided. Mechanics solidifying, but testing will be needed.

September 15, 2011 / William

On themes

It’s occurred to me that I could add some sort of (possibly pretentious-sounding) structure to my currently vague game by basing levels around some sort of theme.

Obviously, it can’t just be any sort of theme. I’m not looking to see how I can make a game about redirecting water that somehow has a strong postmodernist message in it, for example. It would have to be something that could ‘explain’, or at least provide inspiration or a common theme for, the various mechanics and game elements in each level.

The two ideas that I had were:

  • Seasons (spring, summer, autumn, winter).
  • Elements (fire, water, air, earth – and perhaps aether/quintessence, however that works?), or possibly (wood, fire, earth, metal, water).

Both of them allow me to vary the colour scheme of the levels, as well as providing mechanics that match a given ‘flavour’. For example, summer/fire could feature a red-orange background and elements, as well as having fire-themed obstacles – like a wall of fire that effectively blocks off an area.

I’m not sure about having the element of water serving as a theme in a game about redirecting water. Seems kind of redundant, if that’s the word I’m looking for.

Regardless, there is the concern that it may take too much time to ensure each season or element is distinct from each other (in terms of colour scheme and mechanics), lest they simply be cosmetically different but mechanically identical. On the other hand, would that be such a bad thing? It would be a waste to devise a wondrous mechanic that I only use in one set of levels owing to thematic separation.

 

On a somewhat related note: I’ve yet to consider music. I suppose at the very least, as Hydration is meant to be a simple, perhaps even relaxing game, I can narrow down the range of suitable pieces.