next »

[Mark Mayers]

Update 79: 05/16/2016

I think I'm finally back in the groove! It was a long recovery from the April conventions.
I'm probably not doing another major convention until the Boston Festival of Indie Games in September.

I'll still be presenting at smaller events however. Like next week!

Speaking of conventions, I've decided to do a late application for IndieCade.
I would like incorporate a new door/loading system into the new demo.

---

I'm redoing a great deal of the level layouts based off of the changes I've made with scene transitions.
Levels now no longer are directly adjacent to each other, which gives me a good deal of design freedom.



Each world is essentially a archipelago, with individual levels existing as a self contained island.

The above picture is a prototype layout of what the world will look like.
The 'final' art looks like this. I am keeping the central area pretty much the same (as you can see in the prototype picture).



I keep the leftover simple geometry for scene composition even when I make the real art assets, in case I want to make tweaks.

The hard part isn't necessarily the creation of the art assets themselves, but more the perspective and general layout of a scene.
I can pretty much 'throw away' an entire world, but if I keep its skeletal structure in simple geometry it's very easy to rebuild.

However, I spend a great deal of time on the artistic composition of each level, to make sure it looks interesting.
The earlier puzzle mechanics also rely on line of sight, so scene composition is especially critical to the design.

---

Unity would like to feature Desolus again on their Made With Unity page, so I am grateful for that!

I'm in the process of writing up an article based on my experience at conventions, primarily at PAX East.
A portion of the article will be part of my retrospective that I wrote a few weeks ago.

[Mark Mayers]

Update 80: 05/28/2016

I've been prototyping a new mechanic which I am pretty excited about.

---

If you've been following this devlog, you know Metroid Prime is an influence on this game's design.



I was thinking of the dual dimensions in Metroid Prime 2.
The planet you explore in the game is in a state of near dimensional collapse, the light and dark worlds are both fighting to exist.

This concept is present in lots of science fiction.

Back when it was on TV, I was a pretty big fan of the show Fringe. If you haven't seen it, it's kind of like the modern version of the X-Files.  
(Minor Fringe Spoilers): Most of the show is based around interactions between two dimensions, where realities are slightly different.

Sometimes the two universes become unstable. Windows appear to that alternate dimension, allowing objects to travel through.



---

Desolus is a game about symmetry, inversion, and impossible technology (like controlling a black hole).
I figured a dual dimension mechanic would be welcome in the game.

Last night I was working on how the player would transition between dimensions.
I wanted seamless transitions. I researched how to do this for quite some time, I was happy to see my implementation worked.

In this new mechanic, you can walk through 'tears' between two worlds.



---

The effect is performed by rendering with a stencil buffer shader.

When walking through the portals, there's some fancy math to determine when the ideal time is to switch the main camera between the dimensions.



The effect prototype was pretty successful, and I'm happy with it, but there are still a few problems.

-The portals are 2D effects, and have no 3D depth:
Imagine each portal being like a window into another universe. However, it more acts like a 2D image effect right now rather than a true 3D object.
You can see what I mean by looking at the gif and paying attention to the white/black particles.
Notice how the opposite particles from the other dimension do not always appear correctly in 3D space?

-The portals aren't recursive:
I can't have portals render within portals.
I think this would be a cool effect, as you can have a recursive swap between dimensions which would give very interesting results visually and mechanically.
 
-I have to rewrite most of my shaders:
This one isn't as bad as it sounds, because it's only a few lines per shader to work with the effect.
However, I have to pretty much redo my entire sky and water system to work with this new mechanic.

---

Overall, I will continue exploring this mechanic because I feel it has a huge amount of potential to expand the game.

[io3 creations]

When walking through the portals, there's some fancy math to determine when the ideal time is to switch the main camera between the dimensions.
The effect prototype was pretty successful, and I'm happy with it, but there are still a few problems.

-The portals are 2D effects, and have no 3D depth:
Imagine each portal being like a window into another universe. However, it more acts like a 2D image effect right now rather than a true 3D object.
You can see what I mean by looking at the gif and paying attention to the white/black particles.
Notice how the opposite particles from the other dimension do not always appear correctly in 3D space?

