About Julian Ceipek

Entries

 
Ludum Dare 26
 
Ludum Dare 23

Julian Ceipek's Trophies

Julian Ceipek's Archive

Auraline: Design Overview

Posted by
Friday, May 3rd, 2013 10:06 pm

AuralineLogo

The theme for LD 26 was “minimalism,” which other entrants interpreted in a variety of ways, ranging from minimalist art and lifestyles to reductions in size or complexity.

With Auraline, our base concept was to explore minimalism in terms of dimensions. Edwin A. Abbot’s Flatland served as our primary inspiration:

“Imagine a vast sheet of paper on which straight Lines, Triangles, Squares, Pentagons, Hexagons, and other figures, instead of remaining fixed in their places, move freely about, on or in the surface, but without the power of rising above or sinking below it, very much like shadows—only hard with luminous edges”

 

Virtual Reality (Oculus Rift)

BestWithRift

We thought the experience would be particularly compelling through virtual reality; we wanted players to feel as if they had entered a different world. We also enjoyed the irony of a virtual reality headset, the pinnacle of 3d visualization, being used to enhance player’s experience of an essentially 2d environment. However, we didn’t want to limit our audience to owners of virtual reality headsets.

Core Mechanics

Arrows

Viewing an environment from a radically different perspective is complicated enough without a complex mechanic to go along with it. We decided to limit what the player can do to moving around the space of the world. The arrow-key based control scheme in Auraline is the simplest one we could think of to facilitate looking around and moving while remaining compatible with the way the Oculus Rift virtual reality headset allows players to look around the world naturally, by turning their heads. The key idea here is the concept of natural mappings discussed by designers like Norman and Cooper.

Music

HeadphonesRequired

One of the early discussions we had about the direction of the game revolved around the notion of dolphin vocalizations, which represent different objects and activities based on the shape of sounds. We planned to teach the player about the nature of different sounds using that idea as an inspiration for gameplay.

Neither Charles nor I had ever created an audio-based game before, but we both thought that Ludum Dare would be a low-risk way to experiment with the genre. Although I have little experience with music, Charles does, and he owns lots of string instruments and recording equipment. We also had access to the “Jam Room” at Olin College of Engineering, which has lots of keyboards and drum sets.

In line with the theme of minimalism, we wanted the feeling of the music to be emotionally pure and to accompany and guide the player through the world of Auraline.

Each entity in Auraline has a unique sound style and personality associated with it, and we used Unity’s 3D sound features to impart directionality, allowing the player to discover which things to avoid or follow.

Narration

The voice overs in Auraline were heavily inspired by two of my favorite games: Myst and Bastion. Auraline starts and ends with voiceovers directed at the player, much like the narration by Atrus in Myst. I made these with the intent of building a bond between the narrator and the player and to encourage the idea that you and he have a mutual secret. At the same time, I really respect the idea of player agency and hate when games take control away from the player for the sake of narrative. To that end, the narration in Auraline has reactive elements. Some voiceovers can be interrupted or occur only in response to what the player does or experiences.

 

Level Design

WARNING: With regard to spoilers, this is the point of no return. If you haven’t played Auraline yet, reading the next section will ruin the experience for you. Play it here. It only takes about ten minutes.

Opening

 

The level design in Auraline was heavily inspired by talks on game design by Jonathan Blow and Edmund McMillen.

Opening:

The opening of Auraline is all about setting the mood and introducing the controls. The starting voiceover reveals the mystery of Auraline‘s world. Then a set of glowing arrow keys appears on the screen. The only way to proceed from there is to press one of the directional buttons, which ensures that the player understands which keys to use.

Level 0-2:

These levels are all about understanding the objective of the game: to get towards the glowing exit. I derived this concept from a psychological game design technique discussed here: “Players are going to want to go towards the light, as opposed to the dark. That’s hardwired into us as human beings, because we don’t want to get eaten by the bad thing in the dark, and so we’re going to go where it’s light out and we can see.” At the same time, these levels teach the player about the nature of space in Auraline and how to navigate it using sound.

The first level is about heading towards the goal, the second is about turning to face it, and the third level is about following music around corners if the objective is not visible when simply turning.

Level 3-7:

