For the release of Away3D 3.6, together with Influxis, we've builded a realtime 3D multiplayer prototype from the ground up.
You can read more here on away3d.com. I'm not a good writter, but I've tried here to explain a bit more in depth some aspects of the building process that might help you if you decide to build one yourself.. (or not)
I have done a few FPS projects using the BSP feature of the engine already, but so far, none of them were as extended as this one. The goal was to test stress a bit the capabilities of the engine, Prefab and the new player. The plan was to build a huge map just to see how far you could go. I was not certain if Prefab would stand the experience. If the player would be able to handle that much data and pretty unsure it would run at all in combo with the P2P API..
Having no material to compare but my previous projects, I was also curious about how much time would be involved. With only 2 1/2 weeks left before my planned summer vacation, the demo was supposed to be showed in Mineapolis, USA, 4 weeks later. Time to get started.
The prototype
You probably already have tried it by now and saw that it turned out pretty well. Tho there are still some processes between the P2P and the 3D generating slowdowns sometimes, especially on the mac side. The mapping is not 100%, some maps could use improvements etc... Its a prototype.
Considering all is done in the evenings in just 4 weeks, I'm very happy with the results of this prototype. I want also compliment the Flash player devteam, they really made an amazing work on this release.
Where do you start exactly?
If you plan to build a similar project, first thing to do is to make some tests before make the jump. Just to become familar with Away, Prefab and the BSP specific coding. Modeling for BSP technic is not complex, but there are rules you must follow. If you don't, chances are high, you'll never pass the generation step in Prefab.
You can read some of them on David's blog and on our dev group.
Planning
Probably the most important step: plan your work! Both on the map and designs.
Building a complex map, becomes quickly very hard to model and art impressions/sketches are very welcome. In this case, I've started collecting images on google related to tunnels, concrete, prisons etc..
Once my mood board was ready, it was time to define the map. So a bit like an architect, I've defined the layers into Illustrator, made some sketches on paper. I say, "bit like", because since it's a shooter game, the way you think of a building must not reflect the reality at all. Having real building ideas does lead to lots of dead ends, low ceilings, single doors rooms, equal levels... instead, you need think more in term of escapes, strategy. The gameplay and map features are also affecting the map. Such as power lifts and transporters seen in this project. They should exist into your blueprint.
Of course it's always possible to modify or add while you model, but in practice, it turns often into a painful task. So again, do not skip this step, invest in the "thinking" work before start anything.
Modeling
The modeling on itself, as said above requires some experience, but in case of extended maps like this one, it's important that you take an extra care during the build. As you can easylly forget to close a hole, invert a face normal... Finding these later on can be very tedious. Make sure you have your grid set to coarse, that the "snap to grid" option is on. As the tree must remain as simple as possible for best results, ask yourself all the time: if it can be named floor, wall, stairs or ceiling, then it's likely it should be part of the tree. If not, items such as doors, tables, chairs etc, should be added to the tree later on. Consider as well to add geometrical complexities later on like ceilings details, detailed windows etc... At this stage, you will really appriciate your blueprint as the model becomes very quickly a series of enclosed shapes sometimes difficult to inspect/access or even identify. You might also hate yourself if you have not prepared the blueprints properly 
During the build, it's also a good idea to export and inspect the model into Flash or Prefab.
For this project I've used AC3D, which is in my eyes one of the best 3D editor around. After the demo was done, I've added .ac file supports (import/export) to both Away3D and Prefab3D. Wish I did this before
Texturing
Then comes the texturing. During the build, if you plan to use Prefab, make sure you to define the map as a series of meshes. Project the uv's on each part and make sure they are not overlappings. If you plan to use tiling, it will have to be defined in your Away3D project later on. (Prefab3D is not able to prebake this kind of mapping)
You do not need to work with real texture, but you should use a few tmp textures of different colors which help greatly to spot eventual uv mapping errors. It will help you visually to identify the rooms, as it can be confusing at times.
Once the map is done, simply load it into Prefab, make sure the bounderies of the model are between 20 and 100k (rule of thumb based on my previous experience), if not, rescale in your app or Prefab. Open the generator window, set the camera properly and hit the btn...
At this stage if errors or warnings are triggered, look at the region defined as a red cube in the main window (if you close the generator window, this red region will be cleared).
Inspect highly zoomed in outline mode your model in your editor and make sure there are no holes. Repeat. The generation is pretty much a smooth ride from Prefab, look at the video from my previous post to see it in action.
Prefab3D
With over 220 maps mostly at 512x512 sizes for the tree only (+- 250 for total project), Prefab was simply reaching its limits. Only fast rendering was possible. Memory demand was so huge (440 maps in total, original + rendered), raytracing rendering was simply not possible in one pass. At this stage, if you haven't done it yet in your 3D editor, it's a good idea to rename each parts with good names, as they will be the only way for you to access/edit the materials later on at runtime, via the CentralLibrary class.
Yeah! First Export worked!
Once you have successfully generated and exported (as+awd files), you can now make your first steps into your world. Before start build the textures, do the prebaking etc... make sure everything's ok, try go to each and every corners, place to see if you get stuck. In many cases, the camera bounds are related to these problems. In case your camera box is tiny and you still get stuck at a certain place, go back to your original model and try move the vertexes representing the plane so that they are no longer parallel by just a grid increment. I can happend at T junctions.
If you want to use Prefab raytracer, a work around would be to slice your model per groups of rooms, and render. Then use these maps for the final model. I hope be able to improve some internal processes in that regard in future releases.
You are not there yet
After days of work, you have successfully imported your precious data into away and you are finally able to enter your world. finetuned the camera bounds, tested the collisions, it all looks pretty...
Now what?
So far, only the geometry, designs were made, its time now to code the game itself...
I will not extend much on this as its a per case thing. For the prototype, as we wanted to build a shooter, you need of course guns. So I've wrote a "projectile factory" for this. Basically since we wanted to have different sorts of weapons, polymorphysm was the way to go. By pressing the "e" key in the demo you can toggle runtime 2 types of weapons. I was running out of time so I haven't added more, but you'll get the idea. (I might even post the sources if there's enough animo)
David helped me a lot to implement new features for impact detection, uv retreiving etc.. to the BSP package that should allow you to easylly access this kind of information. In parallel David also improved a lot the way dynamic objects are handeled by Away. In short, without David, this demo would simply not run at all!
On the P2P side, Sean, was busy writing the final pieces to his API, and Rob was busy implementing the update events from the Battlecell P2P API on the weapons and avatars hooks that I've had previously written for that. At this stage, I was only just a few days from a well deserved vacation, so Federicco came to the rescue and took over the modeling and animation of the Avatar, helped me build few extra textures, made a beautifull splash screen and updated the previous interface overlay as Rob needed a scalable version not knowing what res the beamers would have for his presentation.
The Avatars
if you are familiar with BSP technics, you probably know that moving an object into the nodes of a BSP tree means that it needs to be tesselated at runtime. The avatar being an animated model having even as low poly as +-150 polys, if you have a few of these running around, it can have a desastrous impact on the perf.
If you have made a room, and entered it with another player, if you come closer to the avatar of your enemy you might notice some pixelly look if you get near of it. In the practice, noone remarks it, because if you come too near, its most likely you will be killed before you even notice anything!
So the answer we gave to this problem was to add a single 2 triangles plane per avatar facing the camera at all times. Then draw onto the plane texture the avatar model considering its animation state and projecting it with both its transformations and the camera point of view. All this magic is signed by the master of matrix Rob himself. You can really measure how smart and efficient this solution is, if you have seen the before and after. Trust me on that.
That's pretty much all the process we went through in big lines.. feel free post a question if you have some.
oh yes, like Steve would say: one more thing. If you are a "company", make sure you do work with people knowing their stuff. If not, you might enter hell instead of your 3D world... Even if we did it in just 4 weeks, all having different schedules and activities, its very easy to spend way more.
This was a pretty long post, I just hope that despite my lousy english, this article has brought bits of light on some of the aspects of building such project using Away3D. It shouldn't be very different using other engines/tools tho.
The keys
It's not on away3d.com, so here are the keys in case you haven't discovered them yet:
e, toggles the weapons,
wasd or keys up/down/left/right moves you
q or j to jump
space to fire
shift to run
and mouse press to rotate. (the Mouse class doesn't give us more option)
In order to log in with someone else, use a room name such as away3d1 or away3d2...
Note that for this prototype, you can have only 4 avatars per room.
Recent Comments