next »

[Kyle Preston]

Light isn’t “good” and dark isn’t “bad”, but rather different aspects of energy...

Not sure how philosophical this was meant to be, but boy does it put a smile on my face. Every time I come back to this devlog, I get more excited to play this. Your work is inspiring Mark : )

Alright, gonna go stare at this for awhile now I think.

[Mark Mayers]

Light isn’t “good” and dark isn’t “bad”, but rather different aspects of energy...

Not sure how philosophical this was meant to be, but boy does it put a smile on my face. Every time I come back to this devlog, I get more excited to play this. Your work is inspiring Mark : )

Thanks! Yea there's a bit of philosophy backing to this game.

As I mentioned in an earlier devlog, some of the core themes are inversion, dichotomy, and balancing opposing symmetrical halves.

For instance, in each world exists the opposite energy type: light word/dark energy, dark world/light energy.
One can't necessarily exist without the other, and neither are 'good' or 'bad' like that article said.  

This plays out from both a gameplay standpoint, but also a narrative standpoint.

[Mark Mayers]

Update 91: 08/01/2016

Last week I was mostly on 'vacation' as I had a few friends visit me in Boston.
However, before this I spent the weekend writing performance improvements, which worked very well!
 
---

I started off by writing a frustum culling system for all of the particles in Desolus.

For this, I implemented a 'Bounding Box' algorithm from using the shape of the particle system.
I then used TestPlanesAABB with the Main Camera's frustum and the Bounding Box.

This approach determines if an object is on screen or not. When a particle system isn't on screen, it doesn't render.
Pretty simple.

Things get much more complicated however, with an additional culling system I wrote.

---

A performance problem since I've added the dimension gates is that two scenes are essentially rendered at once.

Each object has an identical copy in its other dimension. I then use the stencil buffer to switch between visible objects.
Of course, this ends up being unnecessarily intense to render.

To solve this, I had to write a 'dimension culling system' that only renders objects when they are visible in their appropriate dimension.



This picture shows which objects should render in each dimension when looking through a dimension gate.

I hypothesized how to make this work, and figured I could do something similar to frustum culling with the camera.

The bounding box and TestPlanesAABB approach would work, as before.
However, I would have to use the frustum of the dimension gate instead of the camera for the AABB test.

This image helps visualize this process:



The red represents the view frustum of the camera, and the orange the frustum formed form the dimension gate.
The yellow is the bounding box for the example particle systems.

I needed to find if the 'yellow' exists within the viewpoint of the 'orange.'

I figured out how to generate a partial frustum for the dimension gates with raycasts.
Rays are projected from the camera, in the direction of the world space vector coordinates of the dimension gate's mesh.



In TestPlanesAABB, there is a plane array taken as parameter.
Normally this is the array of planes which represents the camera's frustum. But I need to custom make planes which represent the dimension gate's frustum.

Using the pictures as reference, this would be the planes that represent the orange box.

Unfortunately, I still haven't exactly figured out how to do this.
As of now, I have all the vector coordinates I need to generate these planes.
I just need to solve how to translate an array of vector coordinates to an array of corresponding planes.

For now, I use a simple approach: Do not render objects in other dimensions unless a dimension gate is on the screen.
This is a place holder until I finish what I described above.

---

Despite being unfinished, the culling systems I made show HUGE performance improvements.



With no culling, there is a base frame rate of ~77 frames per second.
Culling objects between dimension bumps this up to 94FPS.
Using both frustum culling and dimension culling, this jumps up to 112FPS!

That's almost a 50% improvement in performance, on average. So I was pretty happy with the results.

[Mark Mayers]

Update 92: 08/02/2016

I've been taking a break from programming, and working more on world redesign and level design.

---



This scene is with the new sky system that works with the dual dimensions. This is the dark dimension version.

This is just a world prototype scene, however; mostly to get the composition and colors right.
Any picture I post with the simple pyramids will be later have full terrain and other assets.

---

I'm estimating that by the end of August I'll have most of the new levels complete.
The Boston Festival of Indie Games is in mid September, so I've been working on lots of new content.

[Mark Mayers]

Update 93: 08/17/2016

The past two weeks I've been primarily working on level design and the creation of a new prototype world.
The world consists of 10 individual levels/areas and encompasses much of the new content. It's meant to be the first world of the game.

