William Balcerski wrote: >>- 10 updates/sec. Because the client does not interpolate between >>server updates, gameplay appears 'choppy'. This is probably the area >>where I would most be inclined to change the server, moving to an >>event-based network protocol with sync rather than a updates/sec protocol. >> >> > >Nick Slager's java netrek client (jtrek) did this sort of interpolation. >It was most noticeable on torp movements. I actually thought it made torp >movement worse though, they kinda went all wobbly. > > I think to do this right will require a server-side change because the client obviously cannot extrapolate torp movements properly since it doesn't know where the torp is going to go next. I'd change the server to send the torp position and a vector, which the client would use until the next vector change came along. Torp wobble is accomplished by having the server twiddle the vector each time torps get updated. Now I can already hear the calls "But now the client can use the torp vector to predict the future movement of the torp! Think of the borgs!" True, but if the torp is wobbling a bit every 10th of a second this foreknowledge will probably not be a big deal. >It definitely has some neat stuff grahpics wise. Perhaps more ideas can >come from looking at it ;). > > > >>- Graphics. In general the bitmapped graphics look dated. Now I have >>the utmost respect for those who have come along and tried to give the >>game a more updated look with new bitmaps (Pascal comes to mind >>recently) but it's not just the bitmaps. Smothing out movements >>(vis-a-vis smooth ship rotations) and better effects (explosions with >>particle effects, maybe some lighting, trails off the torps or plasmas) >>are the top things which come to hmind. >> >> > >Well with ship movements to 256 positions (for the new bitmap set at >least), turning is smoother than ever. Lighting effects would be cool, >maybe some particle effects too. Trails off torps would just be >distracting though. > > > Certainly we wouldn't want to go overboard on effects, and they should be able to be turned off for those who find them distracting. But generally I think it is instructive to look at comparable modern games (various RTSes for example) and note some of the graphical details being presented. It's not that any one feature suddenly makes the game look alive, but a collection of very small things. Incidentally, having 256 bitmaps is not especially necessary since the code for rotating a bitmap smoothly is well known. It might save the artists some time to implement bitmap rotations in the client code (make sure it does bi-linear interpolation for rotated pixels!) so they only have to draw the bitmap once and not 'tune up' each degree of the rotation (assuming they do that in the first place.) Although this may seem like a scary idea, a reworked client could use one of the commonly-available, portable graphics engines, such as Ogre. In particular Ogre provides access to the full range of transformations available in 3D. While the game itself is not played in 3D, there are effects which could be implemented using such an engine (lighting, parallax starfields, etc.) >>- Playfield. I've always felt the tactical should be much larger. >>Obviously the galactic is very important and its ability to convey >>information should not be diminished, but perhaps it could be made as an >>overlay, or hidden under some circumstances, etc to give the player more >>tactical screen real estate (even if no real additional information is >>disphhlayed on the tactical.) >> >> > >I agree, one of the longer term goals for the client is to make tactical >resizeable. > > > >>- Sound. Netrek has always been weak on this front. We all know that >>it sounds like what it is - developers grabbed some wavs from their >>favorite Star Trek-themed source and slapped a playSound() call in the >>right places in the code. What needs to happen is someone who is good >>at manipulating sound files needs to fix these up, balance their levels >>and integrate them into an overall sound scheme for the game. A bit of >>background noise (the hum of the ship) wouldn't hurt. To be fair, >>recent clients have done a better job with some of the sounds (shields >>sound good, for instance,) but others leave much to be desired (the >>login WAV on NetrekXP 2006 for instance seems jarring, the cloaking >>sound takes WAY too long compared to the cloak animation time, phaser >>blast sound is slightly delayed compared to the graphics.) >> >> > >3) I've not noticed a delay on the phaser sound, are you getting delays on >other sounds as well? I haven't had a chance to really test the sound on >different systems, and since it's a whole new way of playing back sound >with newSound: on (I'm assuming you are using newSound), I'm curious to >see if there are some problems. > > > The delay is inherent in the sound itself. The attack rate for the phaser sound is too low (i.e. the volume does not rise fast enough.) That is just my opinion though. >>- Configuration. RC files died in the 90s, at least as a primary method >>of users configuring applications. There needs to be a proper >>configuration UI, including a modern keymapping system. Obviously keys >>can be remapped using the help screen, but this fact is a bit opaque to >>new players and provides no instruction. >> >> > >I do feel the keymap mapping is still the most difficult user >configuration required, which is why I tried to include the best keymap >possible as the default with the client. As for remapping keys by help, >we let players know that in one of the hint of the day messages. >The best I've come up with for changing options, is in game through the >options menu. Most rc options can be changed there. All netrekrc options >are listed in a file in the documentation folder called netrekrc_options. >You can choose to save your current options through page 6 of the options >menu, this creates a netrekrc.sav file in your netrek folder. I spent >quite a bit of time improving this, so that is should basically create a >duplicate of your netrekrc with whatever options you changed in game. I'm >hesitant to actually save over your netrekrc though, so you still have to >either rename the file or copy/paste into your netrekrc. > > > This is one area where I think the UI can be greatly improved, taking us away from the minimalist UI of the late 80s and trying to make the application either a) use the common paradigm of the OS on which it runs or b) uses its own paradigm but doesn't look like a developer designed the UI. I generally prefer to use the idioms of the OS on which the application runs because users will be used to this and the game will be much more intuitive to interact with. For instance, having the options windows be real windows consistent with the design rules for that OS, using buttons, checkboxes, textboxes, etc. Alternatively, the existing UI elements would have to be wrapped up in custom graphics and behaviors to maintain the theme of the game (and the game would have to be given a theme other than developer rectangles with solid lines before this can occur.) The current 'rows of settings' with some being clickable, some being just informational does not fit any standard paradigm and looks clunky, even if it IS functional. >>The ability to move windows in >>the client is nice, but quite possibly misguided, especially since you >>can do it while in combat. There are probably a limited number of >>genuinely useful configurations, and it may be wise to make it so you >>can't create dumb ones (for instance, where the galactic is partially >>obscured by the tactical.) These will obviously seem like minor issues >>to devs and hardcore players, but I believe new players will expect more >>polish from a game which is ostensibly 20 years old in its present form. >> >> > >Again, I tried to include the best possible window placement in the >default netrekrc. You can turn off window movement in game by adding the >netrekrc option windowMove: off. This is the default setting. > > > Hmm, for some reason window dragging was on in my game. I don't actually have a problem with the default window placement personally, but I can imagine that there might be two or three 'popular' placements. The options UI could let the user select from these pre-canned profiles, rather than having to edit the RC file. >>- Window decoration. Now maybe this can be turned on and I simply >>haven't looked for the switch, but by default the game should be using >>the OS standard window decorations for the main window, so that it can >>be resized, closed, minimized, etc. Having a game window without a >>title bar (as appears on NetrekXP 2006) looks VERY strange. >> >> >> > >The main window can be made resizeable, and it does come with a title bar. >You will need mainResizeable: on (also the default setting). > Unfortunately, doing this does not scale any of the other windows, which is what the user would expect. >To bring up >the title bar, hit alt-enter. The title bar cuts into the viewable >space if your monitor resolution is set to the size of your netrek window. > > The client could do a check and if the screen resolution is less than the size needed to show the window with decorations, turn them off, but only in the case where there is not enough room. Alternately, the title bar could be left on by default, but a 'fullscreen' option presented which eliminates the decorations (and expands the window to the full screen size.) This is a more standard paradigm for removing window decorations, and may be less offensive to users. >I could make the title bar on by default, but I think it's best the way it >is. One of the tip of the day messages also explains how to use alt-enter >to bring up the title bar. > Tip of the day are great. Another thing to consider is creating a help file appropriate to the OS. Such a help file could include the newbie guide as well. Here I am specifically thinking of a windows help file or a web page which is launched in your default browser when you select 'help.' > NetrekXP 2006 main window is minimizeable as >well. As for the close button, it's greyed out. Not quite sure why. >It's like that in COW and NetrekXP too. Any insight onto this one would >be appreciated. > > > I don't know offhand, I'll have to go browse through the code - it's been a while since I made a CreateWindowEx() call as I've been doing embedded Linux programming for the past 5 years ;) BTW, please take all of these suggestions in the best light. I'm not disparaging your efforts or questioning your judgement. These are my honest opinions on the subject. >Bill > >_______________________________________________ >netrek-dev mailing list >netrek-dev at us.netrek.org >http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > > > >