I intend for it to be a top-down 2D RPG, with 8 bit music and graphics. I am creating all the resources (Music, art, code, story) by myself. I am completely comfortable with the music and story, I'm decently comfortable on programming, and im honestly kind of crap at art, one of the reasons that i decided to make it more retro.

Final Fantasy style battlesMenusClass system similar to Fire Emblem, will reveal more when i start on it.No overworld (Final fantasy) walk everywhere (zelda / pokemon) with ports opening up for faster travel as you reach them.Story ( Branching?) (Have a basic idea, will reveal more when i start on it)ShopsMagic / Skill systemEquipmentMapDungeons (Most handmade, at least 1 infinite randomly generated)Colosseum Mode (Use your single player team to fight waves of monsters, would like to make it so you can face friends here via internet but have no idea how so we'll see)

When recording, the game slows down to 30 fps, and since framerate independent movement doesn't work well with my system, I move slower, in the future when i record i will just change to movement speed to match what it should look like. It is not a problem outside of recording.The recording is also lower quality, im seeing if i can fix that.

As you can see i dont have many tiles yet, just some dirt and grass variants, flowers, and a crappy sign and stump. If anyone has any tips for these i would appreciate them, ive looked at a lot of pixel art tuts, but they don't seem to help too much on such a small scale. Oh, forgot im using Dawnbringers 16 color palette, and im using Famitracker for my music

Ok, next up for me is making my second track which will be the title screen music, then add NPC behavior, more than one box of text per interaction, from there probably i'll move on to menus and shops.

Until then Id love to hear pretty much anything from you guys!

Development Steps (X means finished, O means in progress):Map Editor XBasic Engine 0MenusBattle EngineContentMake Website and figure out how to put it up for saleAttempt MarketingIf any success try to put on SteamIf rich: Pay someone to port to XNA for release on Xbox indie games

Thanks haha, the main reason it's as decent as it is, is the few hours i spent going through tutorials, im just not sure how good ill be able to make the more detailed stuff such as houses, or monster and character battle sprites

Last time i checked it wasn't, but just now i looked and you can! so ill maybe retake the video tomorrow after i write another one of my essays

EDIT: It's basically the same as Fraps except i dont think theres a 30 second time limit, it still slows my game down to 30 fps, even when i switched the capture rate to 60, but ill definitely be using it.

Alright new video up, got openAL, it's easy stuff, took 2 minutes to implement, however it does pause for about 1/4 second before looping but it looks more like a problem with openAL than something on my end.

Also the new video encoder thing doesn't output at full quality, but i'm thinking its because i didn't pay 200$ for the full version.

Trust me you can do it. You have to find a way around it! without it, a person with a really fast computer could move really fast! Unfair advantage. If it is an issue with not wanting to pass delta to methods, you could just make a static variable (and no, it will not static-imize your system at all besides 1 method and one variable). Unless you are working with a non update/render loop, I don't see a reason that you can't implement this!

I await his response, but the probability that someone would be experienced enough to turn out what he has already without looking at a single tutorial (lwjgl or otherwise), virtually all of which will demonstrate fps limiting (either implicitly or explicitly) is practically zero.

Sorry for not replying school is starting and im a lot busier, yes i do have the framerate capped at 60

The problem is that i made my own animation system that depends on how many pixels youve moved so far in the walk cycle.If i pass delta into their and it doesnt divide evenly into the amount of pixels (16) then you end up a pixel or three off of the grid, and that screws up basically everything.

I'm more than happy to take suggestions on how to fix that, its just something i made up myself so its probably not super-efficient.

Graphics should depend on what the state of the game is, not vice versa. Then the frame rate can be capped to any value or uncapped. If it's slow, then it is trivial to drop frames because a frame update is not necessary to make characters "go".

I have a movement timer, the thing is that if i need to move exactly 16 pixels, and have it change animation at every 4 pixels, and im multiplying my movement speed by a delta, it ends up either cutting off animations short, or i dont end up right in the center of the next grid point.Mabye i could round the output from multiplying my speed by delta to the nearest whole number so it would hopefully go into 16, but then its possible that it could get 17, then when i set it back to 16 it would be a little jump, ill post my movement code, and you guys can criticise it for me

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

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

voidmoveUp(floatdelta) { //separate method just for readability hereif(player.getY() isonabovecellcenter, orjustpast) { //if he has reached his destinationplayer.setY(aboveCell.y); //just in case he was just a little bit too far, we fudge a bit, again aboveCell is pseudocodemovingUp = false; //we are done, stop moving } else { //still not thereplayer.setY((int)(player.getY() + movementSpeed * delta)); //movmentSpeed in cells per second }}

voiddoGameLogic(floatdelta) { //delta is seconds per frame, such as 1/60f, but is computed from the previous frame in case we are not making 60fpsif(currentlyPressedKey == 'w') movingUp = true;elseif() ... //you get the idea

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.

my code keeps movement going even when the key isn't held down as well haha

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.

my code keeps movement going even when the key isn't held down as well haha

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.

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.

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

player.y += speed * delta

, use

player.y += amountToMovePerStep

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.

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

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

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org