Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411279 Posts in 69323 Topics- by 58380 Members - Latest Member: bob1029

March 28, 2024, 01:31:26 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsDesolus: A Surreal First Person Puzzle Game
Pages: 1 ... 4 5 [6] 7 8 ... 26
Print
Author Topic: Desolus: A Surreal First Person Puzzle Game  (Read 109045 times)
Mark Mayers
Level 10
*****



View Profile WWW
« Reply #100 on: June 10, 2015, 08:14:08 PM »

Update 41: 06/10/2015

I spent today working on a dynamic crosshair.

---

Through playtesting, I decided to give in and give some sort of crosshair, since people were having difficulty playing without one.

You can of course, still turn it off, which is how I prefer to play.

The crosshair does more than aim, however.
It has a few states, which signify different things.


-Normal
This has the standard function of a crosshair, it points where you're aiming.

-Relevant Object
When you're pointing at an object that can be interacted with, the crosshair blinks.

-Singularity Active
When the singularity is active, the crosshair dilates and spins.

-Singularity Unstable
When the singularity is unstable, the crosshair blinks increasingly rapidly.

Here's a gif to illustrate this concept:



---

I implemented this by using a basic state machine.

The actual crosshair itself is a particle effect, which is placed at the center of the screen.
It sits away from the player in 3D space.

I apply different 'force' functions with relative spin to the particles for the different states.
The blinking I handle with an on/off switch that is timed in the code.

---

One of my main goals in the next few weeks is to dramatically increase visual communication and reduce ambiguity of the game mechanics.
At this point, I feel I have the *right* mechanics, based off of feedback.

However, I need to better communicate with the player, and still maintain the no text/explicit tutorial philosophy.
It's especially challenging because I'm dealing with abstract concepts and mechanics.

---

June may be a slow month in development for me.
I'm taking off from work (and also the game) for a week for my birthday.
I'm going to huge music festival, which should be great Smiley I've been for the last 3 years.

This leaves time for ideas to sit in my brain, and allow me to recharge after crunching last month.
« Last Edit: June 27, 2020, 10:07:48 PM by Mark Mayers » Logged

Desolus Twitter: @DesolusDev Website: http://www.desolus.com DevLog: On TIG!
Mark Mayers
Level 10
*****



View Profile WWW
« Reply #101 on: June 15, 2015, 07:39:43 AM »

Update 42: 06/15/2015

This weekend I worked on more of the mountain environment, 'Ash Peak.'
I'm also going to talk about how The Legend of Zelda influences my design.

---

I transition mindset frequently between 'micro-level' (ex. mechanics, actions, player interaction, etc.) and 'macro-level' (ex. level design, level layout, world theme, etc.).
This is usually to keep my brain refreshed.

I spent a lot of time recently on the macro perspective, after spending so long tuning details of the mechanics.
I've decided to go with more of a Zelda-like Design recently (which was always an influential factor, really).

What do I mean by this?
The Zelda dungeon is a series of puzzles that must be solved in a somewhat-linear progression, or 'critical path.'
Each Zelda dungeon is based around a mechanic, or item.

In order to advance in a Zelda dungeon, one must acquire this new item by demonstrating mastery of previous mechanics.
Acquiring the new item hidden in the dungeon continues the critical path.

This is the 'macro-level core loop' of the Legend of Zelda.

Desolus is also designed in this fashion.
Each energy source in Desolus gives you a unique ability, and is essentially a 'Zelda item.'

I'm designing levels to be pseudo-open world, really in the same way as a Metroid game.
However, each world subsection is a 'dungeon' of sorts.

Every area is based around a new set of abilities/mechanics you must master.

---

With that in mind, this is the second dungeon I've been working on.

A placeholder name of the area is 'Ash Peak.'

Here are two work in progress screenshots:



The world entrance, establishing the theme.
The world has about a 80% day, 20% night cycle; this is at night.



The first 'room' of the dungeon, introducing a new mechanic (which I will go into detail later).
You can faintly see the sun rise in the top-left hand corner of the picture.