These levels are about continuing to explore the nature of space, music, and a new type of entity first seen in level 3. Just like the goal, the entity has a unique sound associated with it. However, this sound is dark and ominous; players need to avoid it in order to proceed. Level 4 reintroduces the concept of corners in the presence of a moving malignant being behind the player and level 5 reinforces that notion with a more complex level layout. After seeing lots levels with enemies, I wanted to give players a break from the tension of avoiding things by making a level exclusively about following sounds in a complex environment. Level 6 does this really well. By the time players complete it, they should have a much greater familiarity with navigating based mostly on sound cues. The level also defies the maze solving technique in which one simply follows a wall. Level 7 is the culmination of the malignant presence explored in the previous levels. It introduces the idea that there can be more than one enemy in a level. In order to keep the focus on the tension of the multiple enemies, the layout for level 7 is otherwise identical to level 6 except for the player’s initial orientation.

The enemies that appear in level 7 never appear again in Auraline, partly due to time constraints but also because of human psychology. As anyone who consumes horror media knows, the more one learns about terrifying things, the less terrifying they become.

Level 8:

Level 8 is a break from the intensity of the last level that builds on the psychological tension of the last encounter. The level mirrors the very first level but is slightly larger. I wanted players to wonder “is this place safe?”

Level 9:

This level introduces a new malignant entity that has the potential to be much more intimidating than the previous enemies the player has encountered. Unfortunately, we did not have time to continue exploring it in more complex situations within the 72 hours of LD 26.

Lessons from Playtesting

One of the most important parts of making Auraline was extensive playtesting, which I neglected during my last LD. The following are some of the key lessons we learned from playtesting.

Level Completion

The initial version of Auraline didn’t have a completion sound during level transitions. Without this subtle element, most playtesters did not realize that a level was over once they entered the glowing goal.

Death

Players were really confused about what happened when they touched malignant entities. Adding a closing/opening blind animation made respawns much more obvious. After that, multiple players reported being “eaten” by these entities.

Trying to head for glowing walls

Initial playtesters liked running into walls more than heading toward the goal. Reducing the glow effect on the walls mitigated this problem, but I still think we could have done more to create a starker visual contrast between environment elements with variable depths.

 

A Glimpse of Things To Come…

Posted by
Sunday, April 28th, 2013 10:47 pm

It’s been a while, but don’t worry; our entry isn’t dead. We’ve been doing a lot of audio recording and even more playtesting.

Here’s an early web build (with Rift support disabled):

Play Auraline

 

MusicStudio

RecordingVoices

 

A cool new logo:

AuralineIcon_512

 

 

Visual Style Update

Posted by
Saturday, April 27th, 2013 4:06 pm

Imagine a vast sheet of paper on which straight Lines, Triangles, Squares, Pentagons, Hexagons, and other figures, instead of remaining fixed in their places, move freely about, on or in the surface, but without the power of rising above or sinking below it, very much like shadows—only hard with luminous edges—and you will then have a pretty correct notion of my country and countrymen. Alas, a few years ago, I should have said “my universe:” but now my mind has been opened to higher views of things. In such a country, you will perceive at once that it is impossible that there should be anything of what you call a “solid” kind; but I dare say you will suppose that we could at least distinguish by sight the Triangles, Squares, and other figures, moving about as I have described them. On the contrary, we could see nothing of the kind, not at least so as to distinguish one figure from another. Nothing was visible, nor could be visible, to us, except Straight Lines; and the necessity of this I will speedily demonstrate.
― Edwin A. Abbott, Flatland: A Romance of Many Dimensions

 

RiftGlow

 

 

 

 

SingleCamera

After a good night’s rest and a day of coding, the movement and visualization code is close to complete.

The art style is minimalistic, yet provides enough of a sense of depth to encourage exploration.

Next up: sounds and music!

(but those will probably come tomorrow — first, I shall take to the stage as Leonato in Much Ado About Nothing)

 

Julian

 

First Rendering Test

Posted by
Friday, April 26th, 2013 9:21 pm

AudioGameScreenshot

 

Our idea is based on the concept of Flatland: you can only see a single line. Looking at it through the rift is very disconcerting; your perception of the world is significantly altered.

Unfortunately, modifying the Rift Unity SDK to display with such a limited vertical FOV isn’t easily supported, so we drew black boxes to cover up the rest of the world.

Code is here: https://github.com/cg123/LudumDare26

Julian

We’re In!

Posted by
Friday, April 26th, 2013 7:50 pm

