You can read about each participant in our post-showcase writeup.

Gillian Blekkenhorst

Cuddlegeddon

Find it online

Yuliya Boublikova

Golden Fall

Find it online

Julia Ediger

Une semaine de bonté: The Game

Find it online

Marie Flanagan

Þink

Coming soon!

Christine Kim

Bitmap

Download Now

Miriam Verburg

Having it All

Play it online

Didn’t make it to the showcase event? Get to know each of these dames and their games a little better before we make them available to download and play on September 1.

Gillian Blekkenhorst

Cuddlegeddon

Gillian is an illustrator who has also self-published comics and zines “mostly about teen angst, faux-religions i made up and ghost stories.” Her day job is in the advertising industry. She came to Jeuxly with some experience making simple HTML games and programming in PHP, and was hoping both to boost her coding skills and get more involved in the indie game community in Toronto.

Gillian is into point-and-click adventures and puzzle games, spooky stuff and non-linear narratives. Her game, Cuddlegeddon, tackles a cognitive psychology narrative in the form of a two-player co-op that inverts the competitive Pong model.

You can find some of her work at blekkenhorst.ca and follow her on Twitter at @gblekkenhorst. 

Yuliya Boublikova

Golden Fall

Yuliya is a graduate of the animation program at Sheridan College, with credits that include the Comedy Network series Ugly Americans and the stop-motion film “Icaria,” to be seen at the Montreal Stop Motion Film Festival and the Northwest Animation festival in Portland. She participated in Jeuxly with the intent of using her animation skills—and picking up the technological/programming skills—to create a game that reflected her artistic sensibilities.

The concept for Golden Fall came together early in the incubator: A side-scrolling platformer, starring an Indiana Jones-styled squirrel. She focused on introducing interesting mechanics and refining her game world, which employs a unique and very appropriate vertical level design.

You can see more of Yuliya’s work at “yuliyaboublikova.com”:http://yuliyaboublikova.com

Miriam Verburg

Having It All

Miriam is a 10-year veteran of the interactive industry, with a work history that includes project-managing game dev teams at zinc Roe games and various web development projects for non-profits and charities. Inspired by the DEI panel at the TIFF Nexus Women in Film, Games & New Media Day, as well as DPAD (which featured games made by participants in DMG Toronto’s first incubator, JAMuary),

Miriam applied for Jeuxly with the hope of complementing her planning and design background with the hard skills needed to create a game on her own. She identified “turning theory into labor” as her biggest challenge.

Her game, Having it All, is a platformer about false dichotomy.

You can find her on twitter as @mirverburg. 

Christine Kim

Bitmap

Christine is a video game theorist and a recent master’s graduate at OCADU in the New Media Art History program. After discovering DMG Toronto through the JAMuary exhibition at DPAD in February, Christine applied for Jeuxly. She hoped to combine her deep theoretical knowledge about gameplay and games as art with experience with the practical side of game design and development, and thought the accountability and supportive environment of an incubator would suit her well.

Best described as a “snake hell maze,“ _Bitmap_ is a retro-inspired arcade game influenced by her love of Katamari and Japanese bullet-hell games. The level design is informed by the work of visual artist Alina Sechkin, with music from chiptunes musician Oxvylu.

Through Jeuxly, Christine feels she has gained the skills she needs to experiment freely with games as an artistic medium. 

You can find her on Twitter at @limbtolimb. 

Julia Ediger

Une semaine de bonté: The Game

Julia is an illustrator, comic artist, and animator who is also interested in technology, web development, and surrealist literature.

She loves the idea of games with innovative or non-linear narratives, and hoped to be able to use her Jeuxly project to explore game-driven narrative concepts in a structured environment.

Her highly visual memory game is based on the 1934 graphic novel Une semaine de bonté. Successful players are rewarded with a “Surreal Fortune” that can be shared on Twitter.

You can find her on Twitter at @reynardin. 

Marie Flanagan

Þink