That makes sense if you haven't implemented any depth check or consideration when rendering.  It might be possible to have that type of check in shaders but it might be simpler to hide/show objects as needed.  Though performance considerations might come into play as well as to which approach is faster.

[Mark Mayers]

That makes sense if you haven't implemented any depth check or consideration when rendering.  It might be possible to have that type of check in shaders but it might be simpler to hide/show objects as needed.  Though performance considerations might come into play as well as to which approach is faster.

Yea! There's currently no depth depth check in the shader, so that would explain it.
There's also no occlusion culling between dimensions, so that's something I need to implement too.

There's a lot more craziness that I've been working on recently. I'll have an update with my adventures down the rabbit hole tonight.

[Mark Mayers]

Update 81: 06/01/2016

Two years ago I lived across the street from the Museum of Fine Arts in Boston.
One of my favorite exhibits involves an infinitely recursive box of mirrors.



Something about infinite reflections is amazing to me. I wanted this in the game some how.

This of course, might remind you of the infinite recursions when aligning two portals in Portal.



The portal objects in the game are essentially a set of inverted mirrors, which produces the recursive effect reminiscent of the exhibit in the MFA.

Even though it's been almost 9 years since Portal was released, I want to experiment with the mechanic in my own style.
I think there is room for a portal mechanic to work in the game, but not have it be derivative.
 
I started immediately with the portal rendering itself. I was able to get infinite recursion working two days ago by using render textures.  



---

Many people really enjoyed the dimension inversion effect. I think it's definitely going into the game in some form.



However, I still need to work out some other details as discussed in the previous devlog.

What gets insane is the thought of putting a dimension inversion in between recursive portals.



The effect produced is pretty amazing.

However, if you think really hard about this, you'll notice the rendering sequence of dimensions in the screenshot I showed is actually incorrect.
I made this chart to help me visualize how this effect should be rendered.




This is the current rendering sequence as shown in the screenshot.
Currently, portals simply copy the scene infinitely rather than properly inverting dimensions with every recursion.

To fix this, relative to the incorrect (current) rendering system:
-When not looking through an inversion, recursive portals have their dimensions swapped every 2n recursions.
-When looking through an inversion, recursive portals have their dimensions swapped every 2n - 1 recursions.

The correct rendering sequence should be as below.



Simply put, dimension swaps should happen only between every recursion, and also affect the following recursion.

The TRUE insanity begins when you think about viewing a set of recursive portals through a dimension inversion.



When you stare through a dimension inversion with recursive portals, you would see an inverted set of portals as well.

Let your brain sit on that idea for a bit!

---

So how do I actually accomplish this from a rendering perspective?

-First I have to get dimension inversions working when seen recursively.  
Right now a dimension inversion will only overlay another, rather than truly inverting it.

-The dimension inversion is a stencil buffer effect, while the portal recursion is a render texture effect.
Currently the portals grab the stencil buffer BEFORE they generate a render texture.
However, I need to also figure out how to reapply a stencil buffer inversion effect AFTER a portal render texture is generated.

---

My brain hurts. If you have no idea what I'm talking about, it's ok I don't either.

[Mark Mayers]

Update 82: 06/05/2016

Currently going a bit crazy trying to figure out how to write stencil masks correctly.
This is for the new dimension swap mechanic I've been working on.

I've been reading a few tutorials on stencil masking. This is a good one:
-Impossible Geometry: Non-Euclidean Cubes

NOTE: If you're not familiar with stencil buffers and masking I would read that tutorial. Otherwise, this devlog entry will make no sense to you!

---

Good news is, I got recursive stencil masking to work correctly.

Here's a gif of the result.



However, I'm still having some problems. Essentially I want the stencil mask to only affect objects behind it.

If you stare at the gif, you'll notice that the stencil inversion is actually only a 2D effect, and not a 3D effect.
Look closely at the black and white particles, something seem a little strange?

The shader still doesn't use depth correctly. The particles currently disregard 3 dimensional space.  

Objects in FRONT of the stencil mask should act normally but currently the stencil mask affects objects both in front and behind of it.

****ing shaders  

[Mark Mayers]

Update 83: 06/06/2016

Yesterday I actually managed to figure out the biggest rendering problem I had with inversions between dimensions.

