Introduction

In the previous article, I've created a simple 2D map editor with the result being a two-dimensional array. That's indeed a crude product - there is too much worth improving. Starting from this article, I'm going to introduce to you an excellent 2.5D RPG games scene editor - RPGSceneEditor targeting Silverlight and Silverlight for Windows Phone 7.

By digging into the scene editor to be introduced in this article, you will find a map editor is hidden inside the scene editor. And especially, by the end of this series you will be sure to conclude that this scene editor is more than a scene editor. With a further slight modification with this application, you can easily build up some real RPG games.

Why Introduce the 2.5D Scene Editor

When I first started to write a 2D game targeting Silverlight, I surfed the Internet to try to find an excellent 2D map editor. Finally, I found one - Silverlight 4 XNA Platformer Level Editor for Windows Phone 7 at MSDN blog. Figure 1 illustrates one of the running-time snapshots of this level editor.

Figure 1: David Rousset’s level editor targeting WP7

For the simple cases, David Rousset's level editor is enough to use. However, in complex cases, such as cross-screen requirement, 2.5D game perspective, this level editor shows powerlessness. On the other hand, David Rousset's level editor has not provided changeable support for sprite's size. These are part of the reasons that our game scene editor comes into being.

About MMORPG and RPG and 2.5D perspective

MMORPG is short for massively multiplayer online role-playing game it is a type of game genre. MMORPGs are online role-playing multiplayer games which allow thousands of gamers to play in the game's evolving virtual world at the same time via the Internet. In our case, we will mainly pay attention to the simple form –RPG. In either case, the popular game scenes mostly leverage 2.5D perspective with 2D programming or directly 3D techniques. Figure 2 shows a game scene based upon the typical 2.5D perspective.

Figure 2: A typical 2.5D game scene

Our game scene editor just targets RPGs. Next, let's take a look at what tasks our final game scene editor can accomplish.

Visualizing the Finished Line

In these six months time, I have been pondering such a question: how to make RPG or SLG, and similar types of game development much easier, easier to understand. Apparently, this work has to originate from an architectural perspective, object-oriented thinking pattern, etc. In the end, the rough scene editor came into being! What on earth can this application do? Let's next take a look at some related running-time snapshots.

Dynamic scene coordinate system

A dynamic scene coordinate system not only can simplify the traditional ways of constructing game scenes by splicing tiles of pictures, but also make a game based on different scenarios with different inclination and random cell size - arbitrary gradient structure of the game can match the perfect masterpiece of artists.

Figure 3: The dynamic scene coordinate system supported in our work

Have you noticed the floatable window at the right? This is the key point in our game scene editor, with which we can adjust nearly any parameters we are interested in until the map is compatible with our requirement.

Contrary to what you expect, when you change the coordinate system inclination into zero, the map will become once again the commonly-seen 2D form - the familiar Cartesian coordinate system, as shown in Figure 4 below.

Figure 4: Our game scene editor also supports standard 2D coordinate system

Yes, this is the most important function of the scene editor: dynamic coordinate system. Starting from next section, we'll detail into some aspects of the scene editor.

Make the coordinate system cross the entire game scene

Now, another question arises? Can we make the coordinate system cross the entire game scene? Yes, of course. In fact, what we just need to do is translating the coordinate system horizontally and vertically.

On the whole, there are two options to fill the entire game scene by the slope of the coordinate system. The first solution is shifting the center of the map coordinate system, by setting the appropriate cell size and two-dimensional matrix of size, plus a slight adjustment to the slope of the coordinate system. This kind of game is very much abundant. Take the latest Chinese masterpiece of the "Magic Crystal Fantasy" game for example (see Figure 5). The oblique angle based checkerboard battle scene perfectly inherits the royal blood of traditional SLG games, orthodox and exquisite without saying word.

Figure 5: Battle scene - classic SLG model

Next comes the second option. Our idea is making the matrix map always stay inside the internal of the slope coordinate system, so that the sprites can reach any corner of the map. And as imaged, by adjusting the offset of X and Y, we can easily achieve something like the layout as shown in Figure 6.

Figure 6: The matrix map always stay inside the internal of the coordinate system

3D support

Silverlight has now provided built-in 3D support for all UElement elements. The corresponding manipulation only needs a few lines of code. We've also added this functionality to the scene editor, as shown in Figure 7.

Figure 7: 3D support for the scene editor

Proudly, regardless of how the scene is transformed, the sprites can accurately move to the target grid where the mouse moves. Even more interesting is that, because it is 3D transformation, unlike the 2D translation, whether the cell or sprites, all of them do not act the same with different distances.

Multiple patterns support

Another noted feature of the scene editor coordinate system is that it supports multiple reference systems, None, Grid, and Box. Any of these three modes can switch freely between each other. When we select the Box mode, we can see a more intuitive form of the game scene, when the scene seems closer to the turn-based game engine.

Figure 8: Multiple reference systems support in the scene editor

A* path finding support

In our game scene editor, the sprite moving mode can switch between the pure A* path finding mode and the intelligent mode. When you move the sprite around the brick red areas in the map you will be sure to find one of the beauties.

Figure 9: A* path finding algorithm support

As you've seen, by only modifying one parameter can we switch the map between the two modes. There is only one goal to make the scene editor more flexible, all targeting making it easier in the game development.

Architecting the Scene Editor using OOP