Marie is happiest when making, and has built things from earthtainers (to allow for growth of plants without wasting water) to social enterprises. She came to Jeuxly hoping to add a game to the list of things she’s made, and to do so in a structured  and supportive environment where feedback and questions were welcomed.

Marie is intrigued by how non-linear narratives can be used in games as communication tools. Her game, Þink (pronounced “Think”), explores creating, growing, and harvesting ideas in a very tactile, minimal way. She hopes it can be used as a practical tool to help players explore ideas within the specific constraints of the plant-growing metaphor.

You can find her on Twitter at @omarieclaire.

Our second game-making incubator, Jeuxly, is coming to a close. Please join us to celebrate the achievements of six first-time devs, play their games, talk to them about their work, and enjoy some tasty snacks and beverages in the company of your friends in the DMG Toronto community.

Saturday, August 18 – 7:00 p.m. @ Bento Miso

RSVP Now

We are extremely proud of the Jeuxly cohort and the work they’ve put into this crash course on conceptualizing, designing, and building a game from the ground up in just six weeks. And for a sneak peak at who we’ll be celebrating on Saturday, see below!

— Cecily & Jennie

Here’s a recap of the session, in case you missed it!

Overview

1. Signal flow (how do I connect things)
2. Synths, samplers, apps, and other ways to make bleeps and bloops
3. Setting up a session
4. Troubleshooting (aka avoiding frustration)
5. Working with audio tracks and MIDI tracks
6. Making Sounds
7. Recording and editing sounds
8. Effects and mixing
9. Games

Signal flow

Computer is connected, both in and out, to the sound card (usually through Firewire or USB). The sound card has an external output to speakers; it can accommodate MIDI devices such as keyboard and other control surfaces with output for communication back to the computer. Finally, sound cards have inputs to receive signals from synths, microphones, guitars, and other instruments.

Key point: What goes out, must go in!

Common connectors

• 1/8” (like your iPod/iPhone headphones)
• 1/4”
• XLR (female and male – often used for microphones)
• RCA (Common to powered speakers)
• MIDI (Don’t transmit sound—only data!)

Synthesizers

Synthesis is the manipulation of signal generated by hardware or software synthesizer. Synths often look like keyboards, but sometimes do not.

• Ribbon controller (such as the Swarmatron, Stylophone, and Monotribe)

• Touchpads (such as Kaossilator)
• Synths played using external controllers (like the Mopho)
• Theremin

• Light beam

Samplers

Allow you to trigger pre-loaded snippets of recordings. You can sample pretty much anything that makes a sound!

Software synths/MIDI

Software synths that live in DAWs [digital audio workstations], for example, Monster.

Apps, DS games, and toy keyboards

• Sound Drop (iOS)
• Bebot (iOS)
• GyroSynth (iOS)
• Korg DS10 (Nintendo DS)
• Elektroplankton (Nintendo DS)
• Speak and Spells, circuit-bent noise makers

Setting up a session

To work with all of these ins and out and get them recorded into your computer, you’ll need a digital audio workstation (DAW). The DAW will allow you to records, playback, sequence, arrange and otherwise process your audio and MIDI signals.

• Audio tracks (microphones, guitars, synths, samplers, etc.)
• Instrument tracks (MIDI-based tracks, usually virtual synth sounds inside the computer are being controlled by a MIDI controller)
• Mono vs. Stereo – 99% of the time, you’ll be using mono tracks as you can mix the left and right spatial relationship of your sounds inside the DAW.

Set your Ins and Outs

• On audio tracks you’ll select both ins and outs.
• On software instrument tracks, you’ll select an output. Instead of an input, you’ll select an insert plug-in.

Tracks vs Channels

It’s sort of confusing! But here’s a way to think about it:

• Tracks = space on a reel-to-reel tap; lanes for your information to be recorded.
• Channels = strip on the mixing board; where you affect the final output of the sound/date you’ve recorded.

Troubleshooting

• Check that everything is turned on and plugged in.
• Check your volume knobs and sliders.
• Check that your track is record armed and that it’s not muted.
• Check that your ins and outs are set properly.
• Follow your signal flow! Slow down and take the time to look how everything is connected and where it’s going—it’s easy to make a small mistake.