---

This dungeon is based around a super-jump mechanic, and has an emphasis on vertical design.

I made a post a while back, where I previewed a prototype.
I'll post gifs and more gameplay previews in a subsequent post.


Logged

Desolus Twitter: @DesolusDev Website: http://www.desolus.com DevLog: On TIG!
Mark Mayers
Level 10
*****



View Profile WWW
« Reply #102 on: June 23, 2015, 06:59:29 PM »

Update 43: 06/23/2015

I took a week of vacation for my birthday; I went to a music festival and had a ton of fun.

However, I was happy to jump back into development today!

---

Today I worked on the glacier world theme.
Environment design is my favorite part of development, so it was refreshing to work on.




---

I fixed a weird bug with the aurora effect.

The problem was I was using a random seed incorrectly, which I used to generate the visual noise in the aurora.
This seed seemed to 'corrupt' the other random number generators used in my Dx11 particles.
The result was instability in the snow particle system, with a strange 'bleeding' effect.

After changing how I call my random function, things seem to work.

I've had this problem for about 2 months, so I'm glad I could finally figure it out.

Here's the end result:



I've always loved the aurora borealis, hopefully I'll actually get to see it in person one day.

---

Vacation month is over for me, now I can buckle down and do content creation!

« Last Edit: June 27, 2020, 10:08:00 PM by Mark Mayers » Logged

Desolus Twitter: @DesolusDev Website: http://www.desolus.com DevLog: On TIG!
Mark Mayers
Level 10
*****



View Profile WWW
« Reply #103 on: June 24, 2015, 07:39:24 PM »

Update 44: 06/24/2015

This is actually more of a meta-update.

I organized all of my posts into a table of contents on the first page of my DevLog.

I did this for two reasons:
So other people can understand what my game is.
So I can understand what my game is.

As a thought exercise, I found it incredibly helpful to organize my work in this fashion.
This lays everything I've done so far on the table.

This game has changed *so much* in even the last two months.
It's not the same game I started out with.

However, that's the beauty of iterative design; nothing is sacred, and everything can be changed.
Every decision I've made has been based off of objective analysis and player feedback to make the best game I can possibly make.

I was getting relatively discouraged, feeling I had 'nothing' and that this wasn't even a game.
Even though it's been almost a year into development (with another ~2 years+ to go... really) I felt I haven't made any progress in creating my vision.

I at least I feel better knowing how much content I've actually created, with a rough idea of what I have left to do.

The size/scope of this game is ridiculous for a single person. I am completely aware of this.
Outside of dying in the next ~2 years of my life (heh), I am determined to see it to completion.

I 100% guarantee you I am totally crazy  Screamy
« Last Edit: March 14, 2016, 11:37:21 AM by Mark Mayers » Logged

Desolus Twitter: @DesolusDev Website: http://www.desolus.com DevLog: On TIG!
Christian
Level 10
*****



View Profile WWW
« Reply #104 on: June 24, 2015, 08:00:14 PM »

Could you give a quick summary on what the game was and what it is now? What were the major changes that altered the game so much?
Logged

Visit Indie Game Enthusiast or follow me @IG_Enthusiast to learn about the best new and upcoming indie games!
Mark Mayers
Level 10
*****



View Profile WWW
« Reply #105 on: June 24, 2015, 08:25:16 PM »

Could you give a quick summary on what the game was and what it is now? What were the major changes that altered the game so much?

Maybe a bit longer than a quick summary, haha.

Big Picture

The game started out as a 2D isometric game in 2011.
It transitioned into a 2D physics platformer in 2012-2013.

I scrapped everything except concept in 2014 and transitioned to 3D.
The first playable prototype was around August/September 2014, so that's when I'm counting development time.

Recent Development

The singularity/black hole began as a projectile, which was shot at particles to activate abilities/effects.

In the last 2 months I changed the projectile mechanic; the singularity now sits in your hand.
The black hole absorbs particles from stars placed around the landscape.
 