@cgoddard and I are in, for his first and my third LD, making a minimal sound-based game with Oculus Rift support.

Julian

Dot Timelapse

Posted by
Tuesday, April 24th, 2012 5:09 pm

My Timelapse is finally ready (compiled from over 20GB of images taken every second):

Also on Vimeo

Play and rate dot

dot Postmortem

Posted by
Monday, April 23rd, 2012 7:13 pm

dot is a top-down 2d space game in which you control a tiny planet with a volcano during his quest to find his parents.

The style was inspired by simply rendered storybooks and the gameplay was influenced by Osmos and the early Asteroids games.

Help dot find his parents.

Play and rate dot.

What worked well:

Working Solo

This is the first game jam I’ve done where I did everything solo. This worked really well for me because it allowed me to settle on an idea very early on – during the other two jams I participated in, we spent multiple hours agonizing over interpretations of the theme and possible mechanics. As I have realized, deciding these things as soon as possible in the process is paramount to creating a finished entry. In prior jams, I had never worked with the people with whom I participated before, and that was extremely limiting because it meant that we didn’t know each other’s strengths and weaknesses, nor our collective familiarity with the tools we were using. In both cases, I started doing artwork and ended up as one of the lead programmers. Since I knew I would have to do everything this time around, I was able to scope my work really well.

 

Refining Assets & Keeping the Art Simple

Unlike in my previous jams, I started out with art assets I made in Inkscape in just a few minutes and focused my initial effort on creating a functional movement system. In the past, I focused too much effort on making pretty 3d models and rendering them out to sprite sheets. You can’t really make a good game if you spend all of your time on pretty pictures. When I finally did start to work on more polished graphics, I avoided 3d modeling and made black and white 2d line drawings in Photoshop. If I participate in a group jam in the future as an artist, I’ll make sure that the programmers are sufficiently familiar with the game frameworks we are using that I don’t need to take an active role in coding in order to get a playable game.

 

Working in a Publicly Accessible Area

I worked on dot in a lounge at my school, which made it really easy to convince passers-by to playtest the game incrementally as I was developing it. I got a significant amount of really helpful feedback from their comments and from watching them play my game, which helped me refine the control system a great deal. For example, the indicator that tells dot where his goal is used to consist of faded black circles on the corners of the screen, and the people who tried it out attempted to avoid them; they thought that they were being chased by dangerous obstacles. Doing this also gave me validation for the game when I was starting to wonder whether it counted as “fun” – one player desperately retried my nigh-impossible asset test level dozens of times despite getting frustrated and kept coming back to check on my progress.

Perhaps most importantly, though, it made sure that I actually got the game to work properly – I was in danger of wallowing in minor details near the end of the first day, and one of my repeat visitors told me to stop messing around and focus on the core gameplay.

 

Using Unity

I have mixed feelings about using Unity to develop games because of its lack of true Linux support and its nature as a closed source development environment with expensive add-on licenses for features that could be accomplished very easily (and for free) in other systems. However, Unity is incredibly easy to use, it has an excellent component system, and I was able to deploy to the web and Mac OS X/Windows with the click of a button. During Ludum Dare 22, we spent about 2 hours generating a working Windows .exe and ran out of the time we needed to generate more than long-winded source compilation instructions for other platforms.

 

Using github with gh-pages

Being able to generate new test builds every few hours and post them to the web with only a few lines of html in Vim was possibly the greatest boon ever. We didn’t use any version control during my first game jam, and that gave us a lot of headaches that we could have easily avoided.

 

Updating my Journal & Making a Livestream

I didn’t do this during any of my prior jams because I thought it would be wasting valuable time, but I think it really paid off this time around by keeping me on track in the game development process. My livestream solution was incredibly hackish, though, and I would like to know how the other mac developers handled this. Just before the competition, I spent four hours writing a convoluted sequence of shell-scripts to get an old version of VLC to stream a sequence of images to twitch.tv, which ended up taking up most of my CPU power. I scrapped that and moved to a piece of javascript that one of my friends wrote, which allowed me to display images once every 30 seconds or so as they were updated on Dropbox. Dropbox banned me from public links for 3 days because of excessive traffic, and my friend made a strange php upload script for me that allowed me to update much more frequently, but still with a really ugly system that involved using my ability to host things on my school’s servers.

 

Getting Sleep