Working with Audio vs. Working with MIDI

If you’re using a mix of audio and MIDI tracks:

• Make sure you use a metronome (helps you keep your tempo!)
• It’s a good idea to start with a MIDI track, such as percussion, and layer audio over it so you have a good foundation to work with.

Making Sounds

As all sounds produce waveforms, sounds can be generated or manipulated through some basic concepts

Oscillators (waves)

Different waveforms are combinations of fundamental frequencies and harmonics and oscillators can generate them. These could be used to produce a simple sound or manipulate other audio waveforms. Basic wave forms include:

• Sine
• Square
• Sawtooth
• Triangle

Envelopes (ADSR)

Shape sounds over time with Attack, Decay, Sustain and Release controls.

• Attack (time from zero to peak)
• Decay (time from peak to sustain level)
• Sustain (level during duration of sound)
• Release (time from sustain to zero)

Filters

Control the tone of a sound via the cutoff dial and “fizziness” with resonance.

• Low pass filter
• High pass filter
• Band pass filter
• Notch filter

Amplifier

• Anything to do with volume is controlled here.

LFO (low frequency oscillator)

Control oscillators whose shapes can be used to modulate filters and amplification.

• A signal below 20hz that modulates a sound
• Creates a pulsing effect
• Vibrato, tremolo
• If you’ve heard dub step, you’ve heard an LFO at work (wub, wub, wub)

Recording and editing sounds

Levels/gain staging

When recording audio into your DAW, you want to ensure that you avoid clipping (going into the red) so that you don’t introduce distortion into your track.

This can be done through controlling the volume of the device you’re recording from and balancing with both the hardware gain of your sound card and the DAWs input control.

This is also important to consider with the sounds you have assigned to your MIDI notes, except all of the gain and level controls are in your software as all of the sounds are coming from inside the computer.

Quantization

Even the best performers need a little bit of help when laying down a track, and quantization is the help that keeps your timing together.

Quantization snaps notes played through MIDI to the note grid based on your preference (whole note, quarter note, triplet, etc.). It can be done as you’re recording MIDI data or you can highlight the individual notes or sections in your track to to be quantized selectively.

Recorded audio generally can’t be quantized, but some DAWs, such as Ableton Live, allow you warp the audio to different tempos by automatically stretching and compressing the waveform without changing its pitch.

Transposing Notes

After MIDI data has been recorded, you can manually transpose the notes in your track up and down the keyboard scale, simply by highlighting the notes and dragging them up and down with your mouse or nudging them with the arrow keys on your computer’s keyboard.

This will allow you to change key, chord values and more to match what you want to hear in relation to the rest of your sounds.

Recorded audio can’t be transposed this way, but often its pitch can be modified to produce higher or lower sounds, however the quality of the audio begins to degrade quickly—think of it like stretching gum out too far it begins to tear.

Changing Sounds

MIDI tracks can have their sounds changed with a click of a mouse. Simply find where your DAW keeps its instruments and select one—suddenly the piano part you played using your DAW’s piano sound is now a xylophone.

A DAW’s instruments can be set up in many ways, so a continuously chromatic instrument like a piano may become a percussion instrument where each note is a different part of drum, for example, as opposed to a progress of notes. Experiment and keep track of your favorites.

As mentioned above, audio recordings can’t be changed in this way as their waveforms have been recorded, not the action of the performance.

Moving Sounds

This applies to audio that’s been recorded into your DAW. The waveforms can be chopped up, duplicated and deleted by highlighting the desired portions.

They can also be moved along the length of the track, the individual slices aligned to the timing grid used for your composition (i.e. 4/4, 3/4)

This makes combing MIDI and audio tracks easier to manage and opens up limitless composition possibilities.

Mixing Sounds

To avoid having all of the sounds in your tracks come together in a muddy, confusing mess, you’ll need to apply various effects and monitor your levels to create space for your composition to breathe.

Levels. Refers to the playback level of each track and is monitored by the indicator of each channel (usually measured in decibels) in your DAW.