This was the previous version, as shown in yesterday's DevLog.



Pay attention to the black/white particles, and how the dimension inversions interact with them.

Both dimension's particles exist in the same three dimensional world space.
The issue was that the dimensions didn't render particles (or any object) in world space correctly between dimensions. Read my previous entry for more detail.

Due to some complex depth testing and very specific rendering order issues, I managed to fix most of my problems. Here's a gif,



Notice how the particles correctly render between dimensions in world space!

The only issue right now is that the inversions essentially create a 'hole' in space, and cull any objects when viewing an inversion.
This is especially apparent when doing this effect recursively. It's hard to explain.

However, I might keep it this way! I can make some interesting puzzles about hiding objects between certain perspectives.

---

If you've been following the game, you'll know that Desolus is a game where you absorb and transfer energy between stars with a black hole.



This gif is taken from my PAX East 2016 demo (high quality).

The player absorbs from an active star on the left and transfers this energy to an inactive star on the right.
When all stars in the environment are active, a prism shines light on a door that leads to the next puzzle.

Most of the puzzles until this point have been about line of sight, and how the player navigates the level to transfer energy.
While this was interesting and received well, I wasn't satisfied with the amount of depth the game had.

---

The dual dimensions mechanic adds a huge amount of depth to the game, and also raises a lot of questions I need to answer from a design standpoint.

For the purpose of this DevLog these questions are rhetorical, as answers would be potential puzzle spoilers.
Each questions corresponds to the properties of how energy travels through dimensions.

• What happens to energy when you shoot it into a different dimension?

         You're standing in dimension A, absorb energy from a star in dimension A, and shoot into dimension B.

• What happens when you absorb energy from a different dimension?

         You're standing in dimension A, and absorb energy from a star in dimension B.
          A second question could arise from this: What happens when shooting that possibly modified energy into either dimension?

• What happens to absorbed energy when you carry it into an inversion?

         You absorb energy from A and walk into dimension B.

• What happens to energy when you shoot energy into another dimension, but look away from the inversion?

         While in dimension A, absorb energy from A, shoot into B, but look away from B while still in A.
          Can you still see the energy from your current dimension, without looking through an inversion?    

• What about all of these concepts, but with overlapping/recursive inversions?

         This could get pretty complicated. The gifs at the start of this DevLog are an example of an overlapping inversion.

• etc.

The player would learn the answers to these questions throughout the game's progression.
Each of these ideas are essentially 'tools' in the player's repertoire to complete puzzles.

I want the player to explore and intuitively observe how mechanics interact with each other.

Desolus has already been pretty difficult to design, as I'm teaching abstract concepts implicitly (with no tutorial text).
The challenge is keeping the player engaged to want to learn more about the game's mechanics, but also not make the player frustrated.

[Mark Mayers]

Update 84: 06/12/2016

Recently I've been focusing on revising my dynamic sky system to work with the new dimension inversions.

Dark Dimension: (Dimension 1)



Light Dimension: (Dimension 2)



---

Before I was using a heavily modified version of Tenkoku Dynamic Sky for my system.

This did the job pretty well for a while, however I needed a fully custom solution to work with my dimension inversions.
Also, the system looked nice but it was extremely expensive to render; I was due for an upgrade. 

I ended up taking my previous version of the sky system (which was in Javascript) and rewrote it in C# to be much more simple.



You can modify all the parameters for the sky in BOTH dimensions via a single script.
This leads to a nearly endless number of sky customizations. I will be adding more features later, but for now this will do.

The performance has also increased drastically between the sky systems.
I already customized the old system for optimization, but rewriting it entirely had major benefits.
 


This is for the scene that I took screenshots of, but with the various sky systems.

Subtracting the sky benchmarks from the empty scene:
-The old system renders in 1.3ms per frame and 115 draw calls.
-The new sky system renders in about .2ms per frame in 34 draw calls!

Saying how I'm rendering two complicated sky systems at once (in different stencil buffers) this is pretty good.
It's a huge improvement; I could probably do better but I'll save extreme optimization for later.   

Since this is in VR I need every ounce of optimization I can get.

---

Now that I have most of the rendering aspects done for inversions, I'll be working on creating experimental sample levels with the new mechanics.

