"Dreams are chaos!", she said.
        "Sure." replied the Daydreamer. "They are a bit messy, but you can do fantastic things within them."
        "You're mad. Do you seriously believe that you'll solve your problem by sleeping?"
        "Oh no, not by sleeping. By dreaming."

Note: this devlog post was originally located in this forum thread.

The Daydreamer is an upcoming platform-puzzle game. Use your skills and the unlimited power of dreaming to solve apparently impossible scenarios!

== Before the contest ==
This is the first jam I participate in. I have a bit of experience developing games, but I think it's still quite limited. 

When I saw the jam theme, an idea quickly formed in my mind. However, I wanted to challenge myself to do the full game, from its conception, during the 2-week contest period. Because of that, I simply avoided thinking about it until Day 1.

In this jam, I wanted to use some assets I recently got through different means. The most important one is the Corgi Engine, which is aimed at the creation of platform games in Unity. I wanted to learn how to effectively use those assets, but at the same time, I wanted to be able to adapt the assets to my game, instead of the opposite. Way more difficult and dangerous, as trying to modify a big asset like the Corgi Engine may turn into a worse, more time-consuming solution than simply coding everything from scratch.

== Day 1 (Saturday) ==
tl;dr: brainstorming, ideation through level design.

As I didn't want to simply stick with the first idea I had, I did some brainstorming. While I got a couple of extra possible ideas, in the end I decided to give my original idea (with some new enhancements) a try.

During the day, I started designing some levels for the game. During the process, I could check what mechanics would allow me to create better puzzles without complicating everything too much.

== Day 2 (Sunday) ==
tl;dr: setup, initial tackling of the "dream timescaling" challenge.

=== Setup ===
My first step was to create a new Unity Project. This time, I did something differently than usual: I added some assets directly from the "Create Project" dialog. Sadly, that didn't go well: the project took ages to get ready, some of the assets needed to be set-up before importing other (DOT Tween Pro > Doozy UI) and other assets weren't updated. After trying to get everything ready, the Corgi Engine didn't even work for some reason.

In the end, I closed Unity, deleted the newly-created project, and created it again without importing any asset. Then, I imported DOT Tween Pro, Doozy UI and Corgi Engine one by one, without issues. Some assets haven't been imported yet.

The next step was to set up source control with Git. As I always do, I created a repository in Bitbucket and prepared everything. The repository is private, partly to avoid trouble with mistakenly publishing third-party code such as the Corgi Engine, as I still don't know how well decoupled will my code be from that of the engine. 

=== Initial exploration ===

Of course, my first task was to explore the Corgi Engine. I discovered a finely organized project, with several nice examples and cool looking features. I concluded that the asset will probably help me to develop the game faster; let's hope it actually does. So far, so good.

=== Tackling the dreaming challenge ===

The Daydreamer can get asleep at [almost] any time, and he can get asleep within his dream (recommended movie: Inception). In each "dream level", time is slower than in the previous one, but time doesn't stop flowing. This means that, for example, if the Daydreamer gets asleep on a falling platform, he'll have some time to work with inside his dream before the platform falls in the real world. My first obstacle was to define how to handle this timescale-changing mechanic, given that several scenarios would be running at the same time at different timescales. In Unity, you can easily change the game timescale, but the change affects all the game; you can't selectively apply timing.

My first try was to see if I could somehow override Unity's Time.deltaTime function, maybe with an extension method. Sadly, that was simply not possible. It meant that I would need to mess with the Corgi Engine code since the begining. Sigh.

OK, let's do this. I modified all the Corgi Engine (!) so its components use a custom deltaTime function instead of Unity's deltaTime. That way, I would be able to play with the deltaTime value on desire, effectively applying a different timescale. I also created a component that allowed the control of this timescaling. The idea is that if a GameObject has that component attached, all its children will be affected by its timescaling.

== Day 3 (Monday) ==
tl;dr: short day, testing the dreaming mechanic.

I could work in the game only at night, so this was a short day.

I created a test scenario to try to make the dreaming mechanic work. The mechanic implied cloning and teleporting the player, spawning and destroying scenarios (the dreams) and changing the timescaling of the main scenario and the dreams. Some of those aspects involved further modification of the engine. Things worked quite well, but there are some critical bugs I still need to address.

== Day 4 (Tuesday) ==

tl; dr: short day, finished a basic dreaming system.

During the morning, I worked on finishing a basic dreaming system. 

It's not perfect (for example, the animators and particle effects are not affected by my custom timescaling), but I think it's good enough for the game.

Sadly, I couldn't work in the game after the morning.

== Day 5 (Wednesday) ==

tl; dr: created unlockable doors, created a full level, remade the dreaming system, game fully playable.

This day, I worked aggresively in creating a fully playable level for the game. This way, I could see what further stuff do I need to develop, and at the same time be able to playtest the game.

My first objective was to create obstacles that can be opened with keys. For this, I extended the Corgi Engine so I had a new kind of object (Unlockable Door) and a new player ability (Unlock Door). In the way, I found and reported a bug in the engine.

After having this, I had enough material to create my first testing level. It went quite well, as it showed me what features I was still missing, and allowed me to discover some invisible bugs in the dreaming system. In the end, I needed to do [again] some important changes to my dreaming system, and at night I already had a fully-playable game working as perfectly as I could see!

Next stops: graphics (including UI), implementing more levels.

== Day 6 (Thursday) ==

tl; dr: no work done.

== Day 7 (Friday) ==

tl; dr: visual design: character and some elements.

It's graphics day. I'm not an artist by any means, but I wanted to create some visual assets for the game. I didn't want to use premade assets because I wouldn't be sure the game had the aesthetics I desired. Also, as I wrote on day 1, I wanted to make the game as fully as possible.

For creating the character, I used Inkscape. I tried a lot of variations until I got something I actually liked. It wasn't easy, as my drawing skills are terrible. I then used Spriter Pro (which I got in a Humble Bundle some months ago, but I hadn't used it until now) to animate it. I worked until quite late, but after dealing with problems with Spriter I finally had a fully working character!

Next step: importing the character to Unity and actually using it.

== Day 8 (Saturday) ==

== Day 9 (Sunday) ==

tl; dr: adaptive music, more visuals, levels

== Day 10 (Monday) ==

This day, I redesigned the aesthetics of the dreams within dreams. I wanted them to look different; perhaps with a more "deep inside" feel. The dreaming action now can only be performed when the character is grounded.

== Day 11 (Tuesday) ==

== Day 12 (Wednesday) ==

The gif looks terrible, but you get the idea.