I barely slept during my past jams, and I think that might have been part of the reason that I never finished something to the degree that I did this time around. Sleep is important.

I still feel somewhat like a zombie now that the competition is over, but at least I was able to think clearly while I was doing things. If I were to change the way I did things, though, I think I would have gone to sleep earlier and gotten up earlier as well – 6:00AM and 5:00Am seem a bit late to be going to sleep while needing to be productive for multiple days in a row.

 

What didn’t:

Level Design

I didn’t leave myself enough time for level design and ended up making only three levels, of which the third is very poorly designed because it can cause you to win accidentally.

 

Music/SFX

While I did end up creating music for dot, I have absolutely no musical background and ended up repeating a sequence of four notes I haphazardly stumbled upon in GarageBand after humming something that I thought might sound interesting. I also didn’t have time to do any sound effects aside from some voiceover that I recorded in Audacity using my laptop’s built-in mic. I really need to find a better mic next time. However, I am still rather proud of the fact that no one who played the game complained about my unpolished audio and very few people realized that the voice was me. Apparently I’m just a really good voice actor?

Level Transitions

This is the largest contributing factor to wasted time during the entire competition. Making level fades properly in Unity is really challenging because of the component-based system forcing complex object interactions. When a fade starts, I needed the character to stop moving and the next level to start loading once the fade was complete. Ideally, the next level would start loading while a fade happens on top of a still image of the current screen. I’m pretty sure that the indie version of Unity doesn’t support that behavior, and I don’t really want to get attached Unity pro if I can only get a demo version. If I ever end up making a game good enough to fund my purchasing a Unity Pro license, maybe I’ll look into doing this better.

Anyway, I am still pretty unhappy with the fades between levels and worked on them instead of making more (and better) levels, which was pretty silly of me.

 

End Game/Story

The end of the game is pretty unrefined/confusing, and I wanted to tell a much longer story through animated cutscenes between the levels. If there is enough interest in seeing those things (give me some comments and feedback!), I’ll look into expanding dot for Kongregate during the summer.

 

Overall Impression:

I’m really happy that I actually made a (sort of) complete game this weekend, and I’m satisfied with the core game mechanic. I feel like I learned a lot about Unity and game design in general during the past few days, and I’m definitely going to try to compete in LD24.

Going off on a bit of a tangent, I thought it was really surprising that some people who play dot get lost in space for up to 15 minutes while others play through the entire game in under 2. Hmm…

 

Congratulations if you read all of that. Remember, you can play and rate dot here.

Less than an hour left!

Posted by
Sunday, April 22nd, 2012 5:16 pm

Sorry for not posting any new builds. I added some simple music (I am not a good composer), some nice voiceover, and made 3 levels. I don’t know whether I’ll get a chance to add more or fully integrate my storyline. In any case, here’s a screenshot – there is now an arrow pointing in the direction you need to move.

 

 

Good luck, everyone!

Final screencast: http://students.olin.edu/2012/czwiebel/webcam/

End States!

Posted by
Sunday, April 22nd, 2012 1:15 am

Isn’t it great when you can actually win or lose? I think so at least, especially because I didn’t have the chance to add that functionality into any of my previous Game Jam games.

Follow the corner indicators to the goal!

You can actually lose? Incredible!

 

I feel really exhausted after all of the stuff I did today, and I need to get some sleep.

 

Stuff to do for tomorrow:

– Make the volcano indicate your fuel level

– Make the transitions work properly between levels

– Art

– Story

– More (real) levels (the current one is just a stand-in to see if stuff works)

 

If you happen to be up while I’m in bed, you can always try out the latest build:

http://jceipek.github.com/LudumDare23/

What’s in a name?

Posted by
Saturday, April 21st, 2012 8:49 pm

I got tired of coding non-stop and decided to work on the main menu and graphics. I’m pretty pleased with how things look at the moment – I’m trying to go for a storybook style. Oh – and I’ve decided on a name for my game:

dot

dot

I really need to start working on gameplay again – I’m afraid that if I continue on art, I’ll have a really pretty, non-functioning game. However, I’m starting to get rather tired again, so I don’t know how that will turn out.

One thing is pretty much set, though – I’m going to get much further than I did on a team for LD 22.

Try out the latest build: http://jceipek.github.com/LudumDare23/

Livestream: www.twitch.tv/jceipek

Screencast: http://students.olin.edu/2012/czwiebel/webcam/