[Mark Mayers]

Update 85: 06/15/2016

I'm currently working on integrating the previous game mechanics into the new dimensional inversion system.

So far it's going pretty well, although I have to rewrite a lot of the game's code to work with the new mechanics.

On the rendering and shader side of things, the dimension inversions are pretty much done.
There are still a few small things I need to do, but I would rather focus on puzzle mechanics right now, and polish later.





I've drafted up some interesting puzzles on paper in regards to how I'll be using the dimension swaps.

Essentially, the game world takes place between a 'dark' and 'light' dimension (pictured above).
You can manipulate light/dark energy in the respective dimension.

There's also a third 'super state' energy type which is a combination of light and dark.
This will have some very special properties, and lead to some crazy puzzles. 

I'll have a more detailed entry in the coming days.

[Mark Mayers]

Update 86: 06/27/2016

I've started to prototype a lot of the new systems and work on level design.
However, I'm currently reworking a lot of the shaders for the dimension inversions due to some depth testing issues.

---

If you look carefully at this screenshot, you can see the problem.



The issue is that particles will appear 'behind' terrain.

A closer look here:



This is because I set the depth testing for particles to ZTest Greater, meaning that the particles will only render behind objects.
Previously this was the intended behavior of the particles, as I'm using a weird combination of depth testing and stencil buffers.

I ended up inverting the way that I did depth testing to fix a lot of the issues.
(Ex. I switched all my 'Greater' to 'Less' for depth testing.)

However, this is essentially trading one problem for another.

Now since I have a decent amount of shader experience, I will likely just completely rewrite the shader code correctly.
I did it partially here. You can see that the particles now render correctly with the terrain.



However, there's still an issue with the particles rendering on the other 'side' of the dimension inversion.
It's hard to tell from this screenshot, but it's an issue that needs to be fixed.

[gimymblert]

Still beautiful though!

[Mark Mayers]

Still beautiful though!

 

[Mark Mayers]

Update 87: 06/28/2016

Last night I manged to fix the majority of my shader issues with the dimension inversions.

One of the issues I had with the new approach is that the shaders wouldn't work when dimension inversions were recursive.



I fixed this with some complicated depth testing and strange usage of the stencil buffer. I'll go into more detail when I have it perfected.

--

Instead of shaders, I worked on art and design tonight to take a break, and made some small changes.

I also swapped energy types between the two dimensions (Light/Dark).



Now the 'Light Dimension' has Dark Energy, and the 'Dark Dimension' has Light Energy.




I'll dive into the philosophy and narrative behind the game in a later post.

Let's say for now a central theme of the game is dichotomy, inversion, and what happens when you upset the balance between two symmetrical halves.

[ActualDog]

Just wanted to stop in and say this looks gorgeous and I love all the detail you're going into. Very cool blend of art and tech.

[Mark Mayers]

Just wanted to stop in and say this looks gorgeous and I love all the detail you're going into. Very cool blend of art and tech.

Thank you!

I originally began development of this game with very little art experience, since my background is in Computer Science.
Most of the art is procedural and minimalist because of this, but it definitely gives a unique art style.

[Mark Mayers]

Update 88: 07/05/2016

This post is a retrospective and self criticism regarding my creative and game development process.
I made a similar post a while ago, but my process has become much more refined since then.

---

Prototyping for Rapid Development

Once every 2-4 months, I have a 'development cycle' where the game ends up in a highly revised state with a polished demo to represent this.
This has been a great approach, as it pushes me to have something playable representing the current game.

--

-Paper Prototype-



Before I even begin making levels, I make sure to write ideas down on paper. I find it immensely useful for organizing thoughts and design.
Here ideas are mostly in the 'brainstorm' stage, or just fragments of concepts.

I mostly plan out designs with crude sketches, but imagine/visualize a created level in my head.
Fortunately I do exceptionally well with image visualization and retention, most of the design in the final concepts comes directly from imagination.    

In regards to gameplay structure for a particular level, I imagine how a puzzle would be solved and play out the game in my head.  
I take notes regarding interesting concepts I could convey with an individual puzzle, and how it fits into the game itself.

--

-Low Fidelity Prototype-



