next »

[Mark Mayers]

I was pleasantly surprised when #indiedev Mark Mayer started his Playcrafting Lightning Talk and it was on the use of the Golden Ratio when dynamically generating the art in his game Desolus, so I whipped out the iPhone and quickly record.







If you can forgive the bad audio and video quality, it is a fascinating presentation.

Ah! I'm really glad this was recorded, thank you!
It's strange to see yourself make a presentation, ha.

The beginning two minutes of the presentation was me pitching what the game is.

You see can most of the slide pictures in high quality throughout my DevLog!

[Mark Mayers]

Update 34: 05/03/2015

This week, I decided to redesign the core mechanic.
Over the past few months I've noticed that gameplay is way too confusing, and puzzles lack true depth.
So, I've decided to suck it up and redo the majority of what I have mechanically so far.

I know anyone reading this devlog probably thinks I'm crazy right now, but I think it will be better long term.

NOTE: 2020 June 27th.
This sent me on an existential journey which lasted several years, whoops.
However, I think in the end it was worth it.

---

Before, you would shoot your singularity at 'nodes' (the blue/red particle spheres) and it would immediately activate an ability or object.

The puzzle design was a tad shallow; it was mostly based on angles and placement of the black hole.

I also didn't feel I was exploring the theme of gravitational attraction enough.

The new mechanic redesign is based around redirecting particles.

You use your black hole (singularity) to absorb particles from miniature 'stars.'
When the singularity has absorbed enough particles, an ability activates.

Particles absorbed by black holes are chained together as a 'stream.'
When a black hole explodes after a short time, particles are transferred to another active black hole.

The stream is broken when all black holes have collapsed. Particles are then transferred back to the original star.

---

This gif shows a particle stream with a single black hole, which absorbs energy from a star.



When the black hole has absorbed enough energy, a bridge activates, which you can walk across.

Most of this might be visually ambiguous; I realize there is a LOT going on at once.
I'm going to make a few tweaks; I'll post some gifs of 'chaining' black holes together sometime soon.

--------

It's difficult working with an experimental mechanic.
This is MORE confusing than before, but that means I need to make better tutorial levels.

[Mark Mayers]

Update 34.5: 05/03/2015

Consider this as an addendum to the previous update.

I have a gif that better conveys the way the game works now (partly because I just implemented this about 20 minutes ago, ha).

I guess I can summarize this new core mechanic as "Transfer energy between stars using black holes."

The previous gif was transferring star energy to a node (which then can be transferred to another star using a second black hole).

This gif is transferring energy directly from one star to another. I also changed the visuals slightly to make things more visible.



When all of the energy is transferred, that star now becomes 'active' and the previous star dies.
The effects of that star are then permanent, until you transfer the energy to another star.

In this case, blue stars create particles that act as bridges.

I have some exciting levels planned with this; it changes the game in a great way!!

[Mark Mayers]

Update 35: 05/06/2015

It's been kind of a slow few days, I've been mostly refining ideas.

In regards to actual content, I made some minor improvements to the title screen to reflect the rest of the game.

There is now a day/night cycle that syncs with the title screen music.
It turns from night to day slowly with the key change in the song (minor to major).
The sun rises right during the major key transition.



---

I am actually re-defining the core mechanic (AGAIN) but continuing down the path I was going.

I think I may no longer have the singularity as a projectile.
It almost doesn't make sense from a design perspective.

Good mechanics affect the PLAYER and the world, not just the world.
In a sense, the singularity was the focus and the player irrelevant.

Here's a preview gif of how the singularity mechanic might work now:



Instead of a projectile, the singularity is stored in the player's hand.

The way I'm thinking of the mechanic is that the singularity acts like a 'battery' of energy.
While energy is stored, certain abilities activate (like the jump/speed boost abilities).
The energy can also be redirected as a massive projectile (the bombard mechanic).

The player would have to 'tag' an energy source first though by firing another projectile (or simply looking at it).
This is just showing what the effect of acquiring energy could look like.

---

In other news I now have an Oculus Rift and I will be making Desolus with VR support!!
I'm super excited

I want to get the mechanics down first, however.

[Mark Mayers]

Update 36: 05/10/2015

I spent today integrating Oculus Rift support for Desolus.

Holy shit.

This is possibly the coolest experience I've ever had in video games.

---



---

I started out with some difficulty in getting the Rift set up.