Absorbing particles give you abilities.
However, the singularity still only lasts 8 seconds; abilities are temporary.

It's almost a 'reverse first person shooter.'
There are no enemies, and you want projectiles to fly TOWARDS you.

You can shoot energy back out to power other stars; some stars lay dormant until powered.

Puzzles are based around player movement and player angle/obstruction relative to stars.
Later puzzles have timing/execution elements.

So 'Aim at Stars->Absorb Energy->Gain Ability->Shoot at Stars' is the core loop of gameplay.

I changed this because the player receives the effect and focus, rather than the singularity.
The best mechanics, I've learned, empower the player to do something.

Future

I'm finishing forming a cohesive set of interactive mechanics based around the core absorb/shoot action.

Think about how in Portal, there are sets of objects which interact with portals in unique ways; that's what I'm going for.

Then I'm going to take all of that and put it in a Metroid style progression and exploration focused world.
  
« Last Edit: March 14, 2016, 11:38:52 AM by Mark Mayers » Logged

Desolus Twitter: @DesolusDev Website: http://www.desolus.com DevLog: On TIG!
Mark Mayers
Level 10
*****



View Profile WWW
« Reply #106 on: June 27, 2015, 08:08:05 PM »

Update 45: 06/27/2015

I spent today primarily working on the glacier environment.

I made the terrain/design for about 4 different levels today, so I made a ton of progress.

---

The day/night cycle in the glacier environment is turning out to be great, I'm happy with it so far.

Here are some pictures:

Morning




Day




Evening




Night



---

I also have a time-lapse of the cycle.
I created it artificially by multiplying some speed variables in-game, so it's not a 'real' time lapse, heh.



---

Fun stuff! Tomorrow I'll be revising mechanics based off of the speed-booster I have partially implemented.
« Last Edit: June 27, 2020, 10:08:12 PM by Mark Mayers » Logged

Desolus Twitter: @DesolusDev Website: http://www.desolus.com DevLog: On TIG!
gimymblert
Level 10
*****


The archivest master, leader of all documents


View Profile
« Reply #107 on: June 28, 2015, 07:08:20 AM »

Holyshit nothing want to load, these image are ginourmous ... and that's the low quality!?
Logged

bitserum
Guest
« Reply #108 on: June 28, 2015, 07:19:49 AM »

I love the style, gotta follow.
Logged
oldblood
Level 10
*****

...Not again.


View Profile
« Reply #109 on: June 28, 2015, 08:27:12 AM »

That timelapse is gorgeous...
Logged

Mark Mayers
Level 10
*****



View Profile WWW
« Reply #110 on: June 28, 2015, 09:14:44 AM »

Holyshit nothing want to load, these image are ginourmous ... and that's the low quality!?

Oh, just realized the source images are ~4mb each as PNGs; I never compressed them, ha.

The gif I attached was originally ~17mb, I think Imgur did compress that, however.
The higher quality is a 60fps HTML5 gif; I wish I could embed that instead Sad

I still need to work on my TIGSource formatting. Any recommendations?

Most of this stuff is saved in my browser cache, so I never notice load times.

I love the style, gotta follow.

Thanks! I took a look at Cloudfall and I like your art style too!

That timelapse is gorgeous...

First time I tried something like that, good to know it resonates well!
Logged

Desolus Twitter: @DesolusDev Website: http://www.desolus.com DevLog: On TIG!
Fervir
Level 4
****


JustLikeMakeGame


View Profile WWW
« Reply #111 on: June 28, 2015, 02:48:17 PM »

Looks like a fun place to explore. Hope the sound design matches the quality of the art!
Logged

   
Mark Mayers
Level 10
*****



View Profile WWW
« Reply #112 on: June 28, 2015, 04:59:58 PM »

Looks like a fun place to explore. Hope the sound design matches the quality of the art!

Currently, I've made the sound myself, except for the title theme (I have decent audio experience).
Eventually I'll probably contract out an industry professional to go the extra mile.