It was nice knowing you…

Posted by
Saturday, April 21st, 2012 2:15 pm

Goodbye…

As I hinted in my last post, the planet now has the ability to die a painful death if it builds up too much pressure while getting ready for a powerful thrust. Nothing happens yet, after the planet is gone; the game just keeps on playing, waiting for you to refresh it. I’ll probably tackle that issue soon.

Before that, though, it is time for me to take a break to get something to eat and replenish my stash of bananas.

In the meantime, you can try out the latest build here: http://jceipek.github.com/LudumDare23/

My screencast and livestream probably won’t be very exciting in the meantime, but maybe you’ll see something interesting happen in my absence. Who knows?

Livestream: www.twitch.tv/jceipek

Screencast: http://students.olin.edu/2012/czwiebel/webcam/

A Swiftly Shaking Planet

Posted by
Saturday, April 21st, 2012 1:26 pm

I just made the planet you control shake as you charge it with the thruster. This way, the player won’t be incredibly confused and frustrated if the planet explodes. This feature also provides feedback about how far the planet will move during a thrust. The animation seems to be a bit large. What do you think? Should I keep the animation tighter to the center of the planet’s movement? (Try it here: jceipek.github.com/LudumDare23)

Video on Vimeo

The screencast appears to be working now thanks to Colin (go to http://students.olin.edu/2012/czwiebel/webcam/), so you can watch me work in close to realtime (update cycle is once a second) at an incredible resolution (my actual screen size). Unfortunately, the screencapture command in Mac OS X Lion seems to only capture the main monitor, so I’ll try to keep the interesting stuff on that one and look at documentation on my other monitor.

Screencast!

Try out the latest build: jceipek.github.com/LudumDare23

Watch the screencast: http://students.olin.edu/2012/czwiebel/webcam/

Watch the livestream: www.twitch.tv/jceipek

Screencast back up!

Posted by
Saturday, April 21st, 2012 11:52 am

If you read my post from earlier today, you know that Dropbox blocked me from sharing files publicly via web links because I was getting too much traffic. Colin just helped me set up a new shell script to broadcast my screencast. You can now see it again at http://students.olin.edu/2012/czwiebel/webcam/ (It’s slightly broken right now while images are loading, but it should be fixed soon. If it asks you for a password, just click cancel).

 

Screencast!

And then I was all alone…

Posted by
Saturday, April 21st, 2012 11:12 am

I got the camera to follow the player. It was much simpler than I thought – in the game I’m developing outside of Ludum Dare, I used Unity’s example camera follow script, and it has a lot of superfluous features.

 

Anyway, here are some new screenshots, and as always, you can try out the newest build at http://jceipek.github.com/LudumDare23

I’m floating away!

Now I’m all alone…

 

The screencast will be back up soon, and you can still see the livestream at http://www.twitch.tv/jceipek

And thus they draw you in…

Posted by
Saturday, April 21st, 2012 10:13 am

I just implemented black holes in the game by generalizing the BigPlanetController code I wrote to work for all objects with gravity wells that affect the player (in fact, I’m pretty sure that I could make repulsor objects using the same script… food for thought). This is the first time that I actually managed to get 360 degree rotation to look smooth – in Blender, it is apparently possible to change the extrapolation mode for IPO curves.

 

 

The player now also has a limiting maximum charge rate – eventually, I want to make the player explode if the volcano is charged too much, but I’ll leave that for later.

 

As always, you can try out the latest build here: http://jceipek.github.com/LudumDare23/

 

Next step:

Get the camera to track the player.

 

Screencast is still not back up; sorry everyone. However, you can still watch my Livestream here: http://www.twitch.tv/jceipek

Back to Work!

Posted by
Saturday, April 21st, 2012 8:36 am

After five hours of sleep, a bowl of cereal, and a glass of grape juice, I am back!

…Oops

Apparently my screencast was getting too much network traffic because I just got this notification from Dropbox. I’m trying to see if someone can help me host it somewhere else, but in the meantime, you can still watch my livestream here: www.twitch.tv/jceipek

 

Also, I’ll be posting my screencast to Vimeo after the compo is over, so you’ll be able to see the parts that I wasn’t able to stream live.

 

Goals for today:

– Improve gameplay

– Nice art

 

That’s enough of a break. Back to work!

 

[cache: storing page]