The level amount can be controlled by adjust the DBs with the controls in you DAW or often can be automated to adjust over time in your track.

While the goal is to always avoid clipping, you may want to layer your sounds by adjusting their levels to allow for a more dynamic sense of space in your composition, as well as effects such as fading in and out.

Reverb. Refers to the real or artificial effect a physical room can have on sound waves. For example, reverb in a DAW can simulate what it would like to have the piano part your played sound like in a concert hall (open, acoustically tuned) vs. an old concrete factory (cavernous with lots of hard surfaces for sound waves to bounce around in).

The effect’s intensity and how much the original sound is mixed in (dry/wet) is all controlled with the parameters in your DAW and can often be automated over time—like have ever fourth bass drum sound like it’s coming from inside a steel drum, for example.

Delay. Refers to the process of buffering or sampling incoming audio information and then delaying the signal before playing it back to create a repeating or decaying echo sound.

There are different types of delay that can be locked to different frequencies, timing divisions and other parameters.

Flange, chorus and slapback echoes are examples of common pre-set delay effects available in most DAWs.

Panning. Refers to controlling the distribution of a sound across the stereo field. In other words: focusing a channels output to be more on the left/right speaker or more evenly distributed.

Most DAWs can automate this effect allowing you to pan a sound across the stereo spectrum at different rates.

Compression. Refers to the narrowing of a channel’s dynamic range by amplifying quiet sounds or reducing the volume of louder sounds.

Compression is used to optimally mix in sources with much dynamic range (such as drum kits) to allow them to be situated in the mix. Effectively, this means losing some nuanced detail in the sound but bring the frequencies that make up the sound more closely. The affect of the compression can be tuned via its loudness threshold and its attack and decay.

Compressors can be side chained in a DAW so that a bass drum can have a “ducking” effect on a channel with a more continuous tone to create a sound that appears to be ebbing and flowing with the bass drum.

How does this relate to games?

Sound in games is often overlooked or thrown together as an afterthought in most indie titles.

This is partially due to lack of familiarity with the concepts covered above, but also because the the full range of possibilities of sound are not fully considered:

• Identity: Setting the tone and theme for characters and levels.
• Feedback: providing additional information for the player about the game world; the effect their actions are having
• Mechanics: providing alternative ways for the player to interact with the game, solve puzzles or problems; allowing audio to drive the game where text, graphics or motion normally would.

An exercise

1. Find an existing, random game clip on Youtube that you aren’t familiar with.
2. Select 30 seconds of footage and play it with the sound off!
3. Spend an hour designing sounds for the actions you see; create some atmospheric textures, etc.

• music and sound effects
• title, game over, and credits screens
• instructions and direction for new players

Assignment for Next Week: Playtest!

Once you have a playable version of your game, find playtesters—people who can try playing your game “cold,” with you looking on. Watching others try to figure out how the game works will be invaluable to you—if there’s a flaw in your design, a confusing UI element, or a bug you haven’t caught yet, they’ll find it!

Every other week, Bento Miso holds Games with Friends, a board-and-video-game social evening. This is a great opportunity to get fresh eyes and fingers on your game! The next GwF is next Tuesday, August 7, at 7 p.m.

Why playtest?

If your background is in creating digital experiences for others, you’re likely familiar with the concepts of usability testing, user research, and user-centered design. Game playtesting encompasses the objectives of all these practices, plus many more. If you’re new to user experience research and design, here’s a primer:

The reason testing is so important in game development is that most video games are highly dynamic experiences. The flow of events changes from moment to moment, and each decision the player makes leads to a multiplicity of outcomes. Most games are also programmed with an element of randomness, so the same player never has quite the same experience twice. Multiplayer games throw even more unpredictability into the mix. As a result, the designer doesn’t directly control the actual gameplay, but instead controls only the underlying system in which the play unfolds. Without actually seeing the game in action, you cannot reliably anticipate how it will work. Mike Ambinder, an experimental psychologist at game developer Valve Software, puts it in scientific terms: “Every game design is a hypothesis, and every instance of play is an experiment.”

