Public Project Discussion

[compelx]

- 04.20.13

Hello everyone, glad to see Echo Sector is back up and running.

I would like to extend an invitation to previous project members or anyone else who is passionate about the Crusader series. Given the amount of free time available with my new job and my recent move, I am planning to once again take a stab at creating a simple, yet fully functional Crusader game demo.

Anyone interested, please let me know.

Thanks!

 

[compelx]

- 04.28.13

Control Scheme

I've decided to adopt a mouse-driven directional movement scheme. The idea is that the mouse dictates the player's direction as opposed to a combination of keys being pressed.

There are issues with this.

First, if we calculate the angle based on two sets of points (x1,y1,x2,y2) > (player.x,player.y,mouse.x,mouse.y) and set the player sprite direction to the result we will have to control how quickly the player can change directions.

This becomes a bit alarming as when the mouse is closer to the center of the player, the angle changes much more drastically when the mouse moves. If you simply pass the mouse cursor south of the player (going effectively from 90* to 270*) you might want to add logic to have the player visually turn around rather than classic platform style (pop! he's now facing south).

Second, we have the issue of dead zones. Given that the sprites allow for a limited amount of angles (faceable directions), we need some sort of dead zone so that the player can only walk in certain directions. Any mouse movement in the dead zone is ignored until it passes between a set of monitored angles. The player would then continue to move in the last acceptable direction until the mouse passes into a new, acceptable directional space.

I do not remember off hand how many angles the silencer sprites allot for. I believe it was 8 (N,S,E,W,NE,NW,SE,SW). If that is the case, my idea should be fairly well represented in the below example.

Keyboard mappings!

This is a draft, it is just there for prototyping. It would later be changed to take into account community feedback.

W - move forward
S - move backwards
A - sidestep left
D - sidestep right

Q - change weapon
R - reload
U - next item
I - previous item

Spacebar - jump
Left Shift - sprint
Left CTRL - crouch

Left CTRL + W - roll forward
Left CTRL + A - roll left
Left CTRL + D - roll right
Left CTRL + S - roll backwards

 

[compelx]

- 04.29.2013

Depth and Collisions

Not my strong point. The extent of my programming experience is within automation development or content management. Game design is still a new frontier for me and as such, I like to prototype until I fall asleep.

So I have been working on a hackish way of collision detection and depth management of objects.

For those interested, here is the mock idea I had:

If player is north of object, in this case a wall, depth case is 1 (else 2)
The depth case 1 line is instantiated automatically based on two sets of points calculated from the objects height and width - visually, the line is hidden to the player. Even though collision would take place immediately when the player's foot hits the top of the wall sprite, any actions are delayed until the players foot (or technically the bottom of the player sprite) reaches the line.

The line would then prevent further movement. The same goes for when depth case is 2 - the top of the player sprite can continue to move north until it reaches the depth case 2 line.

Depth case is calculated based on point direction (angle) from the center of the wall sprite to where the player is. Traditionally you could get away with saying if ((direction >= 0 || direction == 360) && direction < 180){ depth case 1} else {depth case 2} however I think it would work better given that it is ISO if you use something more like >=23 - < 203, depth case 1 / else / depth case 2.

Then of course visual depth of the object is based on the depth case. Depth case 1 would make the wall overlay anything behind it. You visually then get the sense you can move in front of or behind objects.

 

[compelx]

- 04.29.2013

Depth and Collisions

Progress.

From a code perspective, my depth and collision prototype logic works.
From a visual perspective? Well... not so much.

The wall objects accurately change their depth but in doing so, they inadvertently sometimes overlap nearby objects.

I will spend the remainder of the night considering how to approach this problem purely from a mathematical perspective.

 

[compelx]

- 04.30.13

Depth and Collisions

Bit of luck. Utilizing depth=-y / depth=-y+1 I was able to resolve overlapping walls. This should hold true for other objects, like boxes, tables, etc.

I'm now working on smooth collisions. Moving the player to his/her previous x and y coords before collision works but players get stuck. The idea should be that the wall or object pushes you off of itself.

 

[JC Denton]

Hey, CompelX! Long time no see!

I'm interested in helping you with this project but I need to know more details about it before I jump in. Since my free time is fairly limited, for starters, I need to know if we're going to start from scratch, or are we still using GameMaker as a framework.