next »

[Mark Mayers]

Update 51: 07/26/2015

*To tree or not to tree*
Excuse the lame pun.

Today, I've been working with SpeedTree.

The tool is *fantastic* but I don't know if the trees I've made fit the art style of the game?
I'll have to experiment more.

I think I'll eventually include additional foliage in the game, but I need to work out a few things first.

---


I went with a dead/swampy theme.
I think I like the older version better. Maybe it's just the colors.

A few pictures of trees at different times of day.







Old version



---

There seems to be a shader bug with my render fog, so trees simply appear black at a distance.

I use SpeedTree trees for my title screen too, but I changed the shader.



See how the trees fade into the distance?
This is great and all, but there are  no animations for the trees with that shader.

I can't figure it out. I've banged my head against the wall dealing with render fog before.

---

I think I get discouraged sometimes, because I try to shoot for 'AAA Quality.'
In reality I'm just one guy, with no art experience.

[Christian]

Maybe it's just me, but the trees look off. Not their actual appearance, but their presence. Like they don't belong in this otherworldly place

[Mark Mayers]

Maybe it's just me, but the trees look off. Not their actual appearance, but their presence. Like they don't belong in this otherworldly place

It's definitely not just you, haha. I was thinking the same thing.
Something felt 'off' with the trees in the game, but I couldn't quite place it.

Maybe it's more of a thematic reason than a visual (both?).

The art style looks much more 'clean' and barren without them too.

I'll definitely have to investigate further.

[Mark Mayers]

Update 52: 07/27/2015

Two words: PARTICLE TREES

---

I did something... interesting with the SpeedTree meshes I made.

I exported them to my particle system, and now particles render and animate inside the tree mesh!





I think I'm going to keep it, although I'll tweak it a bit.
The effect is really interesting, and it fits in with the theme of the game.

From a narrative perspective:

What are the trees composed of? Antimatter?
Were they once normal trees?

---

For reference, I was thinking something similar to a cross between these two areas.

Crystal Song Forest from World of Warcraft



Lost Izalith from Dark Souls



I wanted to go with a gnarled looking tree like in Lost Izalith, that was transparent in the same way as the Crystal Song Forest trees.

---

BONUS PICTURE:

The 'skeleton' of the tree; also the scene without any particle effects, water, or sky.
Taken from edit mode when previewing the camera!

[Mark Mayers]

Update 53: 07/28/2015

Short update today!!

---



I ended up going with an additive particle shader for the trees.
The effect is more luminous and ethereal, although you can't see the trees as well from a distance.

Someone mentioned to me the 'bonus' picture trees looked better, the black particle effects weren't great.

I took that suggestion to heart, and I'm pretty happy with the results!

The effect is subtle, but interesting, here's a gif:

[qwetro]

Really love this art style, following!

[Mark Mayers]

Tha Frozen theme is somewhat somber, melancholic at least at first. I like that a lot and feel it fits great with the style. (Oh and thanks for the comment on Cloudfall! )

Realized I never responded to this!

Yea, Kyle is a fantastic pianist.
His Twitch Channel seems to be getting super popular too.
I'll have him stream the game sometime when it's ready!

It's been a year since I first contacted him asking about the Frozen theme! Time flies.

Really love this art style, following!

Thank you very much!

---

I'll also have a new DevLog update tonight, with some pretty cool news!

[Mark Mayers]

Update 54: 08/01/2015

Some cool news!

I was accepted into the Boston Festival of Indie Games for the Digital Showcase!
This is a pretty huge deal for me, as it will be the biggest festival/expo I'll be attending so far.

Apparently submissions were relatively competitive this year, with several hundred submissions and only fifty spots.

I'm really looking forward to going

I've been polishing up a new demo with a few of the things I've added in the last two months.

---

Recently, I've mostly been working on environmental and level design, to take a break from programming and mechanics.

I'm going to create a particle forest zone, filled with many types of particle trees.
So far, however, I've only made the entrance:




From another angle:




I've also made some small changes to the entrance to the mountain environment (which later transitions into that forest, and the beach).



---

Tomorrow I'm going back to programming.
I'm going to work on save states for after you solve a puzzle, so that it's world permanent.

I'll probably do some type of technical write up about it.

[eigenbom]

Looking awesome

[Mark Mayers]

Looking awesome

Thanks!! Really excited about Moonman
Keep up the fantastic work!

Update 55: 08/10/2015