How do I playtest?

Put your game in front of someone, and ask them to complete a set of objectives, thinking out loud as they do so. Test early and often, in front of as many new people as possible! Don’t be afraid to ask someone to play something that is unfinished—it’s better to catch problems before spending lots of time polishing elements that may need to be eliminated or changed. Players will provide you insight about the most successful elements of your design, so you can tune and refine the parts that make your game great.

… Grab your coworkers, your family, your friends—anyone who’s willing—sit them down with your game, and watch them as they play it. Don’t forget to play it yourself too! Be harshly critical. Do you enjoy playing it? When it’s over, do you feel like playing it again? Is it frustrating? Is it boring? Is it too hard to figure out what to do? … be prepared to put your game under the microscope again and again, and to adapt the design to make it more enjoyable.

Take notes as players work through your game, and weigh their feedback against the following considerations:

Usability. Do players understand the interface? Are they successful in carrying out their intended tasks?

Ergonomics and Mechanics. Does your control mapping make sense? Can players move and fire at the same time without crippling their wrists?

Aesthetics. Do players “get” your style? Does your visual to aural design, title, storytelling elements and control scheme all work together to create a cohesive experience?

Agility. Are players frustrated or challenged appropriately? Is it too fast-paced or require an inordinate amount of button mashing?

Balance. Do the values you’ve assigned to different elements contribute to fair and equitable gameplay? Are enemies — or player characters — over- or under-powered?

Puzzles. How long does it take players to solve the cognitive challenges? Do they persevere or give up?

Motivation. Are the rewards for playing sufficient to entice players to keep trying? Do they take an active interest in the game? If so, how long is it sustained? At what point do people lose interest, and why? Would they be better motivated by different rewards or game structures?

Affect. What do your playtesters walk away feeling? What emotions come up, and how do they map to your desired effect?

Excerpts from Playful Design: Creating Game Experiences in Everyday Interfaces

More resources

• The Big List of Beta Testing
• Playful Design: Creating Game Experiences in Everyday Interfaces by John Ferrara
• Finding Out What They Think: A Rough Primer To User Research
  (Part 2)
• How to Playtest

• Gillian’s “stiff and morbid” art style for her Pong-like relationship shooter
• Yuliya’s polished pixel art and animation for her jaunty squirrel platformer
• Julia’s highly visual memory game, inspired by Une semaine de bonté, which she’s building in GameSalad
• Christine’s bullet-hell inspired maze-based Snake-like
• Marie’s idea-growing metaphorical narrative

(Miriam was away in the Yukon, working on her office-motif platformer.)

There are just three work sessions remaining before the final showcase on August 18!

• Saturday, August 4, following Christine Love’s New Game Makers workshop – open work session for participants, mentors, and Miso members and friends
• Wednesday, August 8 – work session for Jeuxly participants and mentors
• Friday, August 10 – work session for Jeuxly participants and mentors

Depending on how things go, we might try to squeeze one more mentor session in before the big event.

Thanks again to our amazing mentors and volunteers—we couldn’t do this without you! Your support, patience, and knowledge mean the world to us and the Jeuxly dames.

Hello Dames,

Was great to see your Stencyl mods on Wednesday night. I hope you’re excited to finally get started on your main projects for Jeuxly!

Assignment

For next week, here’s what we’d like you to do:

1. Investigate some different game engines

…for example: GameMaker, Adventure Game Studio, Ren’py, Unity—and make a firm decision about which one you’d like to use for your final project. Let us know what you choose, ideally by Sunday, and we can talk about funding options.

2. Start your game!

Your goal for next Wednesday should be to get at least one interaction working. It can be as simple as having a character that moves, or a button to click on.

On the DMG Web site, you can dig into our Getting Started with Game-making guide for some resources and inspiration.

If you have any questions or trouble at all, please do not hesitate to contact Cecily. Have fun!

Upcoming Work Sessions

Mentors will be available at the following open work sessions at Miso:

1. Wednesday, July 25 following presentation (8 – 10 p.m.)
2. Saturday, July 28 following workshop (5 – 9 p.m.)

Jeuxly.com

Jeuxly.com is a public repository of all things Jeuxly, including session summaries from Cecily and Jennie, photos and blog posts from you dames! It’s a chance for you to share your progress with and get feedback from the wider DMG and indie game dev community.

If you are interested, check your email for your log in information

You are free to post anything you’d like. This week, you might want to post a sketch, or a quick note about your game ideas or thought process behind choosing an engine. You can also update your profile with a picture and short bio.

For assistance with the Jeuxly site, please contact Jennie.

See you at Bento Miso on Saturday at 1 p.m. for Carly Beath’s audio production workshop!

—Cecily & Jennie

Session #2 Recap

• Jennie’s notes from her presentation on planning and managing your game project
• Cecily’s slides from Wednesday on coding concepts

New Game Makers workshop

You’ll learn the foundations of making electronic music using a wide range of affordable tools – some you may even already own!

Jonathan Guberman, creator of the Pianocade will also be in attendance, with his amazing not-yet-released chiptune synth/MIDI controller for you to play with.

Since a lot of you seemed to be running into problems with collisions in Stencyl, I thought I’d write up this quick guide.

Collisions (a reaction that happens when two objects come into contact with each other – like a ball bouncing off a surface or a character being blocked by a wall or hit with a projectile) can take a bunch of different forms.

• If you have a top-down view, you want your character to walk over floor tiles but be blocked by wall tiles. So, your character needs to collide with the wall tiles and not the floor tiles.
• If the enemy shoots fireballs, you might want the fireballs to pass through other enemies without affecting them but collide with your player. So, the fireball needs to collide with enemy actors but not your player actor.
• You might want your character to react to touching certain items while still being able to pass “through” them and not be blocked by them or bounce off them (like Mario grabbing a coin or pac-man eating dots). So you want collision detection (awareness of when two things are in contact) but not necessarily a collision effect where movement is blocked.

There are four areas that affect which objects can “collide” with which other objects.

1. Collision groups

In the left-hand menu in Stencyl, under Game Settings, there’s an area called Collision Groups. This is where you define categories for your objects and decide which of these groups of things should collide with each other.

There are a bunch of pre-set categories (Player, NPCs, Collectibles, Tiles, etc). You can decide here which things collide with which other things. Do you want to have the game enemies be able to move through each other while still colliding with the player? Do you want collectibles on the ground that the player can pick up but enemies can’t? Do you want ghosts that float through walls even when everyone else is blocked by them? This is where you set that up, by defining your categories and defining how they interact with each other. Later, you can group your specific actors into these categories.

2. Actor properties

When you open up an actor, the far right tab called “Properties” is where you define which collision group your actor is a part of. At the bottom of the screen there’s a label called “Choose Group” and a drop-down menu. These are collision groups. Pick the most appropriate one for your actor.

3. Actor collisions

Where you might trip up is that in this screen, you’re setting collisions not for your actor as a whole, but for each separate animation for that actor.

So, if you have a left walking animation, a right-walking animation, a jumping animation, etc. Stencyl will let you have different collision properties for each of those animated states. While this is useful in some situations (like if your actor is usually solid but has a temporary “ghost” state where she can walk through walls), it can be really confusing if you don’t realize that’s what’s happening. Click on each animation in the left hand panel to see the collision settings for that animation.

Unless you have a very compelling reason not to, make sure that the collision group for each animation is set to “Actor (Same as Default)”. All this means is that you’re sticking with the collision group that you defined in the actor properties in section 2.

You’ll also see a picture of your actor with a yellow box around it. This yellow box defines where the physical “border” of your actor is. If there seems to be an invisible force field around your actor, it’s because the box is too big. Enter the position and dimensions of the box using those four fields to the right of the drawing (X, Y, Width, Height). Make sure the yellow box hugs your drawing, and do this for each of your animations.