Audio sometimes gets only 5% of developer attention, when it comprises almost half of the experience!

Music and sound have always been important to me in games, so I'm definitely going to pay attention to them.
Logged

Desolus Twitter: @DesolusDev Website: http://www.desolus.com DevLog: On TIG!
Mark Mayers
Level 10
*****



View Profile WWW
« Reply #113 on: June 28, 2015, 05:25:09 PM »

Here's what you can expect in terms of music:

It's likely to consist of mostly piano, in select areas that I choose to intentionally emphasize.
Otherwise, silence or ambient noise are what you'll hear.

(Current) What's currently in game.



: Kyle Landry

(Inspirational Themes) Songs regarding what I'm thinking music in the game could sound like.



: Zelda, Twilight Princess

Gwyn, Lord of Cinder: Dark Souls

Prelude 4 Op. 28 "Suffocation": Chopin

Etude Op. 25 No. 12 "Ocean": Chopin

"Gaspard de la nuit": Maurice Ravel

Prelude Op. 3 No. 2: Rachmaninoff 

---

I'm definitely emphasizing minor-key themes.
(Actually I think every song I linked for reference is in a minor mode except Ravel, hahaha).

'Dissonance' is what I would describe as the feeling I would like to convey.

Logged

Desolus Twitter: @DesolusDev Website: http://www.desolus.com DevLog: On TIG!
bitserum
Guest
« Reply #114 on: June 29, 2015, 03:09:22 AM »

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! Smiley )
Logged
Mark Mayers
Level 10
*****



View Profile WWW
« Reply #115 on: July 05, 2015, 06:18:55 PM »

Update 46: 07/05/2015

The past week I've been working on the 3 major 'weapons' in Desolus (so far).

Each color energy gives a weapon to fire projectiles, used to redirect energy at other stars.

---

I streamlined the core interactions a bit.
I removed the 'smoke ball' (if you look at the previous gifs) which was an artifact of the previous mechanic.

Before, the player would fire the black ball which would collide with a star, causing it to explode.
I decided to get rid of this step, and make the attraction instantaneous, causing interaction to feel faster.

Players also were confused during playtesting of what the 'black ball' did, it was too ambiguous.

Here's how it goes now:

When you're aiming at an active star and 'fire' your singularity, the star will supernova, and create a black hole in your hand.

So I went from:
Aim at Star->Create Smoke Ball Projectile->Smoke Ball Collides with Star->Star Explodes->Absorb Energy

To:
Aim At Star->Star Explodes->Absorb Energy

---

Here are gifs of the different energy types and their weapons.
Each energy type also has a relevant 'environment' (the three are shown in the gifs).

Blue is a single shot burst.

Orange is like a shot gun, it has a three shot burst.



Purple is similar to a machine gun, it has a constant stream of energy.



---

Next I'll be working on creating more levels relevant to the jump/speed boost mechanics!
« Last Edit: June 27, 2020, 10:08:25 PM by Mark Mayers » Logged

Desolus Twitter: @DesolusDev Website: http://www.desolus.com DevLog: On TIG!
Mark Mayers
Level 10
*****



View Profile WWW
« Reply #116 on: July 09, 2015, 06:55:34 PM »

Update 47: 07/08/2015

Today I prototyped a means of visual communication for what star corresponds to what object

---

I've meant to implement this for quite some time.

During playtesting, people often remarked that the effect of activating stars was extremely ambiguous.
After some thinking today, I decided on a way to show 'power transfer' between stars and objects.



It's pretty simple..... just draw a line!!

When you absorb particles with your black hole, the energy will dissipate and deactivate objects.
This is shown visually, as the energy transfer stops.



Releasing energy from your black hole causes power to 'resume.'

---

The theory behind this is based off of prisms and light, that's what gave me the idea.
Prisms can fracture light into different colors or directions.
Here, the light from stars transfers into energy, which activates objects.  

Everybody knows of course the cover to the Pink Floyd album; 'Dark Side of the Moon.'



