Not Alone: A Concept About Loneliness and Motivation

2 weeks ago I've made a weird dream where I felt incredibly lonely. I can't really put words to describe that feeling, and that's exactly what I found interesting in this dream. I almost immediately wondered how I would do if I had to transpose this feeling in a game. And that's what made me work on the Not Alone prototype.

Play the game here : http://gamejolt.com/games/other/not-alone/14150/

Loneliness?

So the objective was to make the player feeling lonely. Let's face it : I think I failed but the whole creating process was still interesting.

When alone, world is not so bright...

Game Design

Lonely doesn't mean Alone. So I wanted the player to be among lots of other characters, but not part of their group. I wanted that all other individuals in the level go away from him/her. (It looks like player is pushing other characters with physics but actually this is a small AI playing here.)

But if I wanted to turn that into a game, I needed an objective. So player has to make some friends (and maybe find love!) to "feel better."
This kind of stuff needs to be short in order to be completed by most people who will play it. 5 one-minute (max) level should be short enough.
So basically this is it : player has to make as many friends as possible through 5 levels of  1 minute.

Art

First thing I decided was not to focus on graphics : It's not that I don't care about that part of a game . The reason is that I'm a terrible graphical artist. So instead on focusing on creating a nice looking "style", I have chosen to use simple visual assets.
Still they are key : I use them for feedback (color of characters) and to show progression (the level itself, which is some kind of visual representation of main character mood).

That's much better :-)

Audio

Initially, I didn't planned any sound around the game as it was just a prototype. Still I though that having a weird music would help. I found a (almost) random fractal music generator and made my score with that. Current music is calm but disturbing and perfectly fits the game.
Then after play-testing the game a bit around me,  it was clear that I needed a feedback to tell the player he was approaching a potential friend. And that's the purpose of the heartbeat, nothing new here but efficient and that fits this game pretty well again.

Motivation

This prototype is also about motivation. Not player motivation, but mine :-)
It's been almost a year since I started working on my "main" game, and I was working on something quite long and invisible, so it was a bit difficult to keep the motivation high. I really needed a side project done quickly. So having made and released Not Alone in less than 2 weeks (remember I'm a really part time indie dev) was very important to me. Something concrete!
Ok this was not very ambitious, polished, or amazing (I'm way more demanding than that for my "main" game) but that's Okay as it was not really the purpose here.


Still, I hope some people around the internet will try and maybe like the concept!
So feel free to leave a comment about Not Alone here, on Gamejolt or even on twitter.

Cheers!

Indie or Hobby?

I have been asked a couple of times to explain what I meant by hobby developer as compared to an indie. Well, here we go, that should be quick :-)

Indie?

I won't define what an indie developer here, first because it is something quite well known nowadays, and then because it has already been discussed by Derek Yu (@mossmouth) on his blog here.
As a quick summery of his definition which I find quite relevant, an indie is  :
    1. “Independent”, as in no publisher involved.
    2. Small studio (roughly 20 members or less).

Hobby developer?

Now, I consider that there are many subcategories of indie developers: the ones who have enough money to finance their work for instance (probably because they already released a successful game), as opposed to the ones who are making games with no money (no success, yet ! :-), and many others. But let's focus on our current topic, Hobby dev.

Defining it is quite simple at first glance : that's someone making games as a hobby. Sure it is, but that implies some interesting facts, that will shape the whole development cycle of the game.
The main aspect of that subcategory is that the developer as a full time job beside his own game. This job can be anything of course, from teacher to bartender or bank employee. This main specificity leads to 2 consequences : time and money.

Time is Money?

Having a full time job means that the main part of your time is spent at your workplace where you must not work on your game (or just in your head). So then you have your spare time, that you should share between your family, your friends, relaxing (and sleeping!) and possibly making a game. You have to find a balance between all of these. The result is basically that you don't have much time to work on your game, so that progress is slow. Damn slow. Holidays and week-ends can help boosting your velocity, but just to a certain degree. So you'll have to be prepared for a long road, or make something quite small.

Time is flying. Not much time for hobby.

The other impact of having a job beside your game development is that it is not essential that your game becomes a success (at least not if you have a decent job) from a revenue perspective. Your style of living should not be impacted if your project fails. If you decide to quit your job to focus on making a game, well, the stakes are higher then, and you are no more a hobby developer :-)

Need money to live

Slow development cycle, combined to the fact that it is not crucial to complete the project compose the explosive mix that makes tons of hobby development to fail or to be dropped. This is probably the biggest difficulty for a hobby developer.



So there you are, hope it answers the questions some of you may have. Don't hesitate to make a comment or ask questions if you have any, I'll be happy to answer!

First Design - First Mistakes

This posts is again attended to anyone that wants to go a game development as a hobby or even a indie, and this is just a piece based on my own experience.


Almost 1 year ago, after deciding to make a game of my own, I have started addressing my design. I had tons of ideas so I started to write them down...

Make a Game Design Document

That's something that will seem obvious for some, and useless to others. Writing all of your ideas, sort them and see if everything fit. This can be used as a first filter for not-so-good ideas.
Moreover, if someday someone joins you in your development, it will be a key asset to share the concept with him/her.
So I knew it was something really important and I made one...Kind of...

I know it may seems waste of time,
but it isn't. I promise.

Detail your Design document as much as you can

Unfortunately, I was not patient enough. I wanted, as many devs I've encountered, to jump into making things as soon as I could. So I did it, but actually it was a bit useless as it was not detailed enough and was basically just a summary of all my ideas, or draft of ideas. So when I had to start coding, I had to figure out how I was going to do things. I was then focusing on programming one feature at a time, and I probably lost the big picture.

Think features as part as a whole

One other thing that feels obvious when told but not so easy when actually making things is indeed to always think to how your feature will fit in your game. Several times, I've coded a feature as I have it in mind, and then had to change something or even rewrite all code so that it could really be used.
And after a while, I just couldn't bare anymore wasting my time...

Re-roll, change, kill...

So after several fails, I just had to face it : I needed to clearly put my design down on the table and do what I had to. For each idea, I asked myself : "Okay. How am I going to do that? What would it look from the player perspective? What exactly will the player experience be?"
Then, of course I realized that most of my ideas were good... But doesn't really fit each others. So I had to rethink the whole thing, kill many useless features, add a few critical ones.
As Antoine de Saint-Exupéry stated : "You know you've achieved perfection in design,not when you have nothing more to add,but when you have nothing more to take away"

Yeah I know... But you have to do it.

It took a while, but now my design is consistent (I think!), looks like a real game now (at least on the paper and the developed features) and not a clumsy patchwork of features anymore.

So here are again the obvious pieces of advice I would give to anyone wanting to go for an hobby or even an development :
-Write down your ideas
-Write a very detailed design document
-Don't be afraid to adapt things, and kills useless features

Bonus : latest mistake to date

Even when you know what you are doing and why, you may still commit mistakes. My last weekend experience can tell :
In my current game, I have a loot system where dropped items stats are defined automatically by player level. And I just figured out that my dumb formula I use to calculate these stats was an exponential one : at really high level (150+), I had things like a gun making 555433345 damages for each bullet....and around 500 bullets fired in a second...
Even if enemies stats are also increasing depending of player level, that seems weird for the less. I could have put a level cap as numbers were okay up to level 50, but I don't like it, and that doesn't fit the philosophy of my game which is basically about grinding.
So I have to design a new system I can tune the way I want. More work, and more wasted time. But that's okay as long as it should make the game better.