Some of the puzzles come directly from older demos, but edited to reflect the new game mechanics (like the dimension inversions).
I've completed the design of all the puzzles although I need to playtest and polish some of the design.

Here's a screenshot of the editor view for the prototype:



It's been about 3 months since I've made any 'real' art for the scenes.
This is because I've been creating content to enhance the game's design, which is more important than visuals anyway.

Last month I wrote about the importance of prototyping, and I've been adhering to that philosophy.

---

Much of the inspiration for designing the world comes from that of the 'Zelda Dungeon' largely due to how the progression works.

Examples of Zelda dungeon design analysis:



As well as:
-Original Zelda Design
-Flow Control

---

Each area is an individual puzzle, but each puzzle also fits into a greater whole which affects progression.
Zelda uses keys, locks, flow control, and most importantly items to affect the progression.

In the case of Desolus, there is a plot twist that occurs with the mechanics of a specific individual puzzle.
This twist affects the rest of the 'dungeon' and contextualizes previously unsolvable obstacles.

There is no true 'dungeon map' in Desolus (I'll leave that to the player) but here's a diagram of the flow progression for the first world.  



The world is divided up into three sections:
-A dual dimension area, which acts as a controlled hub to other puzzles.
-A light dimension area, where puzzles are based around the black hole.
-A dark dimension area, where puzzles are based around a new ability I haven't talked about.

Most puzzles have you traveling between dimensions. However the theme of the two world halves will be very different.

---

An example of a dual dimension area would be the level which comprises both puzzles #3 and #9.

Light dimension version (puzzle number 3).



Dark dimension version (puzzle number 9).



This scene has probably been redone about 20 times, and it's pretty recognizable.
However due to world design shifting around drastically, the scene composition is varying slightly from before.

I plan on increasing the visual differences significantly between the two dimensions.
Currently only the sky, particles, and obelisks are different, next step is rewriting the terrain, tree, and foliage shaders.

I really want to surprise the player the first time he/she travels between dimensions, and part of that is creating a stark visual contrast.

---

[wizardfu]

These dungeons are adding a really intriguing element. Looks fun to play.

[Mark Mayers]

These dungeons are adding a really intriguing element. Looks fun to play.

Thanks! The game lacked an interesting organization of individual puzzles, as progression before was entirely linear.

This gives some depth because there are multiple solutions to puzzles, some which you might not be able to solve until you revisit the area. 
I can also focus on hiding secrets in weird non-essential paths. Perhaps some will lead to additional lore or the buildup to a secret ending! 

[Mark Mayers]

Update 94: 08/20/2016

Recently I have started to integrate more of the non-prototype art back into the game.
I am mostly doing this for levels I consider 'complete' in the new prototype, or those that are unlikely to change.

I mentioned in my previous devlog that I wanted to increase contrast between the two alternate dimensions in Desolus.
Today I started this endeavor by creating an alternate set of tree shaders for the light and dark dimension.

---

Here are a few screenshots:


Light Dimension




Dark Dimension




Both, through a dimension gate.



---

Also today is perhaps special:



Looking at the Desolus folder on my computer, today marks 2 years since I began development on the game.

---

[Mark Mayers]

Update 95: 08/21/2016

I've been working part time on Desolus for two years now.

Counting the hours I've spent (I keep track) it's been 2601 hours actively developing the game.
This is about 65 weeks working a full time job.

Looking at the Unity scene files on my computer, I've made about ~222+ levels.
Only 13 are in the current build, levels I consider good enough for the 'final' game.

Perfectionism is definitely a real problem for me, but my skills as a designer have improved exponentially since I began development.  
None of that time I consider 'wasted' but more steps in a greater journey.

When I think of the knowledge I've gained, the people I've met, and the experiences I've had, I don't think I would have spent the time on anything else.  

---

A brief look at the history of the game over the last two years.

August 2014: The very first part of the game I made was the title screen.
People seemed to enjoy this art style, so I slowly improved it over the game's life time.

However the game itself has changed dramatically since I first began.



What I had during August 2014 was mostly an experimentation with Unity. There wasn't much of a game.
I wanted to make a game around the concept of a black hole and gravitational attraction.

The mechanic demo I had at the time involved a black hole made of particles, which you could shoot 'missiles' into with a 'gun.'
You could then redirect these projectiles with the black hole for increased force.

This concept would actually later be significantly revised to be the core of the game.
However, I decided to remove the projectile elements, and only focus on the gravitational attraction aspect.



---

January 2015: The first real gameplay started as a completely different concept than it is now.
 
Desolus was about using the gravity of a black hole to attract 'nodes' which would activate mechanisms.
Using the energy of these nodes, the player could traverse various platforming puzzles.

People seemed to enjoy the game, but my design skills were poor.
I wanted to make a puzzle game, but instead came up with a difficult and obtuse first person shooter.



---

May 2015: Based on feedback from players and conversations with more experienced developers, I decided to change the core mechanic of the game.
Puzzles were then based around absorbing and transferring energy between stars using a black hole.

This video was my submission to the Boston Festival of Indie Games, as well as IndieCade.
I was accepted into BFIG as part of the showcase (previously I was denied), and had the chance to show the game at IndieCade.





---

November 2015: By November I removed most of the execution based elements of the game.
Desolus started turning into a proper puzzle game. This period was mostly a refinement of my May 2015 design.

However the game still lacked progression and a 'solution state' for puzzles, and was very confusing to some.

I showed the game at several festivals around this time period, including BFIG and IndieCade.
This helped me refine my design further based on the feedback I received.





---

January 2016: By January the game started to become a 'pure puzzle game' and closer to what I originally wanted for my design.
I decided to remove all timing elements from the game.

The game by this time started to have a proper progression for each individual level, with a tangible objective.

To solve an individual puzzle a player must light all of the 'stars' in an environment. This opens a door to the next area.
All of the puzzles I made around this time period were based around energy transfer and line of sight.



---

April 2016: April was an exciting time period, as I just recently showed at both MAGFest and PAX East.

In April the core mechanics and puzzles based around energy transfer were mostly complete.
My design started to become solid, and people seemed to enjoy the game.

However, I still felt the game lacked that special 'something' and went on a bit of soul searching.



---

June 2016: In the beginning of June I created the dimension inversion mechanic, where you travel between two opposite worlds.

These inversions are powered by stars, which gives a greater purpose to the energy transfer puzzles than 'activate all of them.'
This extended my original vision for the game, and has led to a lot of exciting new content that I've been working on the last few months.

I feel the dimension inversions were the missing piece of the game. I spent a long time looking for that idea.
There's a lot of creative potential which I am slowly discovering about my own game.



---

What will Desolus become one day? I don't know yet.

Regardless if this game is a commercial failure or not, I can at least say I pursued something I believe in.



---

[DireLogomachist]

Awesome work so far Mark! I thought this game looked fantastic the moment I saw it and no matter the changes to the mechanics it will turn out awesome. Everything worth making takes time and effort, and you've put in plenty of both.

Can't wait to see it released! Do you have a timeline on that?

[Mark Mayers]

Awesome work so far Mark! I thought this game looked fantastic the moment I saw it and no matter the changes to the mechanics it will turn out awesome. Everything worth making takes time and effort, and you've put in plenty of both.

Can't wait to see it released! Do you have a timeline on that?

Thank you! That means a lot!

My original target for release date was January 2017, but there is absolutely no way I would make that date.

Part of it is because I work a second job at MIT, although I switched to part time in January of this year.
I'm looking at funding opportunities right now so I can afford to commit more time to the game.

However, I work on Desolus right now at a steady 25-40 hours per week.
I'm fortunate to even be in that position, most indie developers don't get as much time.

I'm just going to say 'eventually' or 'when it's done' for release until I know for sure. 

[jamesprimate]

 

these last updates are looking amazing

[Mark Mayers]

these last updates are looking amazing

Thanks mang 

Also random, but it's been so long since I've made 'non-prototype' art, I forgot what the game actually looks like.
This is from the PAX East demo from April, I just spent a few hours replaying all my previous demos.

[Mark Mayers]

Update 96: 09/12/2016

BOSTON FESTIVAL OF INDIE GAMES 2016

Saturday was the Boston Festival of Indie Games!
I exhibited the game last year as part of the Digital Showcase, this was my second year at the festival.

Since the end of May I've been preparing a demo for this event, with all the new gameplay mechanics like the alternate dimensions.
I'm happy to say it turned out very well!

---



Over the past several conventions I've learned it's best to only bring one computer, so I went with a minimalist setup this year.

Rather than having to frantically set up and manage multiple computers, I could direct my efforts on one.
I would rather have quality interactions with those who play the game rather than a larger quantity.

Retention rate for the demo was fantastic, most people played for a good amount of time and a constant stream of people filed through.

Several people voted Desolus as their showcase favorite, which is kind of funny since I wasn't in the showcase this year nor eligible for awards.
You can't be part of the Digital Showcase two years in a row, so I bought a booth instead.



A few people who played the game at last year's BFIG remarked the game has come a long way since last year.
It's reassuring the new mechanics I've made are interesting and my design is improving.

---

A few images from the Boston Festival of Indie Games Demo:



The first dimension gate, allowing you to travel between the light and dark worlds.



One of the light dimension starting areas, at an ocean cliff sunset.



The first level, revisited in the dark dimension. The dark dimension has an aurora in the sky.

---

As mentioned in my previous devlog, much of development has been iterating on the game's design and massively revising content.
This is the first demo I've shown where I think the core design has started to reach its potential.

With the core structure of the game ~almost~ in place, I can now polish and continue developing what I have rather than throw away ideas.
The game still needs a LOT of work, but I feel I'm making definite progress.

This picture was taken at the festival:



When you work on Desolus for 2 years and the core game starts to come together.

---

[Mark Mayers]

Update 97: 09/16/2016

Recently I've been working on creating a multi-dimensional 'fog' system to diversify the visuals between dimensions.

---

One dimension is orange and another blue, essentially combining the art from two areas I've made in the past but in separate dimensions.
These are the same areas between the light/dark dimensions, although this is using the old render fog system.





The problem is since each dimension renders to a unique stencil buffer value, I had to rewrite the fog system to work with the stencil buffer.
However, since fog is a built in Unity function in the render settings, this isn't really easy to modify.

Instead, I decided to rewrite the fog as an image effect using a depth texture.
This allows me to create my own custom fog shader that I can tweak however I want.

---

One weird idiosyncrasy with writing post-process effects in Unity, is by default you don't have access to the stencil buffer during OnRenderImage.
This is inconvenient, as in order for the fog effect to work with dimensions I need the depth buffer and the stencil buffer.

After a bit of research, I determined a way that I could use the stencil buffer during post-process.



The key is saving a RenderTexure buffer in a variable, during OnRenderImage.
You MUST set the depth bit to 24, as this gives you access to both the depth and stencil buffers. By default this is disabled.

Any image effect using Graphics.Blit can be applied to the buffer.
Normally the Blit would be applied the camera itself, or the 'destination' in OnRenderImage.
Since we are using a RenderTexture intermediary buffer, we want to apply effects to this instead.

You can then set the render target of the camera to this new buffered RenderTexture, which will render the frame with the post-process effects applied.

Don't forget to release the temporary RenderTexture when rendering is finished!
Otherwise this will cause massive memory leaks and cause your game to crash within seconds.
Each RenderTexture is about ~20mb, and is generated once per frame. You'll saturate a few Gigabytes of VRAM within a few seconds

---

The fog shaders still need some work to be perfect with the alternate dimensions.
I also need to rewrite my water system (which I needed to do anyway for performance) to work with the fog.

However, the results are pretty interesting so far.



From a gameplay perspective I think this gives the dimensions the visual diversity they needed.

---

[Mark Mayers]

Update 98: 09/17/2016

I use SpeedTree for most of my foliage, it's a fantastic program.

You can see an example of the trees in the Desolus title screen teaser:




The wind animations for SpeedTree are done with vertex shaders, which gives some pretty cool results.
However, my new fog system produced a bug with rendering where the SpeedTree vertex animations weren't working correctly.

The new fog and the animations for SpeedTree were rendering separately, this created a bizarre split image effect below:



For a depth based image effect like the fog, during Forward Rendering it's hard to reproduce these vertex animations for a post-process effect.

I had to do some research for how to make the new fog work correctly with SpeedTree; starting with how built in fog is rendered.
This seems to be the definitive answer, based on a post I found:



It seems that as of Unity 5.0, fog is automatically added to shaders during compile time.
Since I don't have access to editing the render fog shader itself, I had to think of an alternate way to render fog for SpeedTree.

I decided to take the easy way out.

Since SpeedTree renders correctly using the normal fog, I decided to keep the normal fog SPECIFICALLY for SpeedTree objects.
This means that every other object in the game renders with the alternate fog system I wrote.

You can turn off Unity render fog by writing #pragma nofog for specific shaders.

---

The SpeedTree assets render with the old fog system, it's indistinguishable from the new system and blends perfectly.



After all of this was done, I integrated the new fog into my Procedural Sky system.
For example, the following parameters produce all the lighting/shading in the image above:



---

[Mark Mayers]

Update 99: 09/28/2016

Today I interviewed with Jacob Wood from Indie Hangover, which turned out very well.  

You can watch the interview here:





I realized I haven't posted any real footage of the game online in almost a year!
The interview does a good comparison of the current game and the alpha from last November.

---

On Monday I presented Desolus as part of HUBWeek, which was an interesting experience.

I showed the game in VR to many people who normally do not play video games.
However, the design of the game seemed to hold up well and reception was positive.

There was a great write up on their website about the game:



---

Recently I've been integrating the HTC Vive into the game.
This has had some challenges which I will talk about in a future devlog. However, the platform looks very promising.

I've also been working on an experimental new visual mechanic, which is an extension of the dimension inversions.



The black and white obelisks are the same object, reflected with the use of vertex shaders.

More on this later!

---

[jamesprimate]

[Mark Mayers]

Update 100: 10/04/2016

I've decided to investigate some alternate visualization techniques for the dimension inversions.

After some recent playtests I realized it's a bit ambiguous which objects exist in what dimensions.
Previously, I would simply have objects flash to indicate whether or not they 'exist' in a dimension.
However, this is a bit visually ambiguous and doesn't properly communicate the idea.

After a bit of experimentation, I came up with the idea of rendering alternate dimensions as an 'inverted' or upside down world.

---

Last time I posted this picture, which is largely a proof of concept.



The black and white obelisk are the same object, with an inversion and offset to the vertices applied with a shader.

Inverting the world over the horizon gives an effect like this. The two alternate worlds exist as a reflection of each other.
The same technique the dimension gates use is applied to the horizon, with the objects in the alternate dimension appearing above.



This visualization mechanic is still in prototype stages, and it needs a LOT of work.
I think this opens up lots of interesting design opportunities, and also helps the player visualize the alternate dimensions.

This effect will likely be a finite horizon effect, meaning the entire game will not be like this.
However, certain sections of the world relevant to navigation or puzzle design will have this visualization.

I will largely be working on this effect for the next week or two.   

[Mark Mayers]

Update 101: 10/19/2016

Last week I was over at Steam Dev Days in Seattle!



Steam Dev Days is a conference hosted by Valve, consisting of talks, panels, and networking events for Steam developers.

This year a primary focus was Virtual Reality, as Valve seems to be doubling down on VR content for 2016.
However, there were a variety of panels that I attended with valuable information.

---



The Keynote for the event was given by a few Valve developers and Tim Sweeney.

Sweeney talked about 'the future of virtual reality' and mentioned where VR could take us in the next few decades.
Tim talked about the history of video games and how Virtual Reality might be the 'final' creative medium.

He stated the importance of PC virtual reality, and that tech will eventually trickle down to mobile or portable platforms.
He's putting his faith into PC VR instead of mobile for now, because design evolution for cutting edge PC VR is important to push the rest of the industry.

Looking into the far future, Sweeney mentioned a 'VR Metaverse' which would essentially be a version of the internet in VR, or an alternate reality for everyone.
Think the Matrix but a democratic and open version to everyone where we don't have robot overlords.

---



Steam 101 consisted of introduction advice to publishing on the Steam platform, including how to set up your store page.

"Learn the basics of how to ship your game on Steam, and get tips to make the most of your launch.
This talk is targeted at newer partners who are shipping their first or second game on Steam."

Steam 201 was an advice panel from successful developers that were interviewed through Valve over email.

"This talk is designed to provide some more advanced business guidance.
It will highlight the Dos and Don'ts of launching a game on Steam, informed by the successes, failures, and feedback of experienced developers."

The key advice boiled down to a few points:

#1: Be honest with your work
  -Game design is a conversation with players on what you find interesting. Honesty can be seen through art.
#2: Release timing is essential
  -Don't release within +- 4 weeks of a major release or a Steam sale.
#3: Be part of your community
  -Actively build a community around your game during and after development. Your fans are your greatest asset.
#4: Try not to be a slave to a timeline
  -Never launch a game that is 'good enough.'
  -Game design is an endurance race.
  -You don't get a second chance to make a first impression
#5: Build the game you can afford
  -Adding an additional feature is like adding meters to a marathon
#6: Make your game obviously fun
  -Duh
#7: The whole equals the sum of its parts
  -Treat every part of business as the most important part.
  -Every small aspect of your game is important.

---



The Publisher Panel was an in-person panel consisting of representatives from Devolver, Sega, Digitalmindsoft, and an experienced video game attorney.

"How should you choose whether or not to work with a publisher? How do you know if a given publisher is right for you?
What are the tradeoffs and benefits of working with a publisher, and what does a healthy developer-publisher relationship look like?
What are things to watch out for in a publishing contract?
Get advice and suggestions about these questions and more from our panel, with expert perspectives from development, publishing, and legal."

A few interesting points brought up in the talk. (These are paraphrases from memory, not exact quotes).

-Nigel Lowrie of Devolver: I wake up in cold sweats at night thinking if I would have passed up Stardew Valley.
Nigel and a few other publishers mentioned that success is very difficult to predict.
Games like Stardew Valley are ostensibly simplistic, and might not seem to have an immediate target market or impact.
However, it's important as a publisher to be open to games that might not fit your 'brand' and create a diverse portfolio.

-Tom Buscaglia, Game Attorney: If a publisher wants intellectual property rights and control, you should find a different publisher.
Tom talked about the importance of retaining IP rights when signing a contract.
In almost every case he's mentioned, when a publisher ends up messing with the creative design of a game, the game ends up suffering because of it.
It's essential to maintain absolute creative control when making a game, regardless if you're AAA or Indie.

---



The Lab Panel was a retrospective going into some challenges and lessons learned in designing The Lab.

"Valve released its first VR game in 2016, a free set of minigames and experiences called The Lab.
In this panel, Valve developers and game designers will discuss developing, testing and shipping The Lab."

This panel was interesting because it talked about a few of Valve's design struggles when creating the lab.

-Valve didn't have most of the hardware until near the end of development.
Since the Vive was experimental and these were some of the first games for VR, Valve had to organically discover things along the way.
The team didn't even have the hand controllers for the Vive until later in development.

-Valve had difficulty unifying The Lab into a cohesive whole.
The minigames were set in the Aperture universe, which fit into the whole experimentation aspects of these minigames.
The 'robot dog' and Valve stick figure characters also helped unified the game, and give aspects of commonality.
Every object in each minigame had to interact with each other in the 'hub world'

-Design of each minigame had to show off the strengths of VR.
All of the control systems had to feel natural and intuitive, not needing instruction.
Each object was based off of a real life object (like bow and arrow) but abstracted to be a better version of real life.
Xortex (the RC Copter game) was almost pulled entirely because it relied off of a more traditional control system before revision with the Vive hand controllers.


---




VR Developer Panel

"This panel will focus on lessons learned while building and shipping successful virtual reality projects.
The VR space is still very new, but many developers are already reaching lots of happy customers, and turning a profit in the process.
Hear from some of those developers on the opportunities and challenges of the VR marketplace."

This panel was the last in the conference, but had some insights into the success from early VR games.

-Everyone talked about the importance of sharing developments in VR to create a positive ecosystem. Don't be competitive, be collaborative.
-Developers in general talked about the importance of intuitive VR controls that are also comfortable for the user.
-Try to avoid 'buttons' in VR and instead focus on natural interaction and human movement.
-Sarah Northway (Fantastic Contraption) mentioned people seemed to take joy in simple actions in VR, perhaps outside the main game itself. 


---

Perks of the event also included free breakfast, catered snacks, open bar, and some cool free tech.



DON'T TALK TO ME OR MY SON EVER AGAIN

---

Overall I'm very glad I went!