Well, here we go again.. looking for some feedback on control systems. I'm looking at writing this little adventure system and was wondering what sort of control system would work.. here's the current demo..

If you click around your little chap will walk to the location clicked. Ignore the fact that you don't walk behind things or that you can walk through things. I was wondering if maybe it'd be more natural to be controlling via keyboard. This will of course wreck my network code but better to find out early (it'll currently run a local server).

I'm intending to add a GUI around the current view area to support the inventory, particular actions and chat. I'd also be interested in opinions on walking speed and/or the character being centered in the area (as opposed to free moving)

Your time and feedback is appreciated as always..

Kev

PS. I've fixed the frame rate to 30 so hopefully its not going to tie peoples systems up.

The jerky movement in the demo makes conclusions a little tricky - suggest you smooth it a bit to be sure that people are providing apt feedback. If you aren't seeing jerkiness yoursefl, erm...well this is on my normal 1Ghz machine nothing else really running so I don't know why it's jerky . But I'm assuming it's because you've got a quick hack positional interpolation that's coarse grained at the moment...?

For point-n-click games of this style, frequent clicking is tiring, slow and ultimately leads to RSI. A vast number of people end up just holding the mouse down and dragging it. This is partly because early games with this kind of control mechanism either polled for mous position and moved accordingly, or ingored the in-game position pointed to and just looked at the mouse's relative position to the player (e.g. Ultima 7). The diablo series, which obviously have set expectations for a lot of people, act like this although I suspect they have a dual mode - if you click and release, it acts like yours does now, if you click and hold, it acts like U7. This is all transparent and non-configurable, fo course.

Your demo doesn't support the drag paradigm - looks like you're listening to the mouse-down, then ignoring the mouse position until it ups and downs again?

Jerky movement? Oh dear, thought I was past the annoying bit. Its smooth as a baby's bottom here. Whats jerking exactly? The scrolling?

Mouse drag, sounds like a good plan. At the moment the network stuff is set up to be order based. You click, that sends a message to the server to place the order. The order is relayed back to the client and acted out. If I support holding the button down I can either:

a) Spam the server with updates to the positionb) Check say every second for a new position and update the order.

a) Spam the server with updates to the positionb) Check say every second for a new position and update the order.

c) make the client appear to react as fast as a), whilst sending server updates only every 500ms, and doing some form of dead-reckoning/predictive movement.

Well, c is what nearly everyone does when they can't afford a, so ... .

d) mkae everything coarse-grid-based, such that the playuer is only ever on a tile about 1 - 1.5 times his size. Smoothly animate on the client, but only transfer the new tile to the server when it changes. This smooths out most "lets change direciton really fast and be a PITA" behaviour, at the cost that players in game who try to "dance" in front of each other will be deeply unimpressive to onlookers. Many hack-n-slash games do this, because they don't care about the players' desire to "express themselves".

Runs at 29-30 on my machine. Looks good so far. I had a c++/allegro demo similar to this plus pathfinding minus networking last year. The thing that stopped me cold was object management/interactions. Thats when I started exploring scripting and never really got back to the game.

I'm curious about your command/order protocol. The system I've played with in scripting is variable length arg events (Obj [] in java) to objects (and the game engine) via a GameObject.doEvent(Object []). I was thinking something similar to this would work well over a network; event type would be first element of the array.

I'm curious if I'm on the right track here?

Otherwise, the controls responded as I expected; to my knowledge the Baldurs Gate games didn't do the follow-the-mouse-drag movement, they were click and move like yours.

I've actually just swapped to keys (which keeping a backup of the old stuff ). Somehow keys feels much more natural for this. The inventory is going to use mouse I guess.

The chat might be slightly annoying because of the key controls.

Nonnus, I'm not quite sure I get what you were doing before. I've not got as far as the scripting, I guess the scripting will all be handled by the server, so shouldn't cause to many problems.

The actual movement was done on an Order basis initially. The user takes an action and this fires off an order to the server. The server responds by telling you that your character should start the order.

I've actually just swapped to keys (which keeping a backup of the old stuff ). Somehow keys feels much more natural for this. The inventory is going to use mouse I guess.

The chat might be slightly annoying because of the key controls.