First off, I had some operating system incompatibilities with Windows 7, so I had to fix that issue.
Second, I couldn't actually get anything to render, even though the Rift was being recognized.

After struggling for a bit, I managed to get the demo scene working correctly.
The trick was to make sure the Rift was rendering in Extended Mode, as if it was another monitor.

The next battle was with Unity. I spent about an hour with only a black screen.
I then realized image effects applied to the camera made the scene not render.

It turns out, turning off anti-aliasing and modifying my post-processing scripts helped.
There's also a setting called 'eye texture anti-aliasing' in the Oculus controller prefab which needs to be set to 1, if not the scene would not render.

---

After I got everything rendering correctly, it was time to mess with my character controller.

With a Rift, it's best to play with a 360 controller. This is something I found out.

Some first person games will make you nauseous in VR.
I think I found an interesting way to circumvent this.

The secret is the controls, and only applying gradual movement and no acceleration.

The controls I implemented:
-Left stick controls movement/strafe
-Right stick controls horizontal rotation ONLY, at a slow speed.
-Head movement is actually how you aim.

Your head rotation determines where projectiles are shot.
In the future, I would like to do eye tracking for aim.
However, this control scheme is fine for now.

---

I think I might release a playable teaser for use with the Oculus Rift, consisting of the title screen + three environments.
I still need to work out some kinks before I make anything public.

[Mark Mayers]

Update 37: 05/18/2015

It's been a super busy week in development for me, I haven't posted in a while.

No pictures with this post; I have a video instead

---

-NEW CORE MECHANICS-

I've changed the mechanics of the game dramatically... but definitely for the better.

I can summarize it in a single sentence:
"Explore a dreamlike environment using black holes to absorb energy from stars."

That's what I have on my Twitter now, cool.





It's my submission for the Boston Festival of Indie games, which I'm really excited for! (Submissions were due today)

I put it as 'unlisted' on YouTube as it's not fit for consumer/press level release.
I figured I would make it semi-public to those interested in the game's development.

---

-LOGIC BEHIND CHANGE-

So why did I change the mechanics?

It's not necessarily a total change; it's still the same game.
However, I felt the previous iterations of the mechanics lacked depth.

What did I actually change?

-The singularity is no longer projectile, it's in your hand
-Star and energy transfer mechanic is entirely new
-Added the ability/weapon mechanic for each energy source
-No more turrets or enemies, the environment is the obstacle

Will I change the mechanics around more?

Yea, indubitably a game will always need revision.

However, I think this is the ending set of a series of high-fidelity prototypes.
The CORE is in place, and it's a mechanic I can build on and increasingly improve.

Strangely enough, this is the closest to my original vision that I've come to.
Even if you look at the destabilizer post of the mechanic I killed... it's actually back in this new form.

All of these elements were floating in my head, and I couldn't piece them together until recently.

---

-PLAYTESTING NOTES-

I had an excellent playtesting session with many local indies today.
It was great, I got some super valuable feedback from everyone.

Critical takeaways:
-The game is extremely visually ambiguous (although people think it looks great)
-Level design for presenting new mechanics is not well fleshed out
-People like the older level design better, but think the new mechanic is more *fun* (most critical word in describing a game)

What I'll be working on:
-Work on visual communication, that is the new main focus
-Present information gradually in level design to compliment visual communication
-Use aesthetics of old well polished levels, with new mechanics

---

I'm really excited for the future of this game.

Elements are finally starting to come together for me in the realm of gameplay.

There is still a TON of work left for me to do on this game.
However, looking back to a year ago I had nothing! All I had was a dream.

[oldblood]

Count me in if you need any help with VR testing...

[COOLIO5676]

As a lover of flashy particles effects, I am thoroughly tickled.

Very ambitious for a solo effort but you're making it happen! 

[Mark Mayers]

Count me in if you need any help with VR testing...

Yea! This is all experimental, so playtesting is definitely imperative.
I bring this game to as many expos/meetups as I can, if you happen to be in the area check it out

I may send out builds for feedback to other developers too, in the future.

As a lover of flashy particles effects, I am thoroughly tickled.

Very ambitious for a solo effort but you're making it happen! 

It's 'fancy particle effects the game' when you drill down into it.
All of what would be weapons or enemies are particles, which works for my skill set.

There aren't any 'modeled' art assets in the game besides the terrain, but I use post-processing to simulate erosion/etc. and paint it algorithmically.

