#playerobjectives

[jackeddieself97]

Week 16 (4th - 11th May) - Polish & Steam Page 🎨👷‍♂️🎬

Hi! I can’t believe the FMP is nearing its end. 3 weeks remaining! 🎇 I feel I accomplished a lot this week, however I did shift my attention towards my other unit as that nears its own end! 

This week I started to program the Player Objectives, and at this current state, the player has 7 objectives to complete within the game itself. I believe this to aid player progression by making the game appear more linear. In addition, I created a custom cursor, modelled keys in 3DS Max, created a credits scene and got to work on all round polishing/bug fixing. More details can be viewed in the Week 16 - Development Vlog video below! 

Jumping back into 3DS Max was very refreshing to say the least. I have not done many assets myself in The Forsaken Ruins, so it feels good to incorporate what I can. I have however, done a lot of art and sprites I feel! More than I can count for the Steam Store page!

Getting into Steam now though. I was pumping the hours into the store page this week. This meant getting a hefty amount of images, writing descriptions and specifications. Overall it took a long while! As of this current stage, the store page is in review, so hopefully everything will meet Valve’s expectation! 

I have also made a game-play trailer and will upload that as a separate blog post moments after I upload this one. I am very happy with how the trailer turned out! and I feel it meets the requirements for publishing. I intend to make more trailers in the future, although that might have to be after university. 

Below I will show some of the art I was working on for the Steam page and also the Steam page itself! (Subject to change)

It’s crazy to think about how far this game has gone. Looking back at my second blog post, it just puts everything into perspective.

I am exited to show everyone the trailer and the game. The FMP has been hard-work from day one and I just hope I can be proud of myself looking back. My peers have all worked exceedingly hard on their own individual projects and I wish them good luck as they continue.

Here lies one more week of polish before I can publish the game and be satisfied. Next week, I intend to finish up scenes, polish and add the last remaining content for a suitable Early Access release. Until then, take it easy, stay humble and blessed. Peace! and Cheers! 😎✌

#tfr #horror #steam #steampage #indie #unity #3dsmax #keys #gameplay #trailer #3weekstogo #credits #playerobjectives #hanginthere #gamedev #survivalhorror #polish

[backslashn]

Lighting the Player in Thief

So I've heard a couple people mentioning that Thief calculates how lit the player is by sampling the lightmap where the player is standing.

But this sounded wrong to me. On numerous occasions I've been standing in what looks like a shadow, yet been lit much more brightly than the ground would indicate—like this "safe-ish" example from Robert Yang's blog:

And thinking about the player moving through the Z axis: when climbing up a rope, for example, you can see the light gem change as you move in and out of view of lights around you. Sampling lightmaps doesn't work here either.

If the player does stay grounded all the time, then sampling lightmaps is a pretty good way of determining visibility that is excellent for player feedback. But it seemed clear that Thief couldn't be doing that—or not only that.

So, curious about how it actually calculates it, I dug into the Thief 2 source code again. Obviously things may have changed between Thief 1 and 2, but it seems unlikely on the face of it.

So for starters: the light gem code determines which of the light gem models to display by looking up player's "Visibility" property to get the light level. So it must have already been calculated earlier this frame.

Following the trail of breadcrumbs through the game, eventually I find the light level (ignoring other visibility modifiers like crouching, holding a weapon, moving and so on) being calculated by compute_object_lighting().

So compute_object_lighting() seems fairly straightforward in principle: it just adds up the contributions from all the lights around. The bitfield and inner_frac stuff is a bit confusing though.

Digging into objGetShadows() makes it clearer: there's a global cache with one entry for each object in the game, that keeps track of which BSP cell the object was last seen in, and a 96 bit field. Each bit there relates to one of the lights that touches that cell.

When the static lighting is computed for the level (in the editor), each cell stores the indices of every static light in the map that reaches it. Cells can be quite large, so this could be a lot of static lights. No more than 96 though, I guess?

Then for each object in that cell, this shadow cache bitfield has each bit corresponding to one of those lights: 1 if the object is visible to that light, and 0 if not. The location_sees_light() call does raycasts to check if the object is visible to a light.

Since most objects don't move much, the cache avoids having to do the expensive raycasts very often. Since a map in Thief 2 (pre-NewDark) could have at most 4096 objects total, this cache is 64kB.

Anyway, the conclusion of all that is: calculating the light falling on the player or any other object is done by iterating through the BSP cells' array of lights — WR_CELL(cell)->light_indices — and doesn't touch its lightmaps at all.

This boring code spelunk brought to you by the letter V and the number 96.

I previously posted all this on twitter, but twitter is bad for finding information again. So here's a more permanent home for the thread.

#thief

[arjenschumacher]

Follow the mouse!

The set goal was to move the playfield using mousecontrol. I managed to pull it off by reading the X and Y axis. However, this resulted in a complete mess, where objects were falling through the floor when motion of the playfield was too much. Also, physics objects froze now and then.

So I decided to move mousecontrol to the playerobject, the ball, instead. 

Next step was more diversity in lighting. I attached a point light to the player object, hovering just a fraction above the ball and following its movement. Next to that, I managed to add two spotlights, tied to the ball. When rolling around, this gives a nice ‘siren’ like effect. The shadows playing around complement the scene.

Download Rollerball 1.1 (58 mb, PC win32)

#rollerball #unity3d #lighting #physics

[daniellarsson89]

Unity-2D Player Movement

Checked through my old code some tooday and wanted to share how I got about movement in Unity. We add playerInput() into the void Update() function. So that we take input from the player in playerInput. This is obviously repeated for right,up and down aswell in a similar fashion.Then we call movePlayerLeft() which makes the actual movement of the Player(Object if you want to call it that). Lastly we attach this script onto the playerObject.

private void playerInput(){ if(Input.GetKey(KeyCode.A)){ this.movePlayerLeft(); }

private void movePlayerLeft(){ this.gameObject.transform.Translate (Vector3.left * moveSpeed * Time.deltaTime); speed = 1; }

#unity #movement