Low fidelity prototypes are something I've been recently doing, which has been immensely helpful.
Before I would simply jump right in to the high-fidelity stage, and create final content without proper iteration.

I create a low fidelity prototype with simple prefabs to map out how a level will be structured.
This mirrors the paper design, but instead use simple shapes and create the level in 3D.

I use Probuilder for this prototyping process, since it's intuitive and simple to use.
There have been entire games made with Probuilder, as it's also capable of high fidelity visuals with shaders and a good art style.

The goal at the end of this stage is to have a playable level sequence, without any of the art assets produced.
I usually give these demos to close friends to playtest, as they are very rough drafts.

--

-High Fidelity Prototype-



At this stage I'll have a rough draft of the art assets added to the game on top of the prototypes I created earlier.

These demos I normally bring to local meetups or small expos (fewer than 1000 people).
Here I gather playtesting feedback from a larger subset of people.

I use that feedback to refine aspects of the game for the final stages of the development cycle.
This stage may also encompass a few iterations in itself, if I need to make major changes to design.

--

-Final State of Iteration-



This is the 'polished' content that exists after the 2 month iteration.

These types of demos are those that I've submitted to festivals or expos, that shows the game in its best state.

The last example of this is my demo from PAX East 2016.
It took several months of preparation to reach a state where I felt comfortable showing the game.

Each final state has been a landmark in the game's development.
I keep these demos around to remind myself of how much the game has improved since the last iteration.

--

-Post Iteration-

This is usually the 'existential crisis' point (hah) where I deeply evaluate how to make the game better.
There have been several major design changes because of this.

Previously after the end of every 2-4 months I've largely *thrown away* that final state, which can be discouraging.

Instead of making content for the game, I've been catering towards festivals, expos, or local meetups.
This is even true with the PAX East demo. Those concepts have now evolved into a much more cohesive design, and I have abandoned that level set.  

In the long run this will end up in a better game with a polished and interesting design (hopefully).
However, I'm constantly in a state of adding/revising content, which means the resulting levels reflecting this content are ultimately different.

---


Self Criticism of Game Development Process

In the past I've had trouble creating highly polished demos and later throwing them away entirely.

A lot of this mindset comes from submitting for festivals and expos.
I hold the game to high standards, and want to ensure the impression I leave is a good one.
 
However, this mentality is detrimental to the overall design of the game.

I've realized I spend way too much time on small details and not the greater picture.

I've had difficulties with polishing ideas or assets too quickly, in the sense of spending too much time making a feature 'perfect.'
This is before fully considering the greater design impact on the game, or whether the content will even be used.

Before, I have had problems in the 'prototyping' stages at the beginning of the cycle.
I would simply dive into creating a highly polished set of levels vs. figuring out what works or what doesn't early. (A common mistake, but I'm still learning).

Desolus is full of thrown away ideas.
That time being a perfectionist is wasted, outside of becoming better at design as a skill.

---

Conclusions

Over the past few months I've made a transition to improve my development process.
Recent efforts have been to focus on design, mechanics, and rapid prototyping of content; rather than perfectionism, presentation, and polish.

Since I am now in the middle stages of development and have a much more solid concept, I am taking it easier in regards to rushed preparation for festivals.
I'm both adopting a longer development cycle for my demos and purposely *not* attending festivals until September (which is the Boston Festival of Indie Games).

In the next few months I plan on having a much larger section of the game carved out with the new mechanics.

[jordanchin]

Update 81: 06/01/2016

Something about infinite reflections is amazing to me. I wanted this in the game some how.

This of course, might remind you of the infinite recursions when aligning two portals in Portal.



The portal objects in the game are essentially a set of inverted mirrors, which produces the recursive effect reminiscent of the exhibit in the MFA.

Even though it's been almost 9 years since Portal was released, I want to experiment with the mechanic in my own style.
I think there is room for a portal mechanic to work in the game, but not have it be derivative.
 
I started immediately with the portal rendering itself. I was able to get infinite recursion working two days ago by using render textures.  



---

Many people really enjoyed the dimension inversion effect. I think it's definitely going into the game in some form.



However, I still need to work out some other details as discussed in the previous devlog.

What gets insane is the thought of putting a dimension inversion in between recursive portals.



