I was recently trying to use gcc from Terminal on my Mac. My path was set up properly, and I had used gcc before without any problems.
When I upgraded to Snow Leopard, apparently the upgraded developer tools were not installed. To solve the problem, I had to run Xcode.mpkg in the “Optional Installs” folder on the Snow Leopard installation cd.
The DebugOverlay utility is a class that I’ve been using in my XNA projects for a while. It allows me to draw visualization objects from anywhere in my application – even in separate threads.
Some areas where I have used this utility are:
The AI system can display a units’ velocity and position through Lines, Arrows, and Spheres. Use ScreenText to show the current state or goal hierarchy of a given unit.
The Physics system can use bounding boxes and spheres to show collision volumes. Points can be used to show raycast intersections or points of impact.
The Graphics system can use Spheres, Lines, and Arrows to show the position and direction of lights.
The Editor (or other tools) can use Lines, Arrows, and Bounding Boxes for axis representation during translate/rotate/scale.
Vertex Display – For a software-based skinning implementation, I used Points to visualize the locations of my vertices, and Spheres for the locations of the bones. It’s possible to use Spheres for everything, but thousands of Spheres can get a little expensive.
This utility is only meant for Debug purposes, and therefore uses the [Conditional("DEBUG")] tag on each of it’s exposed methods.
To use the DebugOverlay, create the object during Initialization:
1
new DebugOverlay(GraphicsDevice, Content);
Call the visualization functions from anywhere in your code:
1
2
3
4
5
6
void ScreenText(string text, Vector2 pos, Color c)void Line(Vector3 start, Vector3 end, Color color)void Arrow(Vector3 start, Vector3 end, float arrowSize, Color color)void BoundingBox(BoundingBox boundingBox, Color color)void Point(Vector3 pos, Color color)void Sphere(Vector3 pos, float radius, Color color)
In your Draw routine, call the DebugOverlay.Draw method, passing in the projection and view matrices:
The article entitled Towards a Critical Aesthetic of Virtual-World Geographies, focuses on the first few years of EverQuest, when it was still a game very much oriented towards the hard-core player. It was an extremely dangerous world, with harsh and unforgiving penalties (corpse runs!). Without many of the forms of instant travel that appeared later in the development of EverQuest, the continuity and spatial layout of the world was preserved. It took a long time to get from point A to point B. Because of this, there were secluded areas that were hard to get to, and there was a real sense of a large, dynamic, and truly epic world. This brought rise to trade and economic systems that closely mimicked the real world.
In EverQuest and other online worlds, the game designer and the player indirectly work together to shape the geography of these virtual playgrounds. Geography, as described by Wikipedia, is split into two main branches: Physical Geography and Human Geography. In the case of EverQuest, the designers physically create the world, and are therefore responsible for the physical geography (walls, terrain, building placement, etc). The players are the inhabits of the world, and are responsible for the human geography (social, cultural, and economic aspects).
Through the course of the article’s analysis, I came to understand why players often established their own trading outposts in areas such as the East Commonlands Tunnel, Greater Faydark, and North Freeport. Although these locations may be very different from where the designers intended them to occur, they have a root cause that ties back to the original game design.
East Commonlands and Greater Faydark are both easily accessible via druid and wizard low level teleport spells. North Freeport is a little farther from it’s closest teleport location (West Commonlands), but it has a bank, and is easily accessible by both good and evil races (via the sewer system).
Although I am only pointing out a very specific example (ad-hoc market creation and trading in EverQuest), it sheds light on much broader concepts of migration and human interaction in the real world.
There is never any explicit consent or agreement from the players as to where to create these ‘hubs’ of interaction. Creation is driven unknowingly by the player and the player’s necessity. This creation process is guided (also sometimes unknowingly) by the rules that the game designer has created, and which are governing the world. These ingredients serve to create a truly living and dynamic virtual world.
* * * * *
I will end, in tribute, with an extremely nostalgic video – the original EverQuest intro video.
I learned of a new program today, called FreeMind. FreeMind is a cross-platform, open source, mind-mapping application. It looks like a great tool for both brainstorming and conceptually solidifying ideas. It also can be used as a convincing presentation tool, visually showing the flow of data and information to the audience.
This recipe was originally inspired by the VahRehVah website, and the corresponding Youtube video. There are some great recipes there, but I think some of them are slightly more complicated (and spicy!) than they need to be. I have made some modifications to the original recipe, and posted my version below. Notable differences include the omission of green chili, some whole spices (I prefer powders, in general), and the inclusion of yogurt.
During the first semester of working on NitroX and Artemis Chronicle, our design and content pipeline was very slow. Simple things like creating a level and placing a box were arduous tasks. Placing an item involved flying the camera around the level, writing down it’s rough coordinates, hard coding the coordinates, and then tweak these values until the box is in the desired position. (Thankfully, we were using C# which pretty much eliminated any compile time. Doing this in C++ would have been impossible).
This created a situation where we were unable to prototype levels quickly, and time that could be better used somewhere else was being wasted.
Because of this, I devoted the first few weeks of the second semester to full-time tool development. Two of the more useful tools created are described below. These tools, once created, were continuously used and refined throughout the entire life of the project.
Level Editor:
Artemis Chronicle and the NitroX engine have a completely integrated level editor. The editor allows 3D navigation through the world (using Maya camera controls), object placement (translation, rotation, scale), object property exposure (including physics volumes), trigger volumes (used for scripted events), and interactive camera sequencing (allows us to create cut-scenes and cinematics in a point-and-click fashion instead of in code).
The editor runs on Windows and is written in C#, allowing for close integration into the XNA content pipeline. The editor data is serialized out to an XML format (which is later compressed for application deployment), sent through the content pipeline, and imported directly into the NitroX engine for use on both Windows and Xbox 360.
Mesh Viewer:
The Mesh Viewer is a tool that lets our artists quickly preview their work before sending it off to be integrated into the latest build of the game. As anyone who’s used the FBX exporter knows, exporting from Maya does not always go smoothly, so this tool allows the artist to catch any errors early, thus saving time for the entire team.
Animations can be chained together to create sequences, and then previewed in a real-time manner. Playback speed, blending parameters, and looping can also be adjusted via the user interface.
