jonoxia / rpgbase Goto Github PK

(where NPCs includes "treasure chests")

Figure out how to draw them, and hook it up so you can interact with them using the talk button.

Then encounter tables, step handlers, and the canCross method can all be defined in terms of the terrain type name.

since the square is empty when they start walking, both characters see it as a valid square to walk into.
When the walk animations finish, they're both there, and now we have two people occupying same square, which shouldn't happen.
What needs to happen is that just before any character starts walking into a square, they tell the map screen to put a lock on that square. they release the lock when they're done moving.
this way, the first one who starts moving will lay claim to the square, and the second one won't be able to start moving into it.

OK, so font.png contains a row of 8x8 characters each of which, as a rule, contains a full black line on the top and left sides, and combat-clutter.png demonstrates how this low resolution makes every pixel count. So the specific behavior I would like for a low res text window starting at point 0,0, where W is the number of characters in a line and L is the number of lines would be:

White pixels from 1,0 to (8_W+2),1
White pixels from 0,1 to 1,(8_L+2,)
Characters placed from font.png starting at 2,2 with an 8 pixel offset.
Black pixels from 2,(8_L+2) to (8_W+1),(8_L+2)
Black pixels from (8_W+2),2 to (8_W+2),(8_L+1)
White pixels from 1,(8_L+4) to (8_W+2),(8_L+5)
While pixels from (8_W+4),1 to (8_W+5),(8_L+2,)

The whole server-side component I haven't touched yet.

this is because it's currently using the number hard-coded in npcClasses.js, when it should be using the samenumber of frames that PCs use. Seems like this should be set on the base class MapSprite at the same time as the default sprite picker function is set.

When multiple PCs on the same square, the frontmost party member (according to marching order) should be visible "on top" (i.e. plotted last). It's currently the other way around.

PCs past the first don't get their screen x-y position adjusted during the step if the map is scrolling. They walk in place and then snap to their new position. (This is more obvious if you slow the animation down). If you're just walking in a straight line it doesn't matter, but if you turn a corner and then scroll you can see it.

• Function for registering callback to draw stats
• Default is, like, just put name and HP in a box for each PC

Tiles along the edges of the screen are not being drawn while scrolling, leading to distorted visuals, most easily observed at low animation speeds with non-uniform tilesets, such as with the mountains to the east here:

http://studioxia.com/moonserpent/

Even with values proportionate to the tile size, there is a sudden jerk forward at the end of the scrolling animation.

Holding a key does not result in continued motion in Firefox, but will cause the page to scroll.

Holding a key will cause continued motion in Safari, but this seems to be due to an oddly coded key repeat feature of the browser.

Walking into an obstacle for the first time causes screen to continue scrolling for half a tile, resulting in an off-centered character (although moving the opposite direction restores proper alignment).