This is going to be a rather long update! But with lots of pictures

Last week, I finally got around to implementing global illumination into the game.
I haven't taken advantage of the new Unity lighting engine! I was simply using the older, deferred lighting.

---

I had to change the way level loading works.

The main reason is that I couldn't find an easy way to dynamically switch lightmaps between scenes.
You can't really use Global Illumination if you have scenes that share static world objects (ex. the terrain), like I do.

It also wouldn't make sense to bake the lighting FOR EVERY SCENE in the game, as baking can take 30 minutes or more.
 
Here's how I changed it:

Before, I would simply load the scene with an Application.LoadLevel() call.
This is the most straightforward and easy way to load a level in Unity.

When switching between scenes (ex. walking through a door) an Application.LoadLevelAdditiveAsync() operation is called.
This is a function call that loads a scene asynchronously in the background, as to not interrupt gameplay.

I delete the previous scene after a player has walked through the door.
This hasn't changed. Door loading works exactly the same. (Old example GIF from way back when.)

What I do now, however, is that I use a merged level loading approach for the initial scene.

All persistent world objects (Terrain, Sky, Water, Player Inventory) that do not get deleted between scenes are loaded into a base scene.

I then merge the level objects for a particular scene with the base scene by calling a LoadLevelAdditive().

I've illustrated the process of how this all works below.

---

World 1 Scene with NO Global Illumination



This is what I originally start with to prepare the scene.
This consists of only the terrain and the lighting, before baking the GI.

---

World 1 Scene WITH Global Illumination



This is a picture of the base terrain *after* baked global illumination has been applied.

This means static lights have been applied as lightmaps, and realtime GI has been pre-computed for runtime.

I use this scene as the base scene to call a LoadLevelAdditive() on.

---

World 1 Scene, Critical Puzzle Elements



These are the objects in the scene comprising the actual puzzle.
This is the scene data that is added into the world dynamically between areas.

---

World 1 Scene, Runtime with Everything Loaded



A captured image from editor view of what the scene looks like at runtime.
The base world and the scene are now merged together.

Realtime lighting is applied here.

This is also where objects like particle effects and the ocean prefab become active.

---

The Final Scene! From the Player's Perspective



This is what the scene actually looks like to the player.
Here, post processing is applied as a render effect.

---

Also, YOUR CPU GETS REALLY HOT WHILE BAKING GI.
I actually blue-screened twice while doing it.



Maybe I should lower my overclock? Nahhh.

---

I also *did* manage to write in a permanent world/save system while I was at it, as I mentioned in my previous entry.

Now, when you solve a puzzle it will remain solved for your play through.
That was fairly straightforward, I just use a key/value system to determine what has been completed or not and reference it accordingly.

Overall, I had a good amount of fun implementing all of this!

[Mark Mayers]

Update 56: 08/18/2015

This update is about Particle Boosters which are powered by Orange Stars.




---

Particle boosters apply force to the player, sending him/her flying to previously unreachable heights.



---

Particle boosters also change the trajectory of energy particles!

A force is applied which changes their direction, relative to the particle booster.



This gif shows a star that is blocked by a blue particle wall, which reflects energy.
It is impossible for the player to activate the star by shooting directly at it.

The player must take advantage of particle redirection via particle boosters.


---

I'm preparing a well polished demo for the Boston Festival of Indie Games, which I am super exited for

I'm also showing at the Playcrafting Boston Summer Expo, next week!

If you happen to be in the area, come say hi!

[Mark Mayers]

Update 57: 09/02/2015

It's been quite a bit since I posted an update!
I've been preparing for BFIG which is in two weeks!

I'll keep this update rather short.

---

Here's a preview of a new level I've made.

This is towards the end of a puzzle; it's one of the few places you can see the sun in the canyon world.

Dusk:



Night:



Dawn/Day:



---

I've also been working on Mega Particle Boosters which are used as a transportation mechanism to get between levels.

If you pay close attention, the player is actually flying over a previous level (the one posted in the last DevLog) and landing in a secret, previously inaccessible area.



Also, the player flies through a loading door in this gif.

I've managed to get loading times between levels near instantaneous!

[Mark Mayers]

Update 58: 09/09/2015

The Boston Festival of Indie Games is on Saturday, and I'm putting the final touches on my demo.

---

This might seem like perfectionism (and it totally is) but I've been reevaluating a few color choices.


New, slightly revised color scheme:




Old color scheme from earlier:



The difference is very subtle, dealing with the color of the fog being too green/saturated relative to the rest of the area.

I also changed the color of the water to be much more vibrant.

---

My artist friend recommended I use this tool which helps you pick a color scheme.

I've found it incredibly useful at checking my intuition of what seems to fit, and what doesn't.

I mentioned before I don't have any formal art experience.
Desolus is made entirely without using a 3D art program, everything is generated in-engine. 

I come from a Computer Science background, so it's hard for me to know what is 'correct' when it comes to art.
However, there really isn't anything 'correct' in terms of visual style, everything is subjective.

---

One of the primary methods I get by with my lack of art experience and modeling resources, is usage of color.

Color is the driving force behind my art style, along with composition and symmetry.
I pay particular attention to every single detail, as it has a dramatic effect on the game.

As an experiment, I changed only three parameters to render this picture; the color of the water, sky, and background:



The picture looks interesting, but it seems like an entirely different area.

(Although I took only a minute to choose these colors, it was rather arbitrary).

With a few colors, I can make use of limited art resources to create a different experience.

It's also a similar technique to what older video games used to do; ex. the original Zelda.



In this case, their limitation was technology and arguably time as a resource.
In my case, it's time and experience, but I have technological/algorithmic assistance.

---

Someone once jokingly said to me, "Mark, you take programmer art to the extreme." I found that hilarious.

It's true though, the development of this game has been tailored to my experience and ability.

For example, there aren't any enemies, AI, animations, cutscenes, etc. in the game.
I didn't choose to cut these based on creative vision, but more self discovery of what I'm good and bad at.

It's also a product of overcoming naivete and ambitious scope of vision (something I still struggle with).

To the passive reader, this DevLog probably seems like an amalgamation of weird ideas and concepts, with an ambiguous direction.

I've scrapped and remade probably 90% of the content so far. All for the better, in my opinion; to make a well polished result.

Desolus has organically evolved with my abilities and experience over time, and will continue to do so.

[bitserum]

I wouldn't worry about "correctness" in art, it's not so intellectual as much as being playful, chaotic, random... and you're doing something right there as everything looks really interesting. I always find I enjoy a nice atmosphere much more than fidelity.

[oldblood]

Agreed with bitserum, no need to worry about it being correct or not. It's very atmospheric and it looks great.

I think for me, it's been the organic evolution of your game thats kept me coming back to the devlog. So even if you feel that (as you said) the devlog has a "ambiguous direction", in some ways-- that's what make this an interesting devlog to follow.

Will the demo for the Boston Festival be available publicly?

[Mark Mayers]

I wouldn't worry about "correctness" in art, it's not so intellectual as much as being playful, chaotic, random... and you're doing something right there as everything looks really interesting. I always find I enjoy a nice atmosphere much more than fidelity.

Many times it's the imperfections that make interesting content anyway.

I went in with a 'I'm going to make something cool, even if it doesn't make sense' approach.
I seem to at least be doing relatively well with it, heh. Although there's always room for improvement.

Agreed with bitserum, no need to worry about it being correct or not. It's very atmospheric and it looks great.

I think for me, it's been the organic evolution of your game thats kept me coming back to the devlog. So even if you feel that (as you said) the devlog has a "ambiguous direction", in some ways-- that's what make this an interesting devlog to follow.

Will the demo for the Boston Festival be available publicly?

Thanks! Yea, this game has definitely been a learning experience for me.

I try to make a lot of the game objectively, through the results from playtesting and experimentation.
Really though it's been a product of my own strengths/weaknesses, primarily driven by my personal taste of what I think is interesting.

In regards to the BFIG demo, I'll probably keep it private for now, limited to conventions. 

Eventually I *do* need to make a semi-public demo for feedback from developers or content for press.
For now I'm making sure I have something exceptionally well polished.

However, I've definitely thought that could potentially put me at a disadvantage from a marketing perspective, in regards to not having enough exposure over time. Who knows?

[oldblood]

In regards to the BFIG demo, I'll probably keep it private for now, limited to conventions. 

Eventually I *do* need to make a semi-public demo for feedback from developers or content for press.
For now I'm making sure I have something exceptionally well polished.

However, I've definitely thought that could potentially put me at a disadvantage from a marketing perspective, in regards to not having enough exposure over time. Who knows?

I think there's definitely advantages and disadvantages to public demos. Frankly speaking, I was always very anti-demo... Mostly cause I didnt want to spoil the experience with an imperfect or unfinished part of gameplay. Doing the public demo for Masochisia was the best thing I ever did on the game...

