Lightless (Updated)[9.24.2013]

WIP games, tools & toy projects
#21 
if(movingDown && !movementDone ){
			successiveRight = false;
			successiveUp = false;
			successiveLeft = false;
			translate_y += movementSpeed;
			player.setY((float) (player.getY() + (movementSpeed)));
			movementCounter += movementSpeed;
			if(movementCounter < 4){
				frame = 2;
		    } else if( movementCounter > 4 && movementCounter < 16 && !successiveDown){
				frame = 3;
			} else if (movementCounter > 4 && movementCounter < 16 && successiveDown){
				frame = 1;
			} else if(movementCounter >= 16){
				movementDone= true;
				movingDown = false;
				movementCounter = 0;
				frame = 2;
				player.setGrid_Y(grid_y + 1);
				if (successiveDown){
					successiveDown = false;
				} else if (!successiveDown){
					successiveDown = true;
				}
			}
		}

Its the exact same for the other directions, when you press wasd, the movingDown/ whatever direction it is goes to true, movementDone is set to false when you press wasd, or if you are interacting with something else, it checks which direction is blocked before input is taken, then sets rightIsBlocked/ whatever direction, and makes it so it changes the frame so theyre facing the right way, but doesnt set the movingDown or movementDone from the corresponding key

#22

If you need the character to always reside in the very center of a grid cell, then I would do something like this: (pseudocode)




void moveUp(float delta) { //separate method just for readability here
   if(player.getY() is on above cell center, or just past) { //if he has reached his destination
      player.setY(aboveCell.y); //just in case he was just a little bit too far, we fudge a bit, again aboveCell is pseudocode
      movingUp = false; //we are done, stop moving
   } else { //still not there
      player.setY((int)(player.getY() + movementSpeed * delta)); //movmentSpeed in cells per second
   }
}


void doGameLogic(float delta) { //delta is seconds per frame, such as 1/60f, but is computed from the previous frame in case we are not making 60fps
   if(currentlyPressedKey == 'w') movingUp = true;
   else if() ... //you get the idea
   
   ...
   
   if(movingUp) moveUp(delta); //if he's not done moving yet...
   else if() ...
}

Hey presto! Framerate independent to boot!

Note that now, when a key is pressed, the player will move to the next cell (tile, whatever), even if the key is released as he is still traveling, but if it is still pressed when he gets there, he’ll just keep on going. Also, the player ‘snaps’ to the center of the cells. The fudging of the player’s location near the center shouldn’t be noticeable at decent framerates.

At least in theory, I programmed that in the post ofc, but hopefully you get the idea.

#23

Yeah i see what you mean, i just hope the snapping back isn’t noticeable.

P.S. my code keeps movement going even when the key isn’t held down as well haha

#24

I figured as much, but my real point was to think about movement as a task that runs, and only checks back after the movement completes. (No, do not try to thread it) That way you can update it any way you want, including using a delta.

#25

Do not use delta times in update functions. Use them in rendering if you want. It is more complicated, leads to bugs, and does not make game play consistent. You will either have bugs you never notice or level designs that are impossible for some computers. I played a physics based puzzle game (something really simple) where pressing go without moving anything made the ball bounce to different places. A game that simple (with a walkthrough) became impossible to win because the developer used delta time steps.

You probably don’t want to put yourself through the pain as a developer. Even if you do, the player won’t want that.

#26

Not sure I agree on delta being more complicated (compared to variable render and fixed logic), but predictability is indeed better with fixed timestep methods.
To use that with the “movement as task” idea:

Instead of[icode] player.y += speed * delta[/icode], use [icode]player.y += amountToMovePerStep[/icode]
and stop the task after so many updates, or player.y is in the right position. (e.g. Bennington’s 16 steps)

But remember, now the doGameLogic() needs to be called in a separate, fixed time loop, and I would definitely check out the articles and tutorials page for that. Also google around for fixed timestep loops that can catch-up if they fall behind.

#27

Honestly, there’s no immediate concern with my current system, the only time framerate drops is when i record, which i believe is cause by the camera taking up the same resources or some such thing,

If it becomes a problem i can try capping at 30 fps, which for a simple 2d game should be slow enough for any non extinct computer. If somehow that doesn’t cover it, i will find a better way to implement delta, or i will just seperate my animation and walking and rendering code into different portions.

One thing id like to know is how you guys export, because i haven’t ever successfully moved anything out of eclipse before, i use jarsplice and try to get everything right but it just doesn’t work for me

#28

Haven’t watched it, but seems as good as any

#29

I don’t think that works because i use multiple jars, but i’ll try it tomorrow after classes, if i can ill try to keep an up to date demo of it on the OP

#30

If by multiple jars you mean libraries, then it works fine, as long as the jars are added to the build path as libraries. (Which they have to be for it to compile anyway)
The options for including libraries:

  • Extract required libraries into jar: extracts each jar into your exported jar, can be messy.
  • Package required libraries into jar: puts each library jar into your exported jar whole, and uses a jar-in-jar loader at runtime provided by eclipse. I like this option, nice and tidy.
  • Copy into subfolder: does what it says, creates a folder alongside your exported jar with the library jars in it. You probably don’t want this.
#31

I do that, then if i double click nothing happens, and when i go to the prompt and do

java -jar Lightless.jar

It says Unsatisfied link error, no lwjgl in java.library.path

Im guessing that has something to do with the classpath file that eclipse makes but i’ve no idea what it should look like

#32

Try this:

If the option “Add to Build Path” isn’t there, then look up “lwjgl eclipse project setup” and look around in the project build configuration.

#33

Mine all say remove from build path, suggesting they are already there…

#34

Been pretty busy, but did a little work with NPC’s and changed text a little bit, NPC’s have their own ID’s and variables and such, but i haven’t implemented them walking/wandering yet.

I tried using a checkerboard pattern for the text background at first but after messing with different color combinations for 20 mins, plain blue really did just look the best

#35

I’ll be watching the development process, so far so good :slight_smile: keep it up!