Eep² - Active Worlds Improvements

or
The Real List™
or
Active Worlds Annoyances

2010

3/3: What? Hello? Wow, an update...after nearly 4 years! Anyway, italicized games and added some Wikipedia links. Beyond that, I'm not going to be updating this page anymore since AW is still stuck in the past and just won't evolve. Perhaps the page could be added to AW's wiki... I've moved on to Second Life but it has its own issues...

2006

4/10: News/Updates - merged 7/26/00 entry in duplicate 2000 section with first 2000 section (not sure how I missed it after all this time), fixed a link, and bolded game names.

3/27: Added Internet Archive link to Era's Peroxide engine forum post link in ground. Removed dead links from, and added "AW" to some "Added in..."s.

3/15: Added Internet Archive links to AW beta release notes (and added archived help for older versions). I'm trying to find release notes for all AW versions so if you have them please email me.

3/13: Fixed wishlist newsgroup link (trailing "/" bad, apparently). Adding AW 4.1's improvements where appropriate. Various editing.

3/12: I finally saw AW 4.1's improvements and, I must type, I am somewhat impressed with its improved interface, particles, and zones. However, the object properties box is even worse--it's still too wide and now it's even longer. It could be designed so much better. While AW still has a long way to go before it can compete with Second Life (SL), it's showing promise and potential (still). However, I think AW and SL should just merge. This SL forum post outlines AW 4.1's features compared to SL's (and see the 3D Game Comparison for a link to a virtual world comparison between AW, SL, and There.

2/25: Fixed HTML for Firefox compatibility. Having been using Second Life (SL) for over a year now (and it having many of these improvements), I see just how far behind AW truly is...

2004

9/2: Added Security icon.

9/1: Added volumetric light/shadow simulation to surface action command. Seems MSS isn't free...but I could've sworn it was...ah well. Thanks to Percipient for pointing it out--and also that custom world colors are now saved. Updated ground object action commands and object refresh. Separated world option color linking from absolute custom color saving. Added zone object registry.

8/1: Added Era's Peroxide engine forum post link to ground; cell size.

7/24: Added gravity adjustment update to "smoother avatar collision detection" in physics. Added texturemapping to integrated modelling.

7/23: Added "direction" option to "move" and "rotate" action commands.

7/22: object properties dialog prototype - changed page's colors; added "media" command, some icons, and "location" and "rotation" sections. Added Feature Vote link to header.

7/21: Changed page colors. Added AW website menu. integrated modelling: added bullet titles and edited. action commands - Renamed "change polygon rendering" to just "rendering", added "activate".

7/20: Changed "more action commands" to just "action commands" since it includes existing and additional commands. Tweaked away mode font dim color.

7/19: Added "cell-selected object list" to multiple object editing and some icons.

7/18: Updated, and added #3 to, "rotate", and added "move", action commands; physics (friction and momentum to avs). Fixed font colors to be exactly how they are in AW (which is why I don't like them with my background color). Moved "Security" after "Testing". Fixed tab introduction AW version (thanks Ferruccio). Added beta version release notes links (if anyone has older versions, please email me), some subsection menus, a gesture buttons image, action field length.

7/16: Updated "'stop' sounds" action command, security, and 3rd-person view (AW 3.4 zoom). Added media action command and some old seams updates to news/updates (vs. having the date in the section). Edited turning. Added "z-buffering" subsection to, and edited (near-plane) clipping.

7/15: Added Security section.

7/13: Edited clipping.

7/12: Edited various in-page links (anchors) and added form stylesheet. ChrisPeg is now (has been since December, 2003) an AWI developer. According to E N Z O, who I was telegramming with today, there may not be an AW 3.7. Instead, AW may possibly become a new unupgradeable(?) product focusing on a new architecture utilizing server plugins to compliment bots and extend the world server's capability (Snowcrash motorcycles, swordfighting, economies, etc). Apparently there are a lot of backward compatibility issues with the current (dating back to 1995) world database structure and it is a struggle to maintain. Also, supposedly in the works are particle effects, voice-over-IP (VOIP), and movers (elevators, etc). Take all of this info "with a grain of salt"...

7/9: Added counter old news/update. Check out Construction-Destruction for some cool terrain modification (digging holes, etc) that would be cool to have in AW! Changed tab pane lists and object properties window images. Edited whisper pane and object properties window. Tweaked (and renamed) font customization.

7/8: Updated older news/updates. Added Internet Archive link at bottom.

7/2: Updated momentum.

7/1: Updated improved scene handling. Added skybox. "Added" features will now be in this font (8-point Tahoma), italicized, to separate them.

6/18: Corrected this section's year (was 2003). Edited extended visibility range, interface lag, object properties window, and tab pane.

6/5: Fixed RenderWare logo (but I couldn't find the transparent-background GIF version, unfortunately). Updated seams and sprites.

With the release of AW 3.5, AW's user-interface is even worse: the tab window is now separate and undockable (forget about putting it the same way in AW 3.4-), an enlarged "busy" spinning globe (just mindlessly scaled up, aliasing and all, too--though it does return to its correct size if the gesture bar is hidden--but the 3D pane doesn't fully scale up to cover where the gesture bar was), and other things (skinned toolbar) that aren't really necessary (especially when gesture buttons are still screwed up). Perhaps the only good thing is the smaller "download" window but it's not dockable either so it's still in the way.

6/?: Edited seams (vertical-sync).

2003

2/26: Since AW 3.4 is still in beta, some of these updates may change before it's released. Updated "Movement": configurable keys, jumping, and momentum. Added friction/momentum action command.

1/19: Grr...I wish websites would leave (and/or not rename) graphics up and not change links. Removed RenderWare dVPS image and fixed link. Fixed Miles Sound System image link. AW 3.4 (still in beta testing) is turning out to have many long-overdue improvements listed on this page.

2002

9/21: Redesigned layout. Added "action commands" to Object Properties window. Enhanced "text/font colors/styles/name customization" a bit.

8/18-19: Edited object properties dialog box prototype.

8/16: Added LOD to improved scene updating. Edited object properties dialog box prototype.

7/9: Updated z-axis object rotation.

7/1: Updated clipping to reflect AW 3.2+'s 200m visibility distance.

6/28: Minor editing for AW 3.3. Renamed "web window" to simply "window" and added it and "external browser" to "web pane" interface entry. Moved "Added in AW 3.3!" from "entrance control" to "ground zero designation" (and ~~strikethroughed~~ it).

6/20: Updated integrated modelling: ground.

6/19: Updated 3D sound, overlapping polygon fragmenting, seams, 1st-person view, and some entries to include AW 3.3 features. Added "change polygon rendering" to action commands.

6/18: HamFon will be leaving at the end of this month. Will develops the server/SDK and Shamus handles the browser.

6/8: Roland has left AWC (and HamFon will be leaving soon). Will ("9 9 9", "MrGrimm") is now AW's lead programmer and Shamus Young is still here. Added "terrain" to ground object action commands and corona blurb to sprites. Updated z-axis object rotation and 3rd-person view perspective.

2001

8/31: Roland (AW's lead programmer) has written up several improvement explanations for possible future features: fullscreen mode, cell data limit increase, all-axis object rotation, telegram blocking, saving outgoing telegrams, and scale command. These will eventually be linked to from AW's new website feature voting page.

8/21: Edited improved scene updating.

8/17: Edited Design.

8/16: Edited object refresh, single object reload, "bounding box color", and avatar menu redesign.

8/15: Added "rotate" and "scale" to more action commands.

6/6: Edited more action commands and integrated modelling.

6/3: Audio: One (1) dead link (Aureal 3D) removed (OH GOD ICEY$&*#), moved (and added) "3D sound" out of "DirectSound support", edited "sound playing tags", and added "sound stopping". Edited turning. "More building commands": renamed to more action commands and edited "gesture".

3/17: Edited and moved improved object properties window to Interface.

3/15: Edited fonts and lighting. Added whisper pane.

3/14: Edited seams.

3/12: Added another fragmentation screenshot.

3/6: Minor edited various things. Renamed and edited "fixed" visibility to "fluctuation". Renamed "World Owners" to just "World". Edited world server GUI, movement (momentum physics and turning), and single object reload.

3/4: Edited reflection and lighting.

3/2: Edited and changed "overlapping fragmentation" to "overlapping polygon fragmentation". Edited lighting, seams, and DirectSound support.

2/24: Edited Design and Testing.

~2/?: Edited seams (Andras comment).

2000

12/24: Edited Design and other various things. AW 3.1 will have some things on this list.

10/18: Expanded polygon selection in integrated modelling.

10/7: Edited "more world information" in worlds tab pane lists, and design.

10/7: Added Overlapping fragmentation.

10/6: Edited 3D Engine: reflection, shadows, scene, and expanded visibility ("fixed"). Added: design, seams, and multi-column text (Netscape users only).

...?...

7/26: ground object action commands

...?...

6/22: Edited 3D Engine: scene and "view clipping".

6/17: Edited object grouping.

6/5: Various editing; "received telegrams" added to Telegrams Pane List.

5/30: Edited movement "smoother collision detection". Seems when I made the navigation I forgot to add a "Movement" link--doh.

5/25: Edited building bounding box color customization.

5/24: Added textures. Edited audio: "DirectSound support" and "sound playing tags"; building "custom objects/avatars" and object properties dialog box prototype. Also, it seems I was wrong about AW3's bounding box changing from AW 2.2's--that's what I get for not being in AW much before AW3 beta was finally released. :/

5/23: Edited sprites and lighting. Added skeletal animation.

5/12: Added: "date change" to Telegrams.

5/8: Updated: clipping and alternate rendering. World Owners: added "ground zero designation" and edited "object refresh".

5/5: Audio "better audio mixing" replced with "DirectSound support". Interface's telegram tab: "context menu additions" changed from "'add to contacts' context menu addition"; "organization" added.

5/3: Forms added to Interface. Building edited. Turns out HamFon is a full-time (not part-time) programmer for AWCI; 3D Testing edited accordingly. "Sprites" added to 3D Engine. Edited and changed "enhanced multiple object manipulation" to "multiple object edit" in Building.

5/2: Added "absolute custom color saving" to world owners and "object selection" to Building.

4/29: Updated some improvements for AW3. I want to wait until AW3 is out of beta before adding more improvements.

4/16: Added jumping to physics.

...?...: Added news/updates section.

2/22: AW logo added; RenderWare link updated; seems AW3 actually has some of these improvements. Amazing...

...?...

1999

...?...

6/11/99: Created counter.

2/99: Created webpage.

Perhaps the most important thing Active Worlds (AW) needs is better design. Back in 1995, Ron Britvich, AW's creator and initial developer (programmer), had a vision for AW, but that vision died when Rick Noll and JP McCormack decided to get greedy and boot Ron out of COF because they wanted to suposedly sell out AW (see lawsuit). Anyway, AW's development direction took a turn for the worse after this incident and when COF became Activeworlds.com, Inc. (AWCI) and later just Activeworlds Corporation (AWC) after the dot-com hype busted, and still later Activeworlds, Inc. (AWI)--phew! "E-commerce" was the overhyped marketing buzzword, and "virtual education" soon joined the bandwagon. AW's "e-commerce" is simply a pathetic joke, as is evidence by the still-floundering Sp@m Mart--er, @mart (or is that K-Mart?) world, while "virtual education" has had some success in AW (even spawning an education universe, AWEdu, which might have 10 people at most in it at any given time), hasn't generated much (if any) revenue for AWI or made AW anywhere near as popular as it could be with another development direction: gaming.

In November, 2000, I read that month's issue of PC Gamer Magazine and on page 60 it said they would be doing a review of massively multiplayer, persistent world (i.e. MMORPG: massively multiplayer online role-playing game) games the next month. EverQuest's (an MMORPG) registered player count should be a wakeup call to AWI: people like games more than they like to simply chat and build. Compare AW's citizen count (~25,000) to EverQuest's (300,000+) and that should be a clue. (And EverQuest's been around less time than AW has!) The March, 2001 PC Gamer even has an article about AW on page 26 ("A Brave New World") which claims AW could be "the next step for online gaming" and that "while there's no word on whether the company's talking with any big-name developers right now [they aren't], it's just a matter of time before someone takes advantage of [AW]". Gee, I've only been saying that since 1999...

Now, you may not consider AW a game, but, yes, I know this, and that's exactly my point as to why AW isn't as popular as it could be. With just a few minor gamelike features like better physics, jumping, an inventory, and the ability to either shoot, hit, or simply touch other people/things (not simply clicking them from long distances), etc, AW could become more attractive to gamers, especially since I think AW is basically a multi-user level editor--and there isn't any such thing that exists for any games that I know of (and, believe me, I've been looking for years), except for perhaps Vampire: The Masquerade - Redemption's "storyteller" mode and Neverwinter Nights' "dungeon master" mode (see game links).

Sure, there are limited building 3D RTS (real-time strategy) games like 10six, Star Trek: New Worlds, Giants: Citizen Kabuto, and others. Plus, there are of course many 3D game level editors (but the levels usually have to be compiled and cannot usually be "played" while they're being created/edited in real-time like AW can, though Unreal 3's engine is a step closer) and 2D map editors, but no game developer has done a real-time, multi-user 3D level editor. That is what keeps AW unique from every other wanna-be VR (virtual reality) program out there (except Second Life, but AW is more environment-customizable), but AW just isn't gamelike enough to compete with true 3D game level editors and even 3D games in general.

AW could be the first in this market if AWI wakes up to this realization now and starts moving AW's direction towards it. AW has stagnated and just gotten by for too long now--it's time AW had a real, marketable direction. E-commerce (an overhyped marketing buzzword) and distance learning education are fine sub-design directions, but there's no way AW will become profitable from them compared to gaming. The gaming industry--and, specifically, 3D gaming industry--has already proven itself to be very productive and popular; AWI should learn and adapt AW accordingly.

Don't you think it's high time AWI started reorienting AW's development in a new direction? I'm telling you (and AWI), gaming is where AW should be headed. Now, some people have a limited definition of "gaming" because they think it just means running around shooting people, but it doesn't. Yes, AW has some board/card games and a pathetic excuse for an RPG (AD&DRPG world), but I am referring to action, adventure, role-playing, and even strategy type 3D gaming genres. Sure, you could just go play a real game of one or all of these genres, but where in those games are you allowed to create new levels/worlds/tracks/maps/whatever in real-time with other people anywhere close to the degree that AW allows? You aren't.

And that's my point: if AWI would simply merge their "multi-user level editing" design with gaming, AW would finally become marketable enough to actually stand on its own as a viable alternative to on-line/multiplayer persistant games like 10six, Ultima Online, EverQuest, Asheron's Call, Anarchy Online, Sovereign, Neverwinter Nights, etc.

How much longer will AW continue to flounder while the rest of the 3D gaming industry passes it by and eventually develops AW's "multi-user level editor" design into its games on its own? Mark my words, 3D games are getting to the point of adding multi-user level editors--10six, Vampire: The Masquerade - Redemption, and Giants: Citizen Kabuto are perhaps the current closest, and Neverwinter Nights will be even closer.

AW will be nothing more than a fading dream within, at most, 2-3 years max at this rate (7 years seems like a good, common number)--OK, so I'm pulling a wanna-be psychic prediction here, but I really do see this happening more and more and really wish AWI would stop playing the silly, stupid "e-commerce" card and go play some 3D games and get a clue already as to AW's potential.

Testing

Perhaps the second most important thing AW needs is better testing, or quality assurance (QA). With now only 2 full-time programmers since Roland Vilett, and HamFon (beginning in AW3's development) left, Shamus Young (beginning with AW 3.1), Will (9 9 9, MrGrimm--left), and ChrisPeg, they just can't test everything in AW prior to public release, so AWI has had a closed beta testing program since AW 3.1 which relies on some "select" (at first those deemed "worthy" enough by Roland and then later if they happened to be at TechTalk) citizens to do free testing. However, most citizens aren't qualified to find problems/errors/bugs and so their bug reports are less than helpful in most cases. I've created an error report page to help alleviate this but AWI just doesn't care.

Proper testing procedures would require all beta testers to submit system specs and report any unchanged condition when the problem was discovered and duplicated but most beta testers don't have a clue as to what this means, which is why AW has so many bugs (and also because of poor initial design and programming by AW's creator, Ron Britvich, and then Roland and HamFon--see Mauz's AW History). Anyway, most (if not all) programmers miss things in their programming, but with more attention to detail, careful planning, and structured bug reporting, most bugs can be fixed relatively easily and without diverting too much development time.

Security

Around June 2002, I had my object password stolen (well, when I was made aware of it anyway...) and quickly became disinterested in AW and creating objects for it. AW is in desperate need of better security. Supposedly, according to ChrisPeg, AW already won't load if it detects a debugger is present, but apparently this isn't enough security to stop a determined hacker. Some people have PHP scripts that redirect to other object servers, but that doesn't matter if the AW browser (or a program made to look like it via the referrer) intercepts the password decryption.

objects: Some kind of public AW object registry where one's work is always kept updated (accounts, etc). Of course, for it to have any effect, AWI would have to condone it and abide by it when an object theft occurs, going so far as to eventually ban thieves and persue legal action if necessary.

3D Engine

Criterion's RenderWare (RW) 2.1, AW 2.2-'s 3D rendering engine, was obsolete because it relied mainly on software rendering. RW3 supports all major 3D hardware acceleration video cards, in Direct3D, 3Dfx, and even OpenGL rendering modes, and improves AW rendering performance greatly. AWI seems to have implemented it well enough and it does improve frame rate (especially in AW 3.3 with DirectX 8 implemented), but there are still some ~~compatibility issues~~ . Besides these issues, there are still some things that could be implemented:

improved scene updating: Another problem with RW (or at least AW's implementation of it) is how it updates the scene (RW term for an AW "world"). As new objects enter the visibility range, AW usually pauses slightly while accessing the world's cache on the hard disk and while rendering/unrendering them, even after they've already downloaded. This especially happens if the object's polygon count is high and/or there are many objects in a cell. While RW's (or at least AW's implementation of) scene updating (the process of adding things like objects and textures to a scene) is very jerky/twitchy/unsmooth compared to most 3D games, it is dynamic, meaning that all objects in a world don't have to be downloaded and rendered, and loaded into memory before displaying.
However, AW could be even more dynamic by partially rendering objects instead of waiting until their center anchor point (represented by a small, black triangle by default before the object downloads) is visible. This results in objects (especially large ones) that suddenly "blip" into view without warning. It just doesn't look natural and realistic.
AW should have more fluid scene addition like in many 3D games where clipping planes, fog, portal rendering (BSPs--which RW3+ supports natively so why not AW3+ too is beyond me...), level of detail (LOD), and occlusion rendering are used. Note that it is possible to use fog settings of the same near and far distance to get the effect of closer clipping planes, but AW still pauses while accessing the cache from disk since it's not all loaded into memory like a 3D game level would be. At least by using the far clipping plane method, objects would be loaded into memory before they're visible within the far clipping plane, thus reducing object popup and jerkiness. AW should have an option to use this method instead of its current one, and as an AW browser (not just world) option. The downside of far clipping plane visibility is that objects are "sliced" at odd angles as the camera moves around. A fixed clipping cube would be better.
cell size: Decreasing the cell size from 10x10m to 1x1m would allow for more detailed building (less than 1cm/1%-degree increments), the same cell data could be used, but since a 10x10m cell would now be 10 1x1m cells (horizontally only, of course), more action commands and objects could be added per "old" (10x10m) cell. Collision detection would be finer (hopefully no--or at least GREATLY reduced--slope "bouncing"). Objects would enter/exit the scene in a more fluid manner (though not as fluid as with just a clipping plane, of course).
lighting: AW 3.1 has significantly improved lighting (but not performance) by allowing multiple, dynamic (not static/fixed) light sources, and control over their _posi^tion, direction, size (radius), intensity (brightness), color, and type (spot, point, but not conical--though spot lights are close enough). AW3 allowed control over a world's single light source's position and color. Finally, "real" spotlights and streetlights (not like my fake ones in Hole used to be), flashlights, candles, flares, fire, shadows, and many more possible uses for light, are now possible!
Also introduced in AW3 was prelighting, but it only goes from white (1 1 1) to the color of the world light, so even if black (0 0 0) is specified, the light will only fade to the world light color. It would be nice if prelighting could take negative values to "suck" light out of a vert, thereby creating more realistic shadows and other lack-of-light effects. Negative lights were possible during the AW 3.1 beta but because Criterion yet again removed something cool from RW3 (the first being RWX, of course), negative lights were removed from AW 3.1.
overlapping polygon fragmentation: AW3+ has a problem with overlapping transparent/masked-textured polygons. Parts of the polygon will fragment as the camera moves around, causing alpha-blended areas around masked textures to become transparent instead of alpha-blending smoothly into transparent polygons behind or in front. However, AW doesn't always do this--it depends on where the camera is and if the polygons have reached the 3D pane's edge, so I don't accept Roland's response of it being a Criterion bug, especially considering I didn't/don't see overlapping transparent polygon fragmentation in AW 2.2 with the Direct3D driver.
Some games use a trick to get around this seemingly common 3D engine problem by not making the masked texture edges bilinearly filter but instead curve/round the edges so they're sharp (but not aliased). This way no overlapping transparency occurs.
reflection (environment mapping): Environment mapping is fairly common in current 3D games and gives objects a "shiny" look to them by applying and distorting a texture on top of another texture. (A similar effect can be achieved in AW 2.2- by not using texture foreshortening and in AW3+, since it won't allow non-foreshortening, by not specifying UV coordinates, which just makes AW 2.2- non-UV polygons solid-colored if a texture is applied). For example, the water in a cave that reflects upon the walls and ceiling of the cave. Also, hopefully this would allow for a mirror that reflects everything that is in front of it, so one could see the front of their avatar, but this isn't the same as environment mapping since true reflection requires rendering mirror images of all polygons on the other side of the reflective surface (i.e. mirror).
seams: Seams are those annoying flickering spaces between supposedly flush objects mostly noticeable when moving, turning and/or looking around. Apparently they are due to bad floating point math calculations when different objects are built and come to the same vertex. Whether this is an RW3 problem (perhaps having to do with z-buffering) or something else is unknown because Roland and HamFon can't seem to do anything about them. They suggest making the objects thick (depth/height, depending if vertical or horizontal) or making them slightly larger so they overlap. I would recommend the depth/height option first but it means wasted polygons to render. While overlapping objects a bit would cover the seams, having to build overlaps all the time would be annoying, as it may require many [Shift] and/or [Ctrl]+[Shift] movements (depending on what was being built). Also, depending on object colors, using a dark or light world background color, or making sure dark or light objects are under/behind seaming objects, can reduce the likelihood of seeing seams. Hopefully Criterion just fixes the problem and learns how to do math correctly, but I have a feeling it's actually an AW bug, as usual.
I talked to Andras about this (after posting yet another bug report about it in the newsgroups in the hopes that Roland and HamFon would wake up and fix it already, to no avail of course) and he said "All the objects are stored in the server's database on a 1cm and .1 degree resolution. The elevation difference could come from the browser if it is only a few mm." so this confirms it actually is a cell database issue.
Incidentally, if your 3D video card supports anti-aliasing (and it's enabled), seams can be reduced. Unfortunately, AW doesn't have any anti-aliasing settings so it must be done through Windows' display control panel, which is annoying since it should be a per-3D-app-controlled feature (which AW should implement).
This might be a vertical-sync issue since I see similar seams in 3D games without "vsync" enabled...
shadows: Shadows would make lighting more realistic. There's a way to fake shadows using polygons but they don't look as good compared to actual lack-of-light shadows. Dynamic lighting would also help with creating shadows, but AW would still need "light-blocking" in order to do real-time shadows (like Vampire: The Masquerade - Redemption and Severance: Blade of Darkness--which probably has the best shadows in all 3D games). This also means more extensive calculations, but system and video card processor (CPU) power has increased substantially enough for AWI to be integrating these features into AW. Note: multiple lights would give a better illusion of shadows for non-avatar (static) objects.
skeletal animation: AW uses SEQs for avatar animation, which aren't always fluid and avatar joints show when bent. If AW had skeletal animation, these things would be fixed as well as more subtle movement like facial expressions could be done.
sprites: Since RW3 dropped support for axis-aligned polygons (sprites/facers), Roland had to implement them himself in AW3, but he didn't retain RW 2.1's fully axis-aligned polygons so sprites now only rotate around the y-axis instead of both x- and y-axes. While this may make sprite vegetation (trees, tall plants, etc) more realistic, it kills the effect on small plants/flowers, coronas/"lights" (Metatropolis' "blink" object), and possibilities to attach a sprite sun/moon to a ground object so polygons aren't wasted rendering something people shouldn't ever be able to touch anyway. There should be an RWX command to switch between full/semi-axis-aligned polygons.
Coronas (AW 3.3+) act like full-axis sprites so it is possible in RW3 for polygons to have full-axis camera alignment--but only on lights. :/
textures: AW4- used only JPGs and BMPs for textures, but still only uses zipped BMPs for masked textures. Because JPGs are a lossy compression, they can be come "blotchy" and "blocky" so if a mask was created from the cleaner BMP version, then the BMP converted to a JPG for AW, the BMP mask won't match up perfectly with the JPG texture as it did with the BMP version--and this problem is even more apparent with AW3's greyscale masks. AW should be able to use zipped BMPs for textures as it does for masks. AW should also support GIF and PNG image formats. (Added in AW 4.1!)
view: Since AW is a fairly immersive environment (although it could at least support virtual reality (VR) goggles and gloves) looking around is an important part to this immersion. But, like in many things, AW falls short with this too.
1. 1st-person perspective: AW only allows looking up and down in 1st-person perspective with the page up/page down keys (which should be configurable) and now in AW3+ with the mouse in mouselook mode. But they both stop when not even reaching 90 vertical degrees from the center. AW should at least allow full vertical 180-degree view movement, and even a full 360 degrees wouldn't hurt either so things could be seen upside down. In real life one can look up and down more than 180 degrees vertically anyway! And having the avatar's head in-sync with looking around would be very cool too! Plus, some games also render the player character's (avatar's) body (and some also include the shadow).
2. 3rd-person perspective: AW has 5, fixed 3D views: 1 1st-person and 4 3rd-person perspectives. (AW 3.2 introduced the 4th, closer, 3rd-person view.) However, instead of fixed-position 3rd-person views, AW should have seamless camera zooming (added in AW 3.4!) and allow user-controlled movement of the 3rd-person camera around the avatar (similar to how Tomb Raider does it, but full 360 degrees along all axes like in Half-Life, Drakan, Morrowind, and to some degree in Outcast), so you can view your avatar from all angles, and any distance you want (like by using ctrl with +/- keys).
3. clipping: If the camera gets too close to, bumps into, or passes through an object, AW starts clipping (cutting off) the object's polygons along the near clipping plane before they've actually reached the extent of the 3D pane. While this seems reduced in AW3+, I still notice it at times. Plus, the near clipping plane shouldn't clip polys while passing through them but should completely render them to the edge of the 3D pane. According to Roland, AW's near clipping plane is set at 20cm because on 3dfx Voodoo (long defunct) cards there is a problem with texture mapping getting messed up or something. I've suggested making it an option or auto-detecting the video card and setting the near clipping plane distance accordingly, but he says RW doesn't have a way of doing the latter, and I guess the former is too intuitive for him to even conceptualize, let alone implement.
  As of AW 3.4 build 460 (3/3/3), the far clipping plane is adjustable up to 1200m and always enabled whether or not fog is enabled. Unfortunately, z-buffering is even worse--even with the far clipping plane real close. As of this build, the near-clipping plane seems to be closer, to.
4. full-screen: AW should be able to run in full-screen with the tab bars and menu items still on screen, like a status bar at the bottom of the screen in most 3D games. This would also enable switching to lower resolutions which would improve frame rate. When working in other programs while AWing, you should be able to switch back to windowed mode.
5. visibility
  1. alternate rendering: Instead of using the object's center to figure out whether to display it or not, based on the visibility distance setting, why not use the object's bounding box? That way if the object's bounding box is within the visibility distance, the entire object is displayed, instead of leaving gaps and then having objects blip in and out of view. I think that would make things smoother and more fluid.
    Also, if objects come into view first only within the actual 3D pane, and then the rest of the complete visibility radius, this would also speed up things. Plus it might allow AW to render more objects into the scene while moving instead of only up to 25m like it does now.
  2. fluctuation: AW fluctuates the maximum visibility range relative to the frame rate, despite what it's set to in the options. This can be annoying as objects blip in and out of view when standing still. An option to fix/force/lock the visibility to the specified setting without regard to the current frame rate should be added. Also, an option to fluctuate the minimum visibility range relative to the frame rate would make AW more intuitive at forcing a specific frame rate while fluctuating the visibility range.
  3. expanded range: AW's visibility is configurable between 30m (used to be 25m AW3.2-, although AW actually set it to 22m) and 200m (120m previously). AW should allow for 0m visibility and distances above 200m (up to infinity). Granted, higher visibility ranges may bring AW to a halt in dense (many objects) areas, but with increasingly faster CPUs (system and video), even with RW's software rendering AW's frame rate will improve. The 200m upper limit is supposedly due to how AW's cell structure is designed, and increasing the visibility limit would require rewriting this (which I think is about time!--see bad initial design note above.) Increased to 200m as of AW 3.2. A start, but today's computers and video cards can handle more--especially with LOD.

DirectSound: AW used to use Microsoft's MCI (Microsoft command interface) to play sounds, but it couldn't play more than one sound at a time and paused before playing a sound (which made "bump noise" action commands on walked-on surfaces extremely annoying). However, Microsoft DirectX's DirectSound can play multiple sounds (better audio mixing and fading), won't pause before playing them, can play more than one sound at a time, and has much more realistic fading/panning.
HamFon wrote AW's sound system for DirectSound during AW3's development, and AW 3.1+ finally has it, but there is a limitation: "sound" commands can't overlap; only "noise" commands can (but multiple "noises" can overlap a single "sound"). Roland says he didn't allow this because it would "break AW 2.2 sounds and screw up people's builds" (or something to that effect) but that's just silly because how can overlapping sounds screw up sounds compared to sounds abrubtly cutting each other off? THINK, Roland...
media command AW 3.6 introduced the media command (which uses Windows Media, a DirectSound component) that allows stopping sounds (WAVs/MP3s, among other media files) and can play simultaneous sounds. Unfortunately, the command doesn't support the current world's "sounds" directory's zipped sound files (requiring them to be extracted, wasting object server space) and its commands are wasteful (requires URL protocol text: "http://", "mms://", etc). As usual, AWI implements a new feature half-assedly.
3D sound: A3D (Aureal 3D, though now defunct), EAX (Creative Labs environmental audio effects), Miles Sound System (MSS, a common game audio library), and other 3D audio effects should be implemented for even more realistic sound fading/panning and effects (echo/reverb, etc).
fading: AW fades sound volume too gradually, playing sounds too loudly even when they are far away. AW should take into account relative volume distance fading.
global activated/bumped audio: AW only plays bumped/activated WAVs/MIDIs locally (on the activator/bumper's computer). AW should play these globally to all people within range. Added in AW 4.1!
sound playing tags: Either RWX tags or a way to specify in the world options objects which should automatically be tagged for WAVs (AW's sounds) to play when an object (or polygon if RWX tags are available) is bumped/activated. This would make putting sounds for common objects (poles, streets, grass, cement, metal, etc) much easier than having to edit each object's action property field, wasting cell data. An "override" sound/noise action command option could be introduced to bypass the RWX tagged (or world options entry) sound.
sound stopping: As lame as this is, AW can't even stop playing a sound once it's started ("sound" command only). The only way to "silence" (and I use the term loosely) the sound is to play an empty sound (silence) on top of it, which doesn't work completely when walking around the object. Also, a stop sound action command would be nice. See media command.

General

absolute download: Instead of having to wait while objects come into one's visibility range and are dynamically downloaded and rendered, an option to download all the objects, textures, and sounds at once could be convienent. Granted, this isn't really practical in a streaming environment like AW but AW could have some "cache-ahead" feature while idle (finished downloading up to current visibility range).
post-crash cache redownload: And since I'm on the topic of cache redownloading, after a crash in a world occurs, AW shouldn't mindlessly redownload the entire world's and "misc" cache directories. This happens because AW's cache database for the current world isn't closed until after leaving the world. A more intuitive approach to solving this problem would be to close the cache after downloads have stopped for a few seconds, at certain intervals, etc.
error text instead of error numbers: When an error occurs, AW should display the error text instead of the error number, or both of them, so it's easier to see for the users of AW what went wrong so they might be able to correct the problem themselves instead of being thoroughly confused by the cryptic error number. Programmers need to think about the end-users who aren't programmers...
interuniversal teleportation: With the increasing number of AW universes, AW should allow interuniversal teleportation instead of requiring people to download separate AW browsers with the only differences being the initialization (ini) file (aworld.ini), contacts list (contacts.txt), teleports (teleport.txt), and telegrams (telegram.*) lists. (Inconsequential things like the splash image, AW executable name, and ini file name can also be different.) Simple subdirectory manipulation of these universe-specific files would be all that's necessary to quickly implement universal teleportation. A better implementation would be to allow interuniversal telegrams and contacts lists as well.
inventory: Like in most action/adventure/RPGs (role-playing games), an object inventory (pick up and drop) would make moving complicated structures (perhaps combined with object grouping) over long distances easier. Also the possibility to use these objects for a specific purpose like in a Monopoly game, where you can carry your Monopoly money and exchange it for a hotel or house, and then put it down on a street you own. Second Life has an inventory and it is very convienent!
plug-in support: So third-party programmers can add things to AW that AWI's 2 programmers can't. The SDK (software developers kit) is a beginning to this process, but only really applies to bots which aren't integrated into AW itself like they should be (configurable via in-client dialog boxes, etc).
single object reload: "Object" includes any model, texture, sound (WAV/MID), and picture. Select an object (or multiple objects) and by simply clicking a button on the object properties dialog (for example), everything associated the object(s) refreshes so when downloading/testing something fails or doesn't look right (for example, when an object's texture mask becomes corrupt) the whole cache doesn't have to be deleted, or object refresh set to 0 (and visibility to 25m and set your avatar options to not show animation--SEQs--so object refresh can occur faster) just to fix it!
unbolded PS (public speaker) text: Should be fairly obvious, but this means being able to have PS rights (which expands chat range a bit) without one's text being bolded.

Interface

Object Properties dialog | tab pane lists

The interface (short for graphical user interface, or GUI) is perhaps one of the most important parts of an application since it is how the user interacts (interfaces) with the program. Interface design can make or break a program's ease-of-use, no matter how cool the programmer things the functions are (if they can't be easily accessed and manipulated, no one else will think they're cool). Taking this into account, AW has some very basic interface design flaws. AW4+ has an improved user interface with floating, dockable windows but there are still some flaws with it and the interface overall:

avatar menu redesign: Avatars should be categorized in cascading submenus (male, female, animals, non-human, etc) under the avatar menu, which would be especially handy when a world has lots of avatars. (Added in AW 4.1!) Or the avatars could be in a toolbar pull-down listbox () since having too many avatars causes AW's pull-down menus to fill the screen and cover up menu commands. However, submenus wouldn't work in it.
gesture buttons redesign: Having too many gestures causes the buttons to overlap the right edge of the screen and get cut off if the screen resolution isn't large enough to show them all. Instead, gestures should be in a pull-down menu or in a pull-down listbox () on the toolbar.
lag: As a whole, the interface lags as the 3D pane has to render more objects and animation. Typing becomes very annoying as the letters appear fractions of a second (or longer) after being entered on the keyboard. Scrolling the tabs pane lists and chat text pane become frustrating as well. And the pull-down menus lag too. If there was a way to speeding up the 2D portions of AW's interface—perhaps by limiting/increasing their refresh while the mouse/text cursors were outside the 3D pane. It seems as if the 3D pane refresh is "bleeding" out onto the other panes or something. The 3D pane used to freeze before version 2.1 beta, but there has to be a better way to keep that pane active while using AW's 2D panes without having them jerk, twitch, and lag. Lag was supposedly improved in 3.4 but I don't notice any difference.
improved "Object Properties" window: Just look at it! And AW 3.3 made it even worse because it got wider and still couldn't be resized or docked anywhere like most Windows apps can. AW4 introduced docking but there are still way too many buttons (which should be customizable). AW 3.4+'s window no longer uses your set Windows colors and dims the fields (to grey from annoyingly bright white) if you don't have access to edit a selected object. Funny how Windows handles dimming, without screwing with the set colors, fine... AW4+'s object properties window is even worse--look at all that empty space! There's no reason the "Location" and "Rotation" sections can't be on the same level since their fields don't need to be very long anyway. "Owner" and "Name" can be on the same level too.
1. action commands: These can easily be simplified with some basic GUI dialog design, which could be completely optional (for you sado-masochistic types who like to type) and would just be another more simpler, easier way to edit objects. Here is a prototype of what this could look like.
2. action field length: For some odd reason, the action field can only have 250 characters in it. This prevents more complex actions (that affect multiple objects, for example) and is just frustrating. It's bad enough there's already a cell data limit (which was increased in AW 3.5)...
3. categorization: A "database" (text file) containing all the world's objects, textures, and sounds, sortable into different categories. This would make classifying what kind of objects were available for some special building task easier, for example, as well as just being a convienent way to select objects without having to manually type or paste their names in. Objects, textures, and sounds could be categorized and a category file could be made something (perhaps similar to an ini file) to the effect of:
  [category]
  object name (with/without extension)
  or
  
  [vegetation]
  bush
  flower
  plant
  shrub
  tree
  and even subcategories:
  [tree]
  oak
  pine
  
  Separate category files for objects, textures, and sounds could be made too (perhaps naming them objects.cat, textures.cat, and sounds.cat). If AW had this categorization/classification database system built into it, perhaps even allowing the object server to have subdirectories as categories, like ..\models\mammals\cats, ..\textures\vegetation\plants, etc--and if these category classifications could be created/edited/deleted within AW (instead of in text files)--that would be even more intuitive.
4. 3D object browser/previewer: Implementing a 3D object browser/previewer into AW's "Object Properties" box could be made where the object is rendered, can be rotated, zoomed in/out, and previewed while perhaps even changing its attributes (color, opacity, texture, size, etc) before placing into the world (or these could be done after). If RWXLook/RWXMod can do it, why not AW?
font customization: Speaking (typing?) of colors, not everyone uses the default Windows white background and black text color scheme. The light grey (707070) tourist and green (238E23) immigration officer font colors are hard to see on some backgrounds (like neutral gray that I like to use). Also, italic text can be annoying to read for a long time, so the font style should be customizable as well. Changing the font face (Arial, Tahoma, Trebuchet MS, etc) would be nice too.
tab pane lists: As of AW 3.5, the tab pane is a separate, dockable window from the main AW application. While this is a step in the right direction, as usual, it's half-assedly implemented since it cannot be made to take the entire vertical side of the 3D pane, thus covering up a part of it. Also, when minimized/restored, it tends to lose width (or something) since the horizontal scrollbars re-appear even if the columns are adjusted so the scrollbars don't appear before the tab window (no longer a pane) is minimized. The tab pane should be reinstated as a pane so it can be fully dockable (adjusting the 3D pane accordingly, not covering it--or the chat pane, toolbar, menubar, etc). According to Shamus, AW needs to use MFC (Microsoft Foundation Classes) for this...or something. So why waste time half-assedly implementing it? Just do it right the first time...
1. text titles removal: Since AW is an international application, and to save space on the tabs pane, removing the text titles ("Contacts", "Help"/"User Guide", "Telegrams", "Teleports", "Worlds", and "Search"), and just leaving the icons (the universal language), would save room, allow more list entries to appear below the tabs. Tooltips (those popup descriptions) could contain the label text titles.
  I have the tab pane fairly narrow (all the tab titles used to be on top of one another but now are in 2 rows) and any decrease in space taken up by list columns and headers would help lessen having to scroll and resize this pane as much. One workaround is to remove these titles from the message file, but that means having to change each updated message file (which tends to be included with every build no matter what), which is just annoying.
2. Worlds
  1. alternate status display: Instead of those silly green/red dots to indicate if a world is open/closed and question mark (?: indicating an unknown/older-than-current server version), open worlds could be normal text (or bold), closed worlds unbolded (or dimmed/greyed), and "?" worlds italicized. This would save horizontal space.
  2. more world information: As a context menu (right mouse button click) option, (perhaps named "Information"), or next to the number of people in the world, (but that would make having to horizontally scroll the tab pane more, which could be annoying), the number of people the world can handle at maximum, whether you can build in that world, a full (more than 8 characters) world name, who the world owner(s)/caretaker(s) is/are, when the world was first created, etc.
  3. trial-/non-trial world differentiation: Like the "show private worlds" and "show empty worlds" context menu options, a "show trial worlds" could be added.
3. Contacts
4. Telegrams
  1. context menu additions: Often times, a telegram is sent by someone not on your contact list. It would be nice to be able to right-click the telegram sender and add them to the contacts list, as well as "send file" and "mute" to prevent them from sending more telegrams.
  2. date change: Listed telegrams should change to a date after a week instead of staying as the day and time it was sent.
  3. organization: Multiple telegrams by the same person should automatically be put into folders titled with the person's name and its telegrams named with perhaps the first few words of the telegram contents.
  4. prompt to delete just-read telegram (optional): It gets annoying having to re-right-click telegrams and choosing "delete" when a more simpler, intuitive, quicker method would be for AW to prompt you to delete a telegram after you just read it--or if you read and immediately replied to it as will happen 90% of the time.
  5. received telegrams: The telegram someone is replying to should either be resent or outputted to the chat pane (assuming it still exists in the telegram list) so telegram subjects can be remembered without having to ask the sender what they're referring to, for example.
  6. sent telegram log: Keeping a record of sent telegrams, similar to what ICQ and email programes already do, would make responding to telegrams much easier. The ability to verify what one has said in a telegram days, sometimes weeks after it was sent, is often needed. Having a sent telegram log would be helpful. Or at least the chat window should output the contents of a sent telegram immediately after it's sent so telegram discussions flow can be followed more easily without having to guess at what the other person is referring to.
  7. save/log telegrams to text file: An option to log one or all telegrams to a text file, just like the chat text can be saved while chatting.
  8. telegram window shouldn't hog input: When it's open, any other part of AW is unusable until the telegram window is closed. This is easily fixed by multi-threading, I believe; a simple, basic part of Windows GUI design.
5. Teleports
  1. organization: The teleport tab might be better organized if same-world teleports could be grouped in a heirarchy, and expanding a world (like by clicking on it in a tree-branch-style list) would give the list of that world's coordinates and descriptions.
  2. When editing teleport entries in the new teleport pane, some characters may be cut off.
tooltip color Windows allows changing the tooltip (the text that "pops up" when the mouse is held over something) color in its Display Control Panel. AW's tooltip color is a different color than Windows' for some odd reason. AW's should be based on Windows' (or at least a checkbox to do so). It stays that default Windows puke-yellow color even if it's changed in Windows.
web pane
1. window: The web pane could be made into a separate window behind other windows or on its own tab so one can use the web window in a bigger portion of the screen, and put it to the back of the 3D and chat windows when one wants to move around in AW. Although an alternative to this is to just use a non-integrated web browser like the normal Internet Explorer or Netscape Navigator.
2. external browser: The external browser briefly flashes when a link is clicked but doesn't come to the foreground.
whisper pane: AW should intuitively display/hide the whisper pane relative to avatars nearby. So if there's no one within chat range, the whisper pane should automatically disappear and vice versa. Also, if someone's name is the active whisperee and they leave the chat range, the next name in the list (if any) should automatically become active (or at least optionally so).
The whisper pane should also not grey out when in mouselook mode since one can still type while mouselooking.

bounding box customization
1. visibility: Originally, AW's bounding box was only visible from outside the object. After I suggested rendering the inside to Roland, AW now does it. However, some people have complained about this because it is difficult to see where the object's edges are and it's kind of annoying when selecting multiple objects. An option to use the old-style bounding box would be nice, but a better idea I suggested to Roland at the same time is to only show parts of the bounding box not blocked/covered by the object's polygons. Only the object's polygons would cover parts of the bounding box, and not other object's polygons. This would still make the bounding box visible through other objects, while leaving the object itself easy to move...in theory anyway. An option whether or not to render the bounding box through other objects (like the ground object) would make building easier too. Another way to show the bounding box is to just show its inside if you're inside it, but I like the polygon-covering way better, but it's probably more complex.
  
  AW3's fog obscures bounding boxes, too, which can make building in fog annoying--especially in public worlds where one may not have access to the world's fog controls. A way for people who have building rights to disable fog when building would be convienent.
2. color: AW's bounding boxes are yellow. In fact, all RenderWare programs I've ever used have had yellow bounding boxes so it must be the default bounding box color or something. Being able to customize this color in AW would be nice, as yellow isn't always the best color, especially if an object has a deliberate yellow wireframe box around it. On the subject of color, it would be nice if the bounding box changed color (perhaps red) when encroaching on someone else's property while moving (an) object(s) as a warning before deselecting the objects and having them annoying (especially when only some objects) blip back to their previous position.
custom objects/avatars: AW requires having access to a world (or know someone with access to the world's object path) in order to use custom objects. This is frustrating for aspiring object designers who don't want to pay for a world. If AW is to be more of a community, like the Web, it should open itself up more to customization and personalization. Custom objects (including avatars) would be one way to do this. Custom objects could be access through URLs in the object name field, similar to how JPGs, WAVs, and MIDIs are URL-accessable in the object properties' "action" field. World options with size, polygon, and/or texture limits could also be imposed to control abusers.
improved "Object Properties" window: See Interface.
integrated modelling: This would involve manipulating objects' vertices/polygons and their attributes in real-time within AW itself, without requiring an external program to create/edit them.
1. polygon breakup: Some objects only need some parts (polygons) changed. Break up a selected object into its polygons (like by clicking on one with a special "polygon select" key held down or "Object properties" dialog button) and then change just that/those selected polygon(s)'s surface, opacity (visibility), texture, solidity, etc.
2. selection: Multiple vertices/polygons could be selectable/deselectable by the same method AW uses to select/deselect multiple objects. These selected vertices/polygons could then be moved/rotated using the same keys AW uses to manipulate objects, but hopefully with much more accuracy/precision than the current object manipulation limits (at least 1mm movement increments, .01° rotation increments, and 8-decimal-place world cell database accuracy).
  Selecting a vertex/polygon could cause it to become a more visible color (or a different color wireframe) to distinguishable it from unselected vertices/polygons.
3. render modes: Options to view the selected object(s)/polygon(s) in wireframe, point/vertex geometry sampling, with or without textures, or either in facet or vertex light sampling.
4. overlays: Options to overlay wireframe and/or point/vertex views so as to create a guide for manipulating their polygons/vertices.
5. add/delete, move/rotate: vertices/polygons could be moved/translated (raised/lowered--lofted), added/deleted, and otherwise manipulated.
6. editable attributes: polygon surface and vertex prelighting
7. scalability: Vertices, polygons, objects, and groups of objects should be scalable in all three dimensions, including negative values to mirror the selection. If a polygon is texture mapped (UV coordinates), it should also be scaled. To keep abuse of scaling under control, a world option to set a max scale limit could be created, if necessary.
8. ground: Ground could be modelled in sections/modules (also called sectional/modular ground) to create terrain (hills, mountains, plateaus, etc). For example, beginning with an infinitely repeating ground object, it could be divided up into configurable sections (in meters: 1x1, 5x5, 10x10, 20x20, 30x30, etc.). A 3D wireframe grid (with its maximum height every x meters, depending on the grid size) could be overlayed onto these sections (with optional snapping) so as to create a guide for manipulating them. At each grid intersection could be a vertex by default with an option to highlight all visible vertices and/or polygons.
9. avatar movement: Being able to move one's avatar around while vertices/polygons/objects are selected would be important in order to maintain maximum manipulation.
10. texturemapping: Of course, with all this modelling, AW might as well include integrated texturemapping too. Besides being able to edit the UV coordinates themselves, planar, cubical, cylindrical, spherical, and other texturemapping types should be supported.
movement while object(s) selected: Being able to move one's avatar around while objects are selected is important in order to maintain maximum manipulation capability. Having a static view while manipulating objects can be frustrating when trying to line up an object (especially many objects) and having to deselect/reselect them many times.
action commands: Most of these action commands have to do with reducing the number of objects required to be made just to do some simple changes to them.
1. activate: an option to only allow clicking an object ("activating" it) from a specified distance (in meters: "distance=1")
2. rendering: Sometimes an object is double-sided (inner and outer polygons rendered) when it doesn't need to be. Being able to quickly change the sidedness of an object's polygons would be quick, convienent, and save from having to create another object. These commands could be named "1sided" and "2sided". A related command, "reverse-sided" ("revpolys"--inconsistent with previous commands but short), would be handy for reversing an object's polygons (for example to allow variety in rotating textured walls without having to have a double-sided wall).
3. friction/momentum: Makes an avatar's friction/momentum (sliding) increase/decrease to simulate various surfaces: slippery (ice, snow, wetness, etc), dense/thick (brush, plants, vines, etc), "sticky" (mud, sand, deeper snow, etc), etc.
4. gesture: Makes an avatar do a specific gesture, like "activate gesture sit" when a chair is clicked, or "activate gesture 1" for the first gesture of that avatar.
5. move:
  1. norestart: don't allow move animation to be restarted while it's happening (with/without the "wait" option in effect)
  2. direction: moves object in exact opposite direction of where it was activated/bumped
6. opacity: Ever since avatars could fade in and out when teleporting I've wanted an opacity command (complete with "name", "tag", "loop", "time", "wait", and "reset" parameters). Just think of all the neat stuff one could make with all that "glass"! :)
7. rotate
  1. While this command was added in AW 3.1, it isn't consistent with the "move" command added at the same time. Rotated objects don't return to their original positions like moved objects do. Added in AW 3.3!.
  2. units: Rotation is specified in RPMs (rotations per minute) instead of the much more intuitive degrees--at least a "switch" like "-deg" should be optional to use degrees (or the less often used RPMs: "-rpm").
  3. norestart: don't allow rotate animation to be restarted while it's happening (with/without the "wait" option in effect)
  4. direction: rotates object in exact opposite direction of where it is activated/bumped.
8. scale: It would be a lot easier to be able to scale objects in AW than having to make whole new objects all the time. Sometimes, in order to get a perfect fit, an object only needs to be scaled down by a meter or less; being able to do this in AW would save a lot of time.
9. "stop" sounds: Makes (a) playing MIDI(s) or WAV(s) stop without having to use silence.wav or silence.mid. For example: "activate stop [MID or file.mid for a specific MID]" and "activate stop [WAV or file.wav for a specific WAV]" or as an option to the "noise" and "sound" commands: "acstop"/"bstop" (short for "activate stop"--so as not to confuse an "astop" option with the "create animate astop" option--and "bump stop"; both shorter than requiring a separate action command). AW 3.6 introduced the "media" command which can stop media files (not just WAVs). Unfortunately, it has its own problems.
10. surface: Being able to quickly change the surface settings of an object would make having to make a whole new object obsolete and save on yet another download/refresh call to the object server. This would make creating "dark" versions of objects out of direct light much easier and faster, especially if only a couple such objects are required. Also, volumetric lighting/shadowing could be simulated with a "bump surface .5 .1 0" (for a darkened version) on an object in order to, say make an av appear to get darker as it walks into and out of shadows.
multiple object edit: AW can already select, move, and copy multiple objects so why not edit their action/description fields too? For example, because of AW3's lack of backwards compatibility in using non-existant texture names to remove an object's textures and revert it back to an overall solid polygon color, it gets annoying having to change each (out of, say, 50-100) object's action field from "create animate me . 1 1 0" to "create color grey". Regardless, this feature would make editing multiple objects much quicker and easier.
object gravity: Options to enable gravity on objects globally (world option) and individually (user option) would make vertical building easier to line up and make objects flush as well as more realistic.
object grouping: This would make selecting/moving a lot of objects much easier. Multiple objects could be selected and then a "group" (or "ungroup") command/button in the Object Properties window to link them all together for easier moving and later reselection. Grouped objects could also be "saved" in a "grouped object list" to be built with later. Selected objects could have an option to be changed/converted to a grouped object, different from the "group"/"ungroup" commands. Yes, some bots can already do this but the process isn't very intuitive and AW should just have it built-in anyway (which I think most, if not all, bot functions should be).
object selection: Since AW3, selecting objects above/below ground gets really annoying when selecting objects where ground cover (underground panels) is present because I've found I tend to select the ground cover more than the objects above ground. If this "feature" was added to accomodate below/above ground object selection, a more sensible design would be to have a per-user (not per-world) option to disable/enable the ground object. Note that this wouldn't have any effect on worlds that use modular-only ground (and terrain).
object state variables: Set variables like "object1.visible" to specify if "object1" is visible or not, and user definable variables that can be changed and read in action commands which would allow for more interactive, programmable objects and object animations instead of having to rely on bots (which should be integrated into AW anyway).
relative encroachment: AW's encroachment is absolute, meaning no one can build above/below another's objects, unless that person has eminent domain (ED). Being able to allow encroachment over/under one's objects would be very helpful in community-based building (i.e. public building worlds like AlphaWorld). For instance, I have a lot of pipeline streaming out in Mars world. It would be nice if I could specify (say by an "allow encroachment" checkbox in the "Object Properties" box) that people could build above and below this pipe (but not through it). That way I could bury the pipe and most people wouldn't even know it was there.
whole object movement: While AW3's adjacent object copy reduces frustration when moving objects long distances or even when trying to line up similar objects, AW's object manipulation can be still be annoying when moving objects. A way to also move objects (like by holding the [Control] key down) their complete widths, lengths, and/or heights would make building easier.
z-axis object rotation: It's annoying having to create a whole new object just to rotate it along its depth. This would save on download time (less objects) and would make worlds render faster. Added in AW 3.3! Full-axis object rotation is now possible using either the keyboard or mouse; there's even a "reset" (in addition to the old "undo") option but it would be nice to know the exact rotation degree on each axis (and object world position) for specific, detailed building. Also, being able to change the rotation pivot would be convienent, without having to create a new object with a different origin.

Movement

physics| turning

separate straffing and collision detection disabling keys: AW uses "Shift" for straffing but it also disables collision detection ("pass-thru") if it's enabled in the world options. This can be annoying. Separate keys for these functions would make more sense so one won't move through things (like an inclined surface: slope/hill/mountain—or anything for that matter) when straffing.
~~configurable keys~~: Even better, most 3D games allow the player/user to configure the keys it uses to control movement, view, etc. AW forces certain key combinations that may or may not be the most efficient for their keyboard (some keyboards click/beep when doing certain key combinations) or dexterity (left-/right-handed, big/small fingers, etc). Allowing the user to set keys would be much more innovative and user-friendly. Added in AW 3.4!
physics: The only physics modelling AW has is avatar gravity, friction, and momentum, and limited avatar-object collision detection.
1. collision detection
  1. avatars: From Roland (edited): "Avatar collision detection is checked against an oblong cube 1m wide (x-axis) by 1m deep (z-axis) and the same height as the avatar." So <1m³ avatars are limited in x- and z-axis collision detection and will "physically" collide before visually colliding, making it impossible for rat avatars to scurry in oil drums and garbage cans, for example. Active Worlds should just use the avatar's bounding box instead. Avatars can't "bump" into other avatars (avatar-avatar collision detection) and avatars should be able to push objects and other avatars. Avatars and non-avatar objects should have defined mass (even a general, smaller-lighter/bigger-heavier model would probably be good enough).
  2. smoother: You may (or may not) notice that when traversing up/down sloped surfaces (like the "rolling" hills in Cubed world), your avatar bounces up and down instead of smoothly, gradually, gliding up or down the slope. This is due to the avatar's collision detection. It "steps" and recalculates the "settled" (non-moving) position once stopped ("step-sinking"). While this effect might simulate "walking" (poorly), it doesn't look right for non-walking avatars. Active Worlds should just have smoother avatar collision detection. Note: as of AW3 build 343, avatar collision detection is much smoother when walking up angled polygons, but avatars still "bounce" when going down angled polygons. Roland says this is due to gravity and not collision detection, so perhaps avatar gravity can be adjusted to look more realistic someday... Well, avatar gravity can be adjusted as of AW 3.4 build 445 but the bouncing is still present, so obviously this is not a gravity problem.
2. ~~jumping~~: AW really needs to become more gamelike/interactive, and one way to do that is being able to jump, say, in 1m increments (which could be configurable depending on how long the jump key is held down and if one is running). Added in AW 3.4! It's less than 1m (perhaps .5 or .6m) and because gravity isn't correct, jumping seems more like you're on the moon so I recommend setting gravity to 1.5.
3. momentum: When walking/running off something and keeping the back/forward key held down, momentum is somewhat realistically simulated by gradually curving your path down (though the curve arc should be relative to the avatar's speed: less speed, less curve). However, if the arrow key is let go while in the air, the avatar will fall straight down. This isn't realistic. AW should keep the momentum with or without the key held down.
  In AW 3.4+, momentum is even further reduced when flying because the avatar no longer continues moving in the direction of "thrust" (forward/backward movement) but instead always moves in the turned direction, which is annoying when trying to build or simply stay moving in a straight line while looking around (sightseeing, positioning, etc). AW 3.4+'s momentum is increased when an avatar is on a surface, but it's more like a lack of realistic friction (unless the surface is "icey"). Avatar surface momentum should be configurable and modifiable (perhaps based on a new "friction" or "momentum" action command).
4. turning: AW2.2- has one turn speed (regardless of frame rate): constant. This was very annoying in low polygon areas as one arrow press and you've turned almost all the way around. AW3+ allows use of the "Control" key to increase turn speed, but there should be a way to make it default and use "Control" for slow turning, for example; and proportional turn speed based on frame rate would be far more intuitive. Because AW tends to lag (low framerate) most of the time, a faster turn speed make sense. I use fast turning far more than normal turning. Plus, some keyboards don't like having 2 or more keys held down before the third key doesn't work (keyboard's I've used have clicked or beep through the system speaker when that happens). So by being able to set fast turning on by default I wouldn't have to encounter this annoyance quite so often (unless I want to turn slowly and move, for example).
  Also the rotation arc "step" size (how far the avatar turns each time left/right key is quickly pressed) should be customizable--reduceable so as to flow more fluidly and smoothly, or increased to allow for faster turning.
5. warp movement control: Control over an avatar while a warp is in progress; currently, AW takes control of the avatar, which can only be moved forward/back while the avatar is falling (if the warp pushes it up into the "air"). The physics don't look accurate here because of this effect either. Also, absolute warp shouldn't recenter the 3D view with each warp, unlike relative warp where the camera angle is left alone. Warp movement control would also allow for walking on objects that minutely increment avatar positions to simulate rotating floors around some amusement park waterslide rides, and escalators, conveyor belts, etc).

absolute custom color saving: The world features has an option to change the background color. This is a standard Windows color selection dialog but if a custom color is saved, it is saved so long as AW isn't quit, but if AW is restarted, the custom colors are gone and they must be either reentered (assuming you wrote them down) or found over again (which can be a pain, especially with AW 3.4's introduction of sky color gradients). AW should completely save custom colors. Added in AW 3.4 build 445!
~~configurable~~ ~~gravity~~: Since AW does use the term "worlds", AW should be able to have a configurable gravity velocity to simulate otherworldly environments (like the moon where gravity is something like 1/5th that of Earth) more realistically. AW only allows gravity to be completley disabled unintuitively by having no ground object, which shouldn't happen and instead a "gravity" checkbox used. Added in AW 3.4!
entrance control: Specify the citizen # and/or names of people who are not allowed in a world.
ejection window shouldn't hog input: When it's open, any other part of AW is unusable until the ejection window is closed. This is easily fixed by multi-threading, I believe; a simple, basic part of Windows GUI design.
ground object action commands: AW's infinite ground is unselectable in a world, which makes manipulating it kind of irritating, especially if wanting to apply action commands:
Terrain, new in AW 3.3, while selectable, needs to also allow action commands. Footsteps ("bump noise") can no longer be simulated without using invisible objects (which can be a pain to try and match to the terrain angles).
~~ground zero designation~~: All worlds have their ground zero (origin) at 0n 0e 0a. There should be a way to have custom ground zero coordinates like near a small world's corner or way up in the air or deep below the surface. Yes the world can be designed accordingly around 0n 0e 0a but it would still be a nice alternative to be able to specify a specific ground zero. Added in AW 3.3!
multiple object paths: More than one object path; for example, one could have the main AlphaWorld object path as a primary path, and then another object path hosted by the world owner for some custom objects, so all of AlphaWorld's objects aren't redundantly copied onto another space, wasting storage space and bloating AW's cache even more than it already is.
object refresh: First of all this should be called "cache refresh" or "file refresh" since not only objects are refreshed. AW currently handles "object refresh" by updating all of a world's cache (objects/textures/sounds/SEQs) refresh by a "minutes" field in the world features options. If the limit is set to, say, 0 minutes, not all objects immediately begin refreshing. In the past, only after moving into another cell did the other files begin refreshing, but now (screwed up somewhere between AW 3.4 and 3.5) you must teleport out/back into the world. Still, this whole process isn't very intuitive since after the refresh is set back to a higher value, and someone enters the world, they won't get the refreshed cache until their AW reaches the current object refresh limit.
A better idea for this whole process would be to set a "dated refresh flag" on any updated (changed/edited) object, texture, sound, and/or SEQ which would trigger AW to redownload that particular cache item instead of just arbitrarily redownloading everything within view. At the very least there should be a way to refresh a single file without having to refresh all objects within visibility. Such a feature would make updating objects much more quick and keep object creators from going insane waiting for most other files to refresh first!
owner/caretaker designation: A way to show visitors who owns/caretakes a world in case they are interested.
skybox: It'd be nice to be able to set the skybox to rotate (move) like the cloud planes. And if there was an RWX corona command (or if full axis-alignment was reimplemented), a sun sprite/corona could be a part of a skybox that could rotate very slowly, simulating a day-night light cycle (in conjunction with a bot to control the light source, of course).
world feature color linking: A way to link colors with various world features (background image, skybox, sky color, cloud layers, etc) that would automatically change the color would be more intuitive. Currently, a bot must be used to do this.
world server
1. GUI (graphical user interface): While AW 3.1 introduced a GUI administration tool, which makes managing worlds easier (start/stop, propdumps, proploads, etc in a much more user-friendly GUI rather than from a command-line interface as in DOS, Unix shells, etc.), it could still show current user(s) and sort events by user, the heartbeat (no longer present, but the DOS server scrolls the heartbeat every x seconds--a single, updated line would suffice), allow non-resetting scrolling to check past log.
2. logging options
  1. heartbeats (they really waste a lot of space)
  2. log statistics: # times users log in, average time per session, etc—like BBS (bulletin board system) logs provide
zoning: Restricting someone to only build in a specific zone (area). A portion of a world could be selected perhaps by setting at least three (but up to however many the zoner wants) zone markers (objects marked for zone designation) and marking the area inside to a specific citizen #. A citizen without that number wouldn't be able to build within this zone, except for the world caretaker(s) and people with eminent domain of course.

^ Top
< Back