The feedback I got was invaluable. You'd be surprised the ways people play a game, even a linear one... And watching the videos on YouTube helped the most. Player reactions, seeing what parts got people excited and which parts led to people getting bored... Was huge. You get used to working in your own bubble in indie gamedev. Outside perspective can be really powerful to pinpoint whats working (or not working) in your work.

As far as marketing exposure... the demo's had just under 5,000 downloads on Gamejolt and itch.io since April. But I have no clue if that actually translates sales or marketing (since my game isn't out yet) but I know at least 5,000 people who may not have ever known my game existed are at least familiar with it.

Not saying you need to have a demo. You don't. But I think the potential positives can really outweigh the potential issues. Just my .02 based on my experiences with my "first demo". Your mileage may vary.

[Mark Mayers]

I think there's definitely advantages and disadvantages to public demos. Frankly speaking, I was always very anti-demo... Mostly cause I didnt want to spoil the experience with an imperfect or unfinished part of gameplay. Doing the public demo for Masochisia was the best thing I ever did on the game...

The feedback I got was invaluable. You'd be surprised the ways people play a game, even a linear one... And watching the videos on YouTube helped the most. Player reactions, seeing what parts got people excited and which parts led to people getting bored... Was huge. You get used to working in your own bubble in indie gamedev. Outside perspective can be really powerful to pinpoint whats working (or not working) in your work.

As far as marketing exposure... the demo's had just under 5,000 downloads on Gamejolt and itch.io since April. But I have no clue if that actually translates sales or marketing (since my game isn't out yet) but I know at least 5,000 people who may not have ever known my game existed are at least familiar with it.

Not saying you need to have a demo. You don't. But I think the potential positives can really outweigh the potential issues. Just my .02 based on my experiences with my "first demo". Your mileage may vary.

I think that's great advice. I definitely have a strong tendency towards perfectionism, so I can relate.

For a while I lacked confidence with the game, so I didn't want to leave a bad impression.

In reality, there are a ridiculous amount of people living on this planet that have the capabilities to play/buy your game.

Even if your game is *awful* leaving a bad impression for only a small subset doesn't mean much.
You can take that feedback and make something amazing, which is more valuable.

Things have changed though, I'm getting very positive feedback on the gameplay.
People are playing through the 30 minute demo and enjoying it; regardless of age, gender, gaming experience etc.
There was a seemingly ubiquitous appeal to the aesthetics, but I wanted to make sure the gameplay truly shines.

I think for me it's more of an issue of 'BUT WAIT, I'm not done! It's not perfect!' so I haven't made a public demo.
You'll always see your own flaws more than anyone else.

A year ago I was rejected from BFIG, although Desolus was an entirely different game.
That's why this year is so important to me, that I was accepted into the festival. 

That was probably the best thing that's happened to me in regards to this game.
It's made me rethink my design and decisions, which has made the game significantly better.

I don't know, maybe I should release a demo; at least one to TIGSource. 

I still need to do a few technical optimizations first, however.
You need a very good computer to play the game as of right now.

PS. Finally played your demo; I think the direction you're going is great.
I'll make a post in your DevLog with feedback!

[Mark Mayers]

Update 59: 09/20/2015

As it's been a week since the Boston Festival of Indie Games and I've finally recovered, I've decided to write a postmortem of the event.

==Technical==

Upgrading Unity

One of my main mistakes before the festival was upgrading Unity.
WHY did I do this you ask? Why was I so crazy to upgrade the engine the day before the festival?
Oculus Rift of course! It was a struggle, but was worth it.

Oculus Rift

There is a massive upgrade in Oculus Rift quality coming from Unity 5.0 to 5.2.
One of the main benefits is in-editor support. Before, I would have to compile the build to test anything out.

I also updated the control scheme for Oculus to feel much more natural.
This consisted of analyzing the source code of Unity's Oculus Rift scripts, and integrating it with my own control scheme.

Probably the most important piece of code is this (taken from the Oculus character controller):



It's simple in concept, but it's absolutely critical for the control scheme.
This code normalizes the player's rotation relative to the player's real world position.

I didn't have this before! Which meant that 'forward' on the keyboard or controller was an absolute vector.
The consequences of this were the player would have to be facing *exactly* at the correct angle in real-world rotation to be correct.
Obviously, without this there is a huge amount of disorientation.

I am incredibly glad I fixed this issue before BFIG, it was worth the lack of sleep.

Fortunately, nobody during the demo felt any type of motion sickness.
This was a problem I had before with my previous control scheme, likely due to the unnatural movement.

Rendering Issues

I had issues with deferred rendering in Unity 5.2, and unfortunately, I had to switch to forward rendering.

My render fog doesn't work with 5.2 correctly, due to changes in opaque shaders:



I had two options; manually edit my terrain shaders and water shaders, or switch my rendering mode.

Fortunately, forward rendering did seem to solve the problem:



I had to essentially remake my water assets, however, as the different rendering modes completely change how it looks.

---

==Design==

Tutorial Explanation

The majority of people seemed to finish the demo successfully, which is great!

However, I still have a few design issues to solve with introducing mechanics to the player.

This was the introduction level:



Key:
A- The starting point
B- Active star, corresponding to a light bridge
C- The singularity ability
D- An inactive star

To complete the tutorial level:
-Traverse from A to B, by crossing the light bridge
-Get close to C, which gives you the singularity ability (to absorb energy)
-Traverse back to A
-Take the energy from B, and shoot it at D to activate the light bridge
-Walk up newly activated light bridge at D

This is *way* too complicated.

I realized there is no point to having the player 'acquire' the singularity in the context of this demo; it should already be active.

In the very beginning, some players would get confused.
You can't actually do anything until you gain the singularity ability from point C.

The ability 'sphere' plays the title theme music; so naturally I would assume people would walk towards it.
However, the music wasn't enough. Especially for those on the non-oculus computer; my speakers on my monitor weren't loud enough.

The energy transfer between stars, aka the core mechanic, only about 50% understood without instruction/help.

In the beginning of the day I would sit back and watch people play, to take notes.
About half way through the day I gave up on this.

I wanted people to get past the 'tutorial' and enjoy the game, so I instructed what to do for those confused. 
Definitely not a good thing, but I now have at least some idea of what the problem is.

Resetting the Demo

I realized about 30 minutes through the festival that I had no way of resetting the demo, besides closing and restarting the application.

This was something I truly regretted not including; I didn't even think of it.
I spent a lot of time switching my keyboard between the two computers to restart the demo.

Although menus are super boring, I think it's time for me to create some.

---

==Presentation==

I definitely owe a huge amount to my friends who helped me with my booth.
Two of my good friends woke up at 7am to help me prepare.

I had to transport 2 27" monitors, my 50 pound massive desktop (to run the Oculus build), my mini desktop, and everything in between.

Even though I had to carry my behemoth of a desktop, it was definitely worth it.



Oculus was a huge hit (that kid waited for 45 minutes in line!).

My friends also helped me with managing the booth at the convention.
I had a crowd around my booth at all times, and it would have been nearly impossible to manage by myself.

I think I have the elevator pitch down. I said this at least 200 times:

"Desolus is a first person puzzle and exploration game where you control a black hole to absorb and redirect energy from stars.
The game resembles a cross between Metroid Prime and Portal."

The booth setup wasn't anything incredible. I need to work on my actual presentation for the future.
I *did* however, manage to get a poster the day before; although I didn't have a proper place to hang it.

The game itself, however, gathered a decent crowd.



The lack of sleep definitely got to me later in the day.
I arrived at BFIG around 8am, and by 6pm I was feeling absolutely exhausted.
I packed everything up a little bit early, mostly to attend the festival keynote.

Susan Gold, one of my former professors at Northeastern, gave the keynote to the festival.
I was actually in the keynote! Briefly.

The theme was regarding the indie community in Boston, and the diversity of developers.

Susan took the below picture during the festival.
She mentioned how many of her former students later became independent game developers, regardless of their background (I wasn't a game design major).



---

Overall, despite the lack of sleep and frantic bug fixing the day before, I had a fantastic time.

I took a bit of a break this week after the festival. However, I think I deserved it.

I'm excited where this game is going.
I got several emails afterwards, people said they really liked the game.

I wasn't focused on press at all during the event, but I did have a brief article written about the game.

After the enthusiasm from people who played Desolus at the festival, I feel great.

[bitserum]

Congratulations on gathering interest on the festival!
One unimportant note for resetting the game, what we did with Cloudfall on festivals is simply bind the reset to a single key, as we never had enough time or will to tackle on menu development (and no need either, yet).

Have you decided if you'll be making the demo more public?