Approaching the bottom edge of an irregularly shaped map causes a crash (prior to this update, doing so caused the character to become invisible.

New keystrokes fail to register when animation is playing, rather than queue up as intended.

Unwanted graphical "smoothing" is still being applied in Safari.

Possibly related- demo.html features bleed-over from adjacent tiles in the source image during scrolling in Firefox.

Animation is noticeably slower in Safari than Firefox. More an issue with the browser than the code, but may call for a work-around in the long term.

Unwanted graphical "smoothing" is still being applied in Safari.
It's barely noticeable unless you zoom way way way in, or look at the edges of plains tiles at night though.
We're setting ctx.webkitImageSmoothingEnabled = false;
but that doesn't seem to be respected?

• tracking each character's items
• dealing with what happens when a character gets an item
• defining items use effects: can they be used in battle? out of battle? are they consumed when used? what happens?
• defining equippable items: who can equip them? what slot do they equip to? what effect do they have on stats?

will probably need to refactor the battle system menus and the field menus so that the item command in battle and the item command in the field can share as much code as possible.

Holding command while hitting any arrow key has the rather surprising effect of treating that key as permanently held down. This does not seem to be exclusive to a particular browser.

NPC can walk through PC (though not vice-versa). The map.canMove method needs to have access to the party's locations and not allow NPCs to enter squares where a PC is standing -- although PCs should always be able to walk through each other!

E.g., "all_enemies" and "all_allies" target types

NPC can currently walk through anything. We could fix this on an individual basis by setting the canCross method of every NPC, but that's a lot of redundancy. Would be better if we could set a default canCross method that is applied to all PlayerCharacters and NPCs unless overridden.

Expanding the map a fair bit west left forced me to finally try moving the starting position out of the corner. The map is always initially drawn from the top-left corner it seems, leading to jarring effects on taking the first step to the right. Starting at a location not visible from the top-left corner of the map causes surprisingly few permanent problems, but I'd like the initial view centered.

So e.g. the party can get on a boat and cross the water.

boat's location should be remembered independently from party's location.

Since the end-of-battle text scroll is implemented as a scrollingTextBox, you can currently skip the whole thing and leave battle immediately by hitting X. That could mean you miss out on level-up text or important item drops or something.

1. Effects which grant extra attacks/actions outside of normal turn sequence (for e.g. counterattacks)
2. Temporary effect-handlers (e.g. for one round, when this happens, do that)
3. Commands that cost resources -- don't allow selection ifinsufficient resource.
4. "run away" status -- if a character or monster runs away, they no longer participate in battle and can't be targeted, but aren't dead. If all combatants on one side are dead or run-away, end the fight immediately even if it's the middle of a round.
5. conditions like sleep and poison

Holding a key does not result in continued motion in Firefox, but will cause the page to scroll.

Holding a key will cause continued motion in Safari, but this seems to be due to an oddly coded key repeat feature of the browser.

New keystrokes fail to register when animation is playing, rather than queue up as intended.

Where a scripted event can be triggered by stepping in a certain square, talking to a certain NPC, using a certain item in a certain place, winning or losing a scripted encounter, etc.

Once triggered, the event can include any number of steps which are played sequentially, which can include dialog, NPCs appearing and moving around, your PCs being force-moved to new locations, your stats or inventory being modified, new characters joining the party, and/or boss fights.

Most of this might end up being userland code but if there's parts we can usefully generalize we should do so.

Googleshng says:
"Testing showed this to be a side effect of having an animation speed that was not divisible by the number of pixels in a tile. For what it's worth, I have it set to 40 milliseconds and 2 steps to cross a tile, which looks super smooth and natural and is generally a good default to run with."

Should be fairly easy to build now that we have NPCs and the inventory system.

so that they player will know where to look for them.

e.g. right now if you do a full-party flee command and it fails, you never see the failure message because there's no delay before the monster turn.

• callback for individual PC to override default command set
• monsters need to have lists of actions, too
• callback for generic monster AI (e.g. "here is list of actions and targets, return action and target monster chooses")
• callback for specific monster to override generic AI with their own AI.
• callback to decide order of actions in round ("sort these guys in initiative order please")
• callback for specific monsters/PCs to override default with their own "battle effect message" handlers (implemented, but not tested)
• callback to override random-target selection (e.g. to make people at front of party more likely to be chosen)

I think this link is relevant:
http://www.isaacsukin.com/news/2012/06/how-build-first-person-shooter-browser-threejs-and-webglhtml5-canvas

(for a less "modern" look-and-feel, we we constrain the rotation angle to 90 degrees, constrain the steps to moving one block at a time, and maybe throttle the frame-rate and put it through some kind of pixellation filter.)

This makes moving around really weird, as you can step into the square where an NPC is going, but not into the square where they're coming from.

• callback for start-battle animation
• callbacks for individual attack animations
• monster death animations?
• figure out how to handle the timing of all these animations, i.e. pausing the main battle loop until each animation is done

Hit a key on the map screen to bring up the menu screen. Userland code should specify names and callbacks for the (possibly deeply nested) menu options; the menu system class turns that into a working UI.

Right now, when you create a new Map(), you have to pass in the x and y dimensions, and also a data array. If the x or y dimensions you pass in are larger than the data array, it will attempt to read pas the end of the array and crash.
The arguments are redundant anyway -- it should just use the data array itself. That way, this kind of error can't happen.

Pressing X or C causes a crash. Presumably a result of copying the code from an earlier version where these served to switch characters, using a now unused variable.

This seemed to start happening around the same time as I rewrote party.marchInOrder. I'm guessing that we need to special-case it so that marchInOrder just puts everyone at the vehicle location when you're in a vehicle.

where it tells you the money and EXP and etc that you got. Leveling up would also happen here.

Partly implemented already. Battle system needs to be highly customizable, so it should call back to userland for things such as:

• What to draw in the background
• How to decide initiative order for the round
• How to draw each monster
• How to draw stat block for each monster (if any)
• How to draw stat block for each PC
• each PC's menu of commands (possibly expressed as an override of the default set)
• AI for each monster to pick its move each round
• animation for spells and attacks in progress

At their most basic, an NPC is just:

• A sprite that is drawn on the map
• It can be stationary or programmed to wander around
• Its walking animation should not interfere with the player's walking animation
• Detect collisions - prevent player from walking through NPCs.
• Set an onTalk callback for the NPC. Trigger it when the player faces the NPC and presses the talk button. This could be as simple as showing a single message, or as complex as opening a unique menu system instance with options that modify the player inventory (aka a shop).

Play the intro part once, then the loop part repeatedly until the scene changes.

Each domain can have its own random encounter table (though they can also share them).

Table can be keyed (optionally) on land type, day/night, and geographical rectangles.

Data inside the table is a series of d100 threshholds and encounters, maybe something like this:
{50: {monster: biteWorm, number: 3},
80: {monster: biteWorm, number: 5},
98: {monster: groundSnake, number: 3},
99: {monster: metalSlime, number: 1}
}

where "50" as the key means "a d100 roll of 0-50 produces this encounter".

If keying on geographical rectangles, should be able to assign a zone code for each rectangle, and then key the encounter tables on zone codes. That way one zone can be built up from many rectangles, allowing irregular shapes.

For each map (or battle) should be able to specify a music "intro" and a music "loop". The intro plays once, then the loop plays repeatedly until the music is changed.

e.g. entering a town map or cave map when you step in a certain place on the overworld map.

Maybe try using the requestAnimationFrame shim to get more consistent performance?

It goes like this:

// shim layer with setTimeout fallback
// Written by Paul Irish
window.requestAnimFrame = (function(){
return window.requestAnimationFrame ||
window.webkitRequestAnimationFrame ||
window.mozRequestAnimationFrame ||
window.oRequestAnimationFrame ||
window.msRequestAnimationFrame ||
function(/* function / callback, / DOMElement */ element){
window.setTimeout(callback, 1000 / 60);
};
})();

And then the battle menus get drawn over the new map screen and it looks really weird. Disallow rolling for random encounters on a step that takes you into a town or cave!

this is not the desired behavior -- it's a side effect of how I implemented MarchInOrder, which is called after a fight ends in order to eliminate gaps caused by killed PCs.

this is because each sub-menu is displayed to the right of parent menu, and the sub-menus are never cleared. Try to keep everything on the canvas. Try hiding menus that aren't being used, and if that's not enough, start overlapping open menus.

Possibly a useful stacking feature but definitely not intended behavior!

It should only check that every PC who canAct() has a lockedInCmd, not every PC period.

I have some old AJAXMMORPG code that did this; it can be adapted.

• Draw doors and stairs instead of just black rectangle openings
• Walls to your immediate left and right are currently invisible (because they intersect with the screen at z=0, drawing them does weird things). Need to special case them or something so your peripheral vision isn't broken.
• Enemies need to appear on the ground, not hovering in the air in front of the walls
• There are some weird glitches that appear mid-rotation at certain angles, not sure why.