There’s also a checkbox called “Is a sensor.” If this is checked, it means that the object can detect collisions while appearing not to react to them. There are lots of times when this is useful, like if you want items on the ground that the actor can either walk over or pick up. Again, make sure you set it to the value you want for each animation.

4. Tile collisions

Each tile in your tileset can have individual collision bounds. Make sure it matches the shape and function of your tile (i.e. if you have a top-down view, floor tiles will be “No Collisions” so that actors can walk over them, while walls might be square).

*If you’re having collision problems, check the following: *

1. in the overall game collision group settings (1), do the groups and their relationships match the way I want the collisions to work?
2. in my actor properties (2), has my actor been assigned to the correct group?
3. in the actor collision properties (3), is the group set to “Actor (Same as Default)” for each of my animations? If it’s not, do I have a really good reason why this is the case?
4. for each of my actor animations (4), does the yellow bounding box hug my drawing? Is the sensor checkbox set correctly?
5. for the tile collisions (4), does the collision shape match the shape of my tile?

I hope this helps at least one of you! Best of luck with starting your games.

Just a reminder. That’s what you’re doing here.

Jeuxly is a lot like a game jam – but you guys have the not-insignificant added challenge of never having made a game before. In a jam (or any project with a stingy timeline), pre-production planning and constant vigilance toward your goal will determine your success.

Because your timeline is so compressed, the key is finishing – however you define that for your project.
So as you start to move into production this week, be sure to manage your own expectations – there will be bugs. It won’t be perfect. But you will complete it.

Pre-production

Now through Sunday, July 22

This is what you’re going to do for the next few days to prepare yourself to start actually working on your game. Even if you’ve already started digging in, it’s helpful to take a step back and do these things.

Sketch + Scope

Start by drawing. I use a Moleskine storyboard notebook for Web projects and I think it would work really well for a game. How you sketch is up to you! You can draw in a notebook or:

• Draw on a white board (flowchart/storyboard hybrid)
• Write out the flow and major scenes (text – I recommend also interspersing illustrations)
• Create a flowchart diagram (Visio, OmniGraffle, Balsamiq)

Different ways to sketch out your game.

The purpose of sketching is to make your ideas more concrete. Before you can figure out what you need to do, precisely, you need to wrap your mind around the “big picture” of your game. It also helps you figure out what’s most important to you, so that when you inevitably need to cut something out, you know what you can sacrifice without compromising your vision.

Try to cover the whole game in your sketches – beginning, middle, and end. And challenge yourself to represent gameplay – not just individual elements.

In a group project, storyboarding on a white board is really useful. It gets everyone thinking about the scope of the game. Euphrates is a “screen at a time” type of game with looping events, but this can work for most styles. Even if your text-based game is non-spatial (that is, the primary way the player moves through the game is through time or a story rather than rooms), this exercise can help you map out your content requirements. Christine Love will be talking about this in her workshop on storytelling in games on August 4.

Also be sure to draw and note everything the player interacts with. Background/atmospheric elements (anything non-essential to gameplay) can be left to the end. Your art can be “layered” on raw elements, so rough representations and placeholder images and text can be used while you are working on your mechanics.

Define your game

What kind of game is it? Can you name its genre (or invent/combine genres)? Try to describe your game in one sentence. For example:

Euphrates is a four-player cooperative, turn-based, interactive narrative.

Understanding the primary mechanics and conceits or your game up front gives you a language and framework to build upon, sets up the parameters for constructing your game world, and helps you figure out what kinds of assets you’ll need. This is not the story of your game, but an objective description (we can add in the fun bits later – you know, set in SPACE!)

• Is it a puzzle game? You might only require simplistic art, so you might want to spend time refining your colour palette and shapes.
• Adventure game? It might be heavy on the art and writing. (Or not!)
• RPG? You’ll be using spreadsheets.
• Platformer? Your theme/art will be important to set your game apart. Are you going to build in a unique mechanic or theme?

Make a big list of production tasks

It’s critical that you carefully define what you need. Dump it all out on paper – you won’t get everything, and a lot of what you come up with might turn out to be unnecessary.