I've never touched a 3D modeling program, if you don't include Unity.
I have used Photoshop for the textures though, but my skills are lacking and all the 2D art is placeholder.

I probably (definitely?) bit off more than I can chew. I've gotten this far at least, ha.

[Mark Mayers]

Update 38: 05/28/2015

I've been working on Desolus for quite a lot in the past week, although I've been rather sick the past few days.
I've also spent some time *playing* video games for once. Weird concept, right?

This will be a rather short entry.
My next one will be about the different weapon and star types with the revised mechanics.

---

These pictures are of the first two areas of World 1, although very much a work in progress.



I spent a dumb amount of time redoing the majority of the first few areas.
Every month I make a huge evolution and redo much of the first zones.



This might be my last terrain iteration for a while, although I'll definitely make tweaks from here on.
I've spent so many hours making terrain I'm tired of it, ha.

---

I'm still shooting for IndieCade and am doing the late submission.
I'm going to put some finishing touches on these sample levels and submit!

[Bluebutton]

Love the art-style. Based on the player feedback you got, what didn't they like about the "new" level design?

[Mark Mayers]

Love the art-style. Based on the player feedback you got, what didn't they like about the "new" level design?

Before, the demo was the 'tutorial' which is fine; the whole game is really a tutorial.
However, it was very long (45+ minutes) for a demo presented at an expo-like setting.
This demo I compressed the new mechanics into only a few levels.

My methodology was, "Well, this is a demo, let's just throw people into the game."

Imagine if in Portal you started out at the GLaDOS fight, without introduction of what Portals even are.
That's what I did (essentially) and that was the primary problem.

It's not necessarily that the levels were bad but they didn't properly introduce mechanics.
The later levels in the demo were also 'developer hard' as my friend put it.
Timing was too exact, elements weren't well communicated enough, checkpoints weren't fair etc.

I usually got comments like, "This is fun now that I understand what's going on."
However, those comments only came from people who mentally persisted for the 10+ minutes on the second level via trial and error.
So ironically, the shortened demo ended up being just as long due to esoteric design.

I may run into 'problems' for expos where people play for 30+ minutes (which has been the previous case).
A few developer friends said I should kick people off, but would I hate doing that; it's counter-intuitive and is in poor taste.

Hypothetically, if I go into an expo like PAX East with a long demo, not many people will get to play.
However, I get a deeper dive into what people actually think about the game.
People liking your game is not a problem.

[Mark Mayers]

Update 39: 05/31/2015

I submitted to IndieCade!!!

This was the result of a weekend of hard work.

---

A major victory:

I managed to increase overall framerate by about 50%!!

I massively optimized Desolus this weekend.
There were three major components that were performance hogs in particular.

-The water is *extremely* expensive.
It essentially doubles the draw calls of the scene, as it's a near 1:1 reflection of the game world.

Something (stupid) that I did was have lighting affect the water.
Every pixel light and directional light in the scene would cause the water to redraw itself.
It would also occasionally cause weird visual glitches with textures.

So... I disabled the lighting on water, and have it as a constant ambient lighting instead.
This was a massive performance increase, and it looks better visually as well.

-There was almost no garbage collection with procedural geometry.
Most of the game objects in Desolus are created procedurally (the pyramids, the 'tentacles' etc).
I use a fractal algorithm to do this, where I combine around ~2000 GameObject primitives into a single mesh.

What I realized I forgot to do, was clean up empty game objects after the combination process finished.
This resulted in *thousands* of extra GameObjects per scene, which is a huge memory overhead.

-The black hole shader caused a big memory leak.
I was calling 'new Material(shader)' during OnRenderImage() ..... DO NOT DO THIS, EVER.
It creates a copy of the GameObject and corresponding material FOR EVERY FRAME.
The result is 100k+ leaked GameObjects per scene, after you play for a while.

I don't know how I never found this, but it's fixed now

---

Another huge victory:

Desolus now has full Oculus Rift support!!!!

The entire IndieCade demo can be played in the Rift.
I am super excited and it's something I just managed to pull off today.

All you have to do is hit the 'Oculus' setting in the launcher and it just works

---

Here are some screenshots from the IndieCade demo.
I kept a lot of the old areas, but slightly changed them with the new mechanics.

The day/night cycle and the water is particularly striking. Here are screenshots of both day and night:






It's really a world you can lose yourself in, especially in VR. I feel it's like a lucid dream I've created.

---

IndieCade is super competitive this year.
I was around entry ~4000, I'm guessing there's around six thousand entries?
I have better odds of getting into Harvard than IndieCade

I think I have a chance, I *hope* I have a chance.
Regardless, even if I don't make it in I would love to go and check out all the cool games!

[jamesprimate]

ahh, looks gorgeous! good luck 

[Mark Mayers]

ahh, looks gorgeous! good luck 

Thanks James 
I heard you and Joar submitted Rain World, so I hope to see you there!

I think I'm definitely going to go regardless (submission gives you a 'free' ticket?).
During my small town East Coast upbringing, I've never been to California.

[Bluebutton]

Looking absolutely beautiful!

[Mark Mayers]

Update 40: 06/08/2015

Looking absolutely beautiful!

Thanks

---

I took a brief vacation to the beach this weekend, and I haven't been at a computer in a few days.

There isn't a whole lot new, so instead I'll do a 'reverse post' of things I've done in the past for Desolus.

This is mostly a technical post.
I normally gloss over most of the technical details in my DevLog.
If you're a programmer you might find this interesting, although this is for Unity in particular.

---

WARNING, VERY OLD SCREENSHOTS AHEAD
Disregard the crappy default Unity assets, this was when I first started

I talked previously about how I generate objects procedurally.
This entry is a high-level overview of my algorithm, and about an interesting glitch that I encountered a long time ago.

I had a problem with mesh-deformation and corruption. It was rather extreme!
I took this picture probably March 2014, when I first started experimenting with Unity.
I saved it because it was so bizarre I found it hilarious.



I was working on trying to generate fractal trees and failed miserably.
I later perfected the algorithm (and use it in game). There are no trees, but I use it for the other objects.

This is what end result of this algorithm was:



---

To generate the fractals, I used an algorithm which recursively clones each fractal iteration from its parent GameObject.
A transformation function is applied which changes the size, rotation, and position, of the child object.

The initial parent object, or 'stump' of the tree is a cylinder. In-game I use cubes.

I place the GameObject's position on instantiation relative to the parent's Transform.Position.Forward (as a Vector3) and rotation using Quaternion.Euler(x,y,z) (because ugh quaternions).

That visual glitch comes from recursively copying the parent's transform and then applying transform translations to the parent.
If you have a recursive parent/child transform structure, a simple change in size/rotation could *massively* affect objects further 'down' the fractal tree.
I fixed it by avoiding applying any type of mutation to parent transforms.

In retrospect, I should have stored the child GameObject data in an ArrayList, and combined/cleaned up later vs. doing the parent approach.

After generation, I combine the GameObjects.

---

The second part of this algorithm is a mesh merging function.
This reduces draw calls, material count, and GameObjects in scene.

I made a post a long time ago with this code.

A high level overview is that the code takes the meshes from each child game object, and combines them into a single mesh.

In the actual mesh merging function itself, I had problems in converting world transforms to local transforms (as a vector).
If you look at the code, I set the mesh local position to a Vector3.zero, apply the function, and reset the position to avoid corruption.

Unity's mesh merging function got 'confused' for lack of a better word, when I did not zero out the local position of an object first.

I don't have a picture left-over, but the result was transparent 'ghost' meshes that hovered in the sky.
Spooky.

---

All of the 'tentacle' and Desolus objects are generated with a revised version of this algorithm.
I can type in a few numbers as parameters, and infinitely generate permutations of objects.

---

Anyway, next focus for development is improving visual communication for the game.
It's an area the game has always been weak on (new players often can't really tell what's going).

My brain has been regenerated significantly from even a brief vacation and some sun, so I feel good

[gimymblert]

yup

[Mark Mayers]

yup

I'm assuming you're talking about the money = time/sanity/sleep clause, ha.
There's an interesting website about dev costs for games.



It's somewhat unsettling, but that's a realistic figure.

If I paid myself $40/hr for ~3000 hours of work, it would be about $120k.
Throw an extra $15k in there for additional sound design, contracting professional art assets, music, etc.
Conventions/marketing/legal/localization expenses come out to an extra $15k, however.

So $150,000, or 3 years unpaid and alone.

---

And if we're talking about an award winning game here...



Let's pretend that extra million costs you a large chunk of sanity instead of time/money.

Fun stuff

[gimymblert]

yup