The effect produced is pretty amazing.

However, if you think really hard about this, you'll notice the rendering sequence of dimensions in the screenshot I showed is actually incorrect.
I made this chart to help me visualize how this effect should be rendered.

Oh my god, I just got up to speed with this game. Those colors are just the most gratifying thing. Absolutely stunning.

[Mark Mayers]

Oh my god, I just got up to speed with this game. Those colors are just the most gratifying thing. Absolutely stunning.

Thanks! I spend a lot of time meticulously choosing the colors for each scene, haha. 

[Mark Mayers]

Update 89: 07/14/2016

Since the beginning of this year, I have added and revised a great deal of content.

I think I'm starting to understand what my game 'is.' (If that make sense).  
The game is really starting to come together in terms of identity and direction.

Below is all the content I've added or refined in the last six months of development.

---

THE BLACK HOLE



The black hole is the main ability in Desolus.

The puzzles in Desolus are based around using your black hole to absorb and transfer energy between stars.

---

THE EYE



The eye is used to convey information about the world, including lore and puzzle hints.  
The eye functions similar to the scan visor in Metroid Prime.

---

STARS



Stars are the glowing particle orbs hovering above those black obelisks.  
Players can manipulate energy from stars using their black hole.

To do this, you can absorb energy from an active star (With Left Trigger or Right Mouse).
You can then transfer the energy to an inactive star (With Right Trigger or Left Mouse).

---

PRISMS



To solve a puzzle, the player must activate all of the stars in the level.
When all stars are active, a prism combines the light of the stars and redirects it at a door.

---

LEVEL AND WORLD DOORS



Each puzzle contains a door (sometimes multiple) which teleports you to a new area.
Doors will not activate until a puzzle is solved.

Once every puzzle is solved in a world, their beams are directed at a very large world door.
Entering this door leads you to a new world.

The picture above shows a world door in the center (the big one) and a level door to the left.

---

DIMENSION GATES



The world of Desolus has been fractured into two opposite but symmetrical dimensions.

Objects called dimension gates are used to travel between these two dimensions.
Dimension gates are powered by stars.



Affecting objects in one dimension will affect the same object in the opposite dimension.
However, you can not bring energy between dimensions, and sometimes objects only exist in one dimension.

---

There are many other mechanics for the game which I have been working on, which I'll introduce in future entries!

It's encouraging to see how much progress I've made, even in the last 6 months.

[Mark Mayers]

Update 90: 07/17/2016

Recently I've been working on an alternate set of shaders for the Dark Dimension.

My goals for this were as follows:
-Increase the difference between the two dimensions.
-Improve visibility of objects at distances.
-Make the dark dimension more ethereal.

---

I took a brief survey to ask people on Twitter what they thought about the shader. I asked to choose between A and B.





Most people actually chose B. I asked why, and most people said it was because Shader A clearly has a shader error.
You can see the 'arms' of the obelisk behind the central pyramid.

I realized this was because the shader is transparent, and I forgot to use ZWrite to write to the depth buffer.

I fixed the problem with the shader, and uploaded this picture. People seemed to like it.



---

Now the obelisks are different between dimensions and also look like the energy they hold.

In the light dimension, the obelisks are black. The stars above them hold dark energy.
In the dark dimension, the obelisks are white. The stars above them hold light energy.



The shader is fine, however, it highlights some problems with the mesh.
 
It's easy to tell that the 'arms' in the obelisk are constructed of smaller cubes.
You can see the faces of the cubes inside due to the transparency. This can be fixed by changing the mesh itself.

---

Here was the final picture for the day. I cropped the image with 'The Eye' and it looks pretty cool.



As a bonus, Desolus was also featured in Hardcore Gamer's Screenshot Saturday for this week!!

"Desolus- A first-person puzzler about manipulating darkness and light to open up pathways through the world.  Light isn’t “good” and dark isn’t “bad”, but rather different aspects of energy, and you can activate an inert dark star with energy from a light sun and vice versa.  Light up all the stars of a certain type and the door opens to the next world, although sometimes this involves hopping between light and dark dimensions to get everything properly activated.  It’s a ridiculously beautiful game."

Thanks for including me as part of the article