• Assets
  • Art
  • Music/sound
  • Player interface elements (menus, instructions, etc.)
  • Text (story, dialogs, alerts)
• Functionality
  Understand your dream scope so you can pare down to the core game elements.
  • Figure out what you need to do – do you need/want to write any new code? Do you need to integrate elements from sample games? What don’t you know/understand?

Try not to sink too much time into creating assets before you’ve laid a solid foundation – this exercise is just to become aware of what you’re going to need to so you can block off your time accordingly.

Here’s our “big list” for Euphrates and some supporting notes for creating assets:

Our asset list, including everything we could think of for art, music, text.

Research

We figured out late that we hadn’t given our writer a good conceptual framework. A few lines about how your world works really helps! (Rachel touched on this – this is how you figure out what fits and makes sense in your game world.) Don’t spend a lot of time on this – a few sentences is sufficient.

We also had a small list of references – this is the “broad research” Rachel talked about. It helped us set the tone when we dove into producing the assets we’d listed. Most of our theme and aesthetic inspirations were movies, but we also referenced games like The Yawgh and Nidhogg.

Jeuxly is like a standardized test

Remember the two tips your teacher gave you when you sat down with those awful bubble-filled forms with your No. 2 pencil?

1. Start with the easy stuff. Checking a bunch of stuff off your list is satisfying, and leaves you with lots of time to focus on the harder things!
2. Stuck? MOVE ON! With two weekly work sessions, and plenty of opportunities to get feedback and help from your mentors, there’s no reason to work yourself into frustration over, say, collision detection. The solution may be just around the corner, but it likely isn’t. So move on to something you can do and reach out for help.

The whole point of Jeuxly is to provide a focused group environment for as much continuous support, feedback, and collaboration as you need. You don’t have to work in isolation if you don’t want to – everyone wants to help you finish your game.

Production

Sunday on out!

I’m not going to give you any specific details on how to manage your project over the next four weeks. You probably have tools and processes you use in your work – exploit the systems that work for you!

However, I will give you a way to frame the work you are doing.

Things that will keep you focused:

Choose the tool that feels best

• Focus on making a game, not mastering a language or tool!
• Don’t switch tools midstream unless you REALLY must.
• Don’t spend too much time pondering your game engine. Select one that is suited for your genre – you’ll get the help you need.

Remind yourself of your goal every day

• Don’t get hung up on details (it’s easy to sink a lot of time into the “fun stuff” but refinement needs to come at the end.
• Allow yourself time to work on the parts you find most interesting, but block off your time so other aspects don’t suffer. You’ll be happier with the result, I promise!
• Write down your goal and stick it on your monitor or fridge. Set up a recurring reminder in your calendar. This is your mantra. You’re allowed to stray, but you should know that’s what’s happening!

Imma finish this co-op tandem bicycle-racing civic-engagement game in 4 weeks.

Define success for yourself

Picture the game you want to finish. That’s what you’re doing. Don’t worry about anyone else – this is YOUR game. Your cohort – and the DMG community – is here to support you and help you realize your goal, whatever that might be.

This week, we’re starting to work on modifying existing games in GameSalad and Stencyl, and next week’s assignment will have everyone starting work on their game. We are not certain what tools participants will choose to use, but there will likely be a mix of GameMaker, Stencyl, GameSalad, Unity, and Adventure Game Studio.

Call for Mentors

Starting with work session #4 (Wednesday, July 25), we need mentors to be available for the work sessions to assist our seven game-makers with their tool of choice; to provide game/level design guidance; advice on creating art, music, and content assets; or simply be on hand with encouraging words when they encounter bugs and other bumps on the road.

Wednesdays

July 25, August 1, and August 8 (7 – 9 p.m.)

Saturdays

July 28, August 4, and August 11 (5 – 9 p.m.)

If you are available for any of these dates, please let us know!

Thanks to our volunteers so far!

• Adam Clare
• Katie Foster
• Alex Bethke
• Damian Sommer
• Cale Bradbury
• Tory Morrissey
• Maggie McLean
• Corinne Natasha
• David Gallant
• Eric Emery