Think of this as kind of a ... Pink Floyd Easter egg?
That's where the idea originally came from, I was listening to Pink Floyd at the time, ha.

Obviously this is just a prototype design; the final version will most likely change.
However, the black pyramid has always been a motif in Desolus and will remain so.

« Last Edit: June 27, 2020, 07:21:34 PM by Mark Mayers » Logged

Desolus Twitter: @DesolusDev Website: http://www.desolus.com DevLog: On TIG!
Mark Mayers
Level 10
*****



View Profile WWW
« Reply #117 on: July 13, 2015, 03:20:41 PM »

Update 48: 07/13/2015

In the past few days I've been working on what I'm calling 'constellations.'

Constellations are what show when a puzzle sub-section is complete.
It also serves as a type of landmark system for navigation, as each constellation is unique for every level.

Since this is an open-world 'Metroidvania' style puzzle game, I need to communicate *you need to return to this area later* to the player.  

---

In my last post, I talked about the theme of power transfer from star to object.
I expressed this by drawing an animated line between a star and its relevant corresponding object.



I went a step further, and started connecting stars to adjacent stars.
Since I am going with a stellar/space theme, I figured this naturally extends to 'constellations' as a metaphor.

---

Here's how constellations work:

When all of a central star's sub-stars (the smaller ones attached to the pyramids) are active, the central star becomes active, and the puzzle 'solved.'



---