Depends on both the audience and the style of game. If you want chat to feature quite strongly (e.g. everquest amounts) then you should make a UI where people can type on the keyboard at any time without pressing a special key first. This will make a very large and obvious difference to socialization within the game (nb: personally I'd make it one of a couple of controller configs, so people who chat rarely can instead have their keybaord full of one-key shortcuts, along with the standard "hit enter to go into chat mode until the next press of enter" paradigm).

W.r.t. mouse vs keyboard you will get a lot more players if you offer a very simple and obvious mouse-based UI. In a perfect world, I'd make the mouse UI the default, with easy instructions in the first few minutes of the game tutorial area on how to change to a cursorkeys-based UI (and that chat-centred UI as a 3rd option). This will turn off the fewest possible players. So long as they are aware they can make the change, most won't at first (apart from your hardcore players who like to fiddle), but will remember they can later on once they get accustomed to the game.

Jerky movement? Oh dear, thought I was past the annoying bit. Its smooth as a baby's bottom here. Whats jerking exactly? The scrolling?

When it scrolls, it doesn't move evenly, it seems to go at varying rate. Seems like it's pausing for a couple of frames or so every couple of frames, or something. It's pretty regular, like it's doing 1-1-3-1-1-3 frames per frame or something (e.g. like with missed vsyncs). The pause is too rapid to really work out what I'm seeing

PS Ultimas had the arrow get longer and the speed increase based on absolute distance from the player. This is a convenient way of letting people move fast and yet lose fine control at the same time - it's much harder to be agile while running simply because you have to move the mouse much further to effect the same change in direciton.

When it scrolls, it doesn't move evenly, it seems to go at varying rate. Seems like it's pausing for a couple of frames or so every couple of frames, or something. It's pretty regular, like it's doing 1-1-3-1-1-3 frames per frame or something (e.g. like with missed vsyncs). The pause is too rapid to really work out what I'm seeing

Then I noticed the FPS is 24-27.

Erk, that probably means the demo is exceeding capabilities of your machine.. what spec are you trying it on. The FPS should be stuck on 30.

EDIT: Actually, maybe not. What JVM are you running and are you one of the folks thats got 1.5 up and running? If so could you try it on 1.5, apparantly thats got OpenGL support for Java2D.Kev

I don't use the beta JVM's, but we're about to use them at work ( want to do "-source 1.5 -target 1.4" if it works, assuming that javac is much more stable than the rest of the JVM). When this happens I'll retest and tell you the differences (side by side).

EDIT: just noticed that to run java 1.5 in your browser, if you have SuSe linux Sun requires that you are running Mozilla 8.1 (looks like SuSe users have a few decades to wait... )

Just booted into linux and run it here (Gentoo, GF4), using blackdown's 1.4.1 java (default one I appear to have) I'm getting fps of 800+ (since I took the limit out in the latest version). Could you try the current version and see if your frame rate is still <30?

Just booted into linux and run it here (Gentoo, GF4), using blackdown's 1.4.1 java (default one I appear to have) I'm getting fps of 800+ (since I took the limit out in the latest version). Could you try the current version and see if your frame rate is still <30?

! Nope, there *are* only nv drivers for this geforce (laptop version).

PS do you know how to change which JVM JWS is using? I *cannot* overwrite my system JVM with a beta VM (because I have to use this for work...). Appletviewer is very easy - it's just a symbolic link in the plugins directory (which in my case now points to *another* symbolic link for "my current preferred JVM's directory", which works perfectly . I can swap between 1.4.2 and 1.5.beta just by changing the JVM directory link; everything updates except JWS, but that was installed automatically and I have no idea where or what it's config is ).

No idea I'm afraid, I've just installed a jre and its brought a new webstart along with it... so I guess you get a new javaws directory per jvm

Shouldn't worry about installing the 1.5 VM for this. If you manging to get a FPS count reported of 250+ then there is something more basic wrong.. wonder if it could be to do with the threading model difference between windows and linux. Not sure, but its most likely due to current running the server as another thread.

I'll stick a yield in the server thread aswell, see if that helps. I thought sleepUntil() in gagetimer did this but maybe not.

However, getting 250+ fps is a good sign

Kev

EDIT: PS. Did the scrolling get any better with the fps reported higher?

The WebStart app launcher has settings for what JREs Web Start will use.

Thanks; once I'd found the executable I sorted it.

FYI things were about ten times worse with 1.5 beta - far far more choppy and jerky, fps jumped from 1 to 55 to 255 to 55 and all over the place, perceived fps was 1 frame every 5 seconds or so, sometimes lots a second, then back to every couple of seconds.

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