All owes to the plentiful Silverlight form-based support and OOP technique. Now, with the scene editor ready, you will see that we just need a single line of code to set up the scene, and another a line of code to create the sprite, as well as automatically add it to the scene. Believe it or not; refer to the following code.

The OOP power

All along, I keep thinking about how to make Silverlight simpler in the real game productions. One of the most important reason making the scene editor simpler to create and more powerful to use should owe to the object-oriented programming technology. The fundamental structure of any object in the biosphere can be described via a three-dimensional space plus one-dimensional time. Hence, we can construct an abstract game base class – GameBase with at least the following properties:

In the above code, we define the coordinate type as the Point type so as to let it compatible with Silverlight Storyboard-based animations. In addition, as a virtual property, subclasses can choose whether to rewrite their own specific needs.

In addition, we should also give the "object" an external "body" to accommodate the other components, so that we can visualize it:

Canvas is a very good choice. Compared to the Image, it has the same excellent Background property for the "physical" picture show. In contrast to Grid, Canvas similarly inherits from the Panel container control, which can easily accommodate the layout of all objects in the body anywhere. My overall rating toward Canvas is: ultra-thin, lightweight, simple but not simple.

Finally, we should also create a helper method GetImage to get the outer pictures, as listed below.

This method specifies the picture download mode. Of course, as a virtual method, any "object" of the subclass can also be rewritten according to their own needs. Here is a simple example: if I want to use only a legend to act as the indicator before downloading all 56 frame sequence related images, I can rewrite the GetImage method, using WebClient or any other means to implement the relevant logic behavior. As long as we carefully control the whole process from downloading the resources to the related rendering mode, it is still simple to set up the GetImage method, which will be introduced in the next article.

Next, I will introduce the game's most important one-dimensional 'time'.

In the real world, the "objects", broadly speaking, can be divided into "dynamic" objects and "static" objects. Only the "dynamic" objects will take the initiative to interact with time, while "static" objects will not change without external intervention. Back to the game world, the most representative "dynamic" object should be the well-known wizard (Sprite), widely existing in various forms of all games.

Figure 10: The household sprites in many games

As for the "static objects", they are also essential for every game, the most representative of which should be HUD. What is HUD? The full English name is "Head up display". In video gaming, the HUD is the method by which information is visually relayed to the player as part of a game's user interface. It takes its name from the head-up displays used in modern aircraft. The HUD is frequently used to simultaneously display several pieces of information including the main character's health, items, and an indication of game progression (such as score or level). It is a bit abstract, isn't it? Well, let's take a look at the diagram as shown below.

Figure 11: The HUD gadgets in a popular shooting game

The picture shows the typical usage of HUD; the three panels in the red box areas are right the HUD, whose most outstanding feature is it is always in the forefront of the game show; and that the data is updated by the impact of lead-related information rather than themselves. For example, the leader shot consuming bullets, when the related data will be submitted to the bottom of the HUD to update the display of the number of bullets. Similarly, the protagonist constant moving, changing direction will thereby trigger the update of the radar map data at the upper left corner, and so on. As to how to achieve these related triggers in Silverlight, we can define the relevant delegates and events within the sprites, to be discussed in the subsequent articles.

Back to the topic, we can therefore create two subclasses, DynamicObject and StaticObject, inherited from the abstract base class GameBase. According to the foregoing analysis, only DynamicObject has the concept of time; in Silverlight, I prefer to use DispatcherTimer to describe this one-dimensional time. The advantages lie in that we do not need to consider any cross-thread related issues; and also, through the DispatcherTimer's Tick event, any activity of the object will be presented directly by the game world, as a heart, every strong beat showing the existence of life.

Up till now, a very, very simple while highly versatile scalable game underlying framework is born. In the future, whether you will add, for the game, "dynamic" sprites, magic, and the scene, or "static" ones, such as Window, FloatableWindow, HUD and other objects, what we just need to do is to make them inherited from the corresponding DynamicObject or StaticObject. According to the actual needs of different types of game design, we can seal some classes, such as the scene (Scene) that will no longer be inherited, to improve performance, while continue to make the sprite class (Sprite) abstract and derivable, to further derive the other entity subclasses, such as Leader, NPC, Monster, and so on. All these owe to the advantages of OOP.

Now, let's take a look at all the entity classes introduced in our case, as shown in Figure 12 below.

Figure 12: The hierarchical inheritance relationships between the classes we are interested in

In fact, there are a variety of ways to construct the underlying game structures. You can target more specific objects or define some wider abstract. In addition, the underlying game framework must also be built accurately on what game types you want to develop, as well as concrete manifestation of forms. Only do you accurately grasp the common features of the elements in the game and the inextricable links between the various elements, can you set up a strong foundation for the late game development. Like a building, the foundation determines the quality of how high it can reach, as well as the lifetime and the ability of anti-disaster.

Summary

In this article, we have made a rough description of the game scene editor. You've visualized some of the running-time snapshots of the application. Especially, with the help of skillful design and object-oriented programming, the scene editor becomes pretty easy to manipulate. In the subsequent article, we will further research into the developing techniques in the game scene editor.

About Xianzhong Zhu

I'm a college teacher and also a freelance developer and writer from WeiFang China, with more than fourteen years of experience in design, and development of various kinds of products and applications on Windows platform. My expertise is in Visual C++/Basic/C#, SQL Server 2000/2005/2008, PHP+MyS... This author has published 81 articles on DotNetSlackers. View other articles or the complete profile here.