From a technical perspective:
(*Meta* I'm going to do more of these, as I realize I often gloss over technical details and only post screenshots.)

Each star is essentially a 'node' in a directed cyclic graph.
Theory of Computation actually came in handy for once, heh.

Here's a rough chart of the level layout.
A, B, and C represent stars, 'Main' represents the central star, and light bridges are labeled accordingly.
 


Each star has a boolean value representing an 'active' state.

The active state is assessed based off of how many particles are in the star's gravitational orbit.
If there are fewer than N amount of particles in orbit, the star is not considered active.

To activate a dead star, the player shoots their burst of particles at the dead star, gathered from another star.

Objects attached to stars query the star's boolean state, and deactivate/activate accordingly.

To show energy transfer between stars/objects, I have a projectile fire from the star to the object.
The mechanism is actually an extension of the 'weapon' class I use for the 'guns' I showed a few entries ago.

This projectile shows 'direction' as specified by the graph above.

For stars adjacent to other stars I have *two* projectiles fire in opposite directions (ex, from star A->B and A<-B).
Two stars linked together form a branch of the constellation.

For the main star to be considered 'active' I query the boolean state of all its children, passed in via a reference.
It's a simple logical expression, in this case, A && B && C to 'activate' the star.

After the star activates, I set up more bi-directional links algorithmically between the main star and the children stars.

---

Where to go with this from here, design wise?
 
I may have some type of key/lock system where certain doors are only opened when certain stars are active.

I can also delinearize world structure, in the same sense of some other puzzle games like The Talos Principle.
In that game you need x amount of keys to open y door, but can complete puzzles in any order.

However, I don't plan on adding any 'filler' content, each puzzle serves a purpose and teaches the player something.

If every puzzle is essential, can you skip puzzles? These are questions I still need to answer.
 
« Last Edit: June 27, 2020, 10:08:46 PM by Mark Mayers » Logged

Desolus Twitter: @DesolusDev Website: http://www.desolus.com DevLog: On TIG!
Mark Mayers
Level 10
*****



View Profile WWW
« Reply #118 on: July 20, 2015, 02:21:17 PM »

Update 49: 07/20/2015

This week mostly consisted of a few small design changes that hopefully reduced visual ambiguity in the game.

I spent sometime reworking the particle shaders to make them more visible.
This was done primarily based off of playtesting feedback.

---

Stars now have a black core for visual emphasis.
This is mostly because before stars were incredibly bright, and barely visible against the background with high brightness values.



I took the screenshot during the day, by one of the 'beach' levels in the canyon.

It's now considerably easier to see stars across the map.
Notice the 'dead star' in the background of that screenshot.
It's much easier to see, where before it would simply blend into the background.

From a narrative perspective, at first glance the star looks like an eye.

Is the Desolus watching you? What is your purpose in exploring this dreamlike environment?
By connecting the power between these stars, are you somehow awakening some ancient entity?


I can go many places simply through this visual metaphor.

---

Light bridges/barriers now have an alpha particle shader instead of a transparent/multiplicative particle shader. This was mostly due to visibility concerns.

Here are the new particle shaders:



Before, I was using a multiplicative shader for light particles.
What this means is that particles were inherently transparent, and would over-draw on top of each other.

The more particles appeared in front of each other, the brighter the overall particle mass would get.  

Here are the old shaders:



The alpha-shader means particles are solid colors, and do not blend together in a multiplicative fashion.
This makes things much easier to see from a distance, and makes for more coherent and noticeable objects.

The shaders also have a gameplay purpose.
You *cannot* activate stars when your line of sight is blocked by barriers, it is a puzzle mechanic.
Why would you be able to see the stars, when you can't activate them?

Most of the barrier/light bridge puzzles are based around the player's position, relative to the barriers.
The mechanic is mostly based around challenges of perception.

---

I've changed how light beams work.

I removed the black pyramid mesh from the design, and vastly simplified light trails.

Light beams now 'recursively' travel from object to object from a source star.

For each object, the light beam will shine through as a single beam of light, redirecting where necessary.

Here's a gif of that pyramid structure, with corresponding light beams:



I feel the 'one line per object' rule is much more communicative than my previous approach in update #47.
 
---

I still have a lot of work to do, but I feel I've definitely made some progress.
Small changes end up leading to a much better game Smiley

« Last Edit: June 27, 2020, 10:08:58 PM by Mark Mayers » Logged

Desolus Twitter: @DesolusDev Website: http://www.desolus.com DevLog: On TIG!
Mark Mayers
Level 10
*****



View Profile WWW
« Reply #119 on: July 23, 2015, 08:35:43 PM »

Update 50: 07/23/2015

I spent some time today working on the gravitational lens shader!



This might fit into a 'light bending' mechanic I'm thinking about, which may or may not go in game.

---

Here's a gif of the effect:



There are *two* gravitational lenses in this gif; one for the black hole in your hand, and one for the world black hole.

There is, however, no gravitational attraction script attached to the world black hole (so particles just fly through).

---

There are a few problems with my script/shader, however. The gif actually shows some of these problems.

The black hole is a screen space effect; there's no raytracing, or simulating the path of light.

The shader only distorts the screen pixel space, rather than actually 'bend' the light in the game engine (is that even possible in Unity?)

Unfortunately, I have no idea how to implement a raytracing algorithm, so the effect isn't as accurate as it could be.
There is also occasional screen distortion, due to screen resolution.

This also makes 'visual obstruction' for the black hole act strangely.

As you can see in the gif, the black hole effect does not have any layer depth.
Objects in front of the black hole seem to simply be 'absorbed' where otherwise they might block out the light rays of the black hole. I need to check my physics on that one.

I also temporarily took out the singularity of the shader (the black center).
I'm trying to think of a better way to do this, outside of simply draw the center black at a certain radius!

Oculus Rift really doesn't like this shader Sad
The problem is with a 'World Space' to 'Camera Space' calculation that I'm making.

There are two cameras in the Oculus Rift prefab, which means the shader positioning is super wonky.
The black hole doesn't seem to like to stay in one point when you move your head, and floats around the screen in an odd fashion.

---

The mechanic I'm contemplating might involve something like this:



You would use the gravity of world singularities to affect the trajectory of your light projectiles.

I still have a ton of work to do with this idea, so it's still TBD.
« Last Edit: June 27, 2020, 10:09:07 PM by Mark Mayers » Logged

Desolus Twitter: @DesolusDev Website: http://www.desolus.com DevLog: On TIG!
Pages: 1 ... 4 5 [6] 7 8 ... 26
Print
Jump to:  

Theme orange-lt created by panic