Fundamentals of Level Editor Design and Implementation

Introduction At the end of this lecture you will be able to: –Know at a high level what game levels are –Understand how game levels are designed and built –Understand the motivations behind a level editor –Understand the basic functionality for simple level editors –Learn some fundamental design and implementation details behind some of these basic functionality

References MOGREhttp:// MOGRE

Game Levels Why do we need Game Levels? –Provides variety in gameplay –Provides staged and periodic sense of accomplishment –Aids immersion in story or virtual world –Advances storyline What is a Game Level? –A separate area or setting in a game’s world –Consists of a unique arrangement of the game objects and environment to present a different challenge and/or experience of the game world to the player

How Levels are Built A level design is created and documented The functionality of game objects and the mechanics of the general gameplay are implemented in code Art assets are created for the game objects For integration purposes between art and code, placeholders are created on both sides A level builder integrates with some of the game engine code and has access to the store of art assets for game objects

How Levels are Built The level is implemented by using the level builder to organise and integrate game objects together into a level. The level is QA Tested within the game Refined and retested Ready for release We are going to focus on the actual implementation of the level based on using the level builder tool

How Levels are Built Constituents of a level depends on the game, but can include: –Level geometry –Player spawn points –Enemy positions –Obstacles and traps –Collectables and power ups –Boss positions –Triggers and events –Scripted scenes –Lights –Interactive prop placements –Etc.

Goals of a Level Building Tool Minimise programmer involvement for creation and integration of game content Allow for tweaks to the level to be quickly implemented and retestable Flexibility and extensibility (for the addition of new content) etc. Possible reuse for later developed games

Goals of a Level Building Tool Possible release for public use – for user created content and mods GUI usability and user friendliness Also provides indication to publisher of current state of gameplay, or planned gameplay mechanics if only placeholders are available and used

Functionality Robust – especially if to be released for public use Maintains data integrity – want to avoid data corruption and incompatibility between versions of the game engine and tool etc. Adheres to game interfaces. –Serialisation of in-game structures Graphical performance not as high a priority compared to in-game performance

Functionality Some typical functionality: –Multiple viewports with different points of view (orthographic front, side, top, perspective) –Appropriate camera movement within viewports –3D Picking –Object selection and placement –Object movement and rotation –Multiple object selection and movement –Saving and loading –Keyboard controls re-mappings

Geometry Editing Consider: –Advanced support within tool: polygon and 3D volumes creation texturing vertex editing Constructive Solid Geometry ( CSG ) –Partial support: Basic 3D volumes ( spheres, boxes etc ) –External importations: From 3D packages ( Maya, 3DS Max, Blender etc ) –All of the above

Design and Implementation The following slides will discuss some design and implementation aspects of some of the basic functionality of a level editor

Multiple Viewports Create separate MOGRE render windows Associate each with a handle for different Windows controls For each render window, create a viewport and attach a different camera Set the appropriate camera properties to reflect the viewport type (e.g. projection type, position and orientation, render style – wireframe, solid etc )

Multiple Viewports NameValuePairList misc = new NameValuePairList(); misc["externalWindowHandle"] = this.Handle.ToString(); mRenderWindow = m_Editor.Root.CreateRenderWindow("RW" + mCount, 800, 600, false, misc); mCamera = m_Editor.SceneManager.CreateCamera("Came ra" + mCount++); mCamera.AutoAspectRatio = true; mRenderWindow.AddViewport(mCamera);

Multiple Viewports switch (type) { case OGREditViewType.PERSPECTIVE: mCamera.ProjectionType = ProjectionType.PT_PERSPECTIVE; mCamera.PolygonMode = PolygonMode.PM_SOLID; mCamera.Position = new Vector3(0, 200, 0); mCamera.LookAt(new Vector3(50, 170, 50)); break; case OGREditViewType.SIDE: mCamera.ProjectionType = ProjectionType.PT_ORTHOGRAPHIC; mCamera.PolygonMode = PolygonMode.PM_WIREFRAME; mCamera.Position = new Vector3(-1, 0, 0); mCamera.LookAt(new Vector3(0, 0, 0)); mCamera.FOVy = m_FOVy; break;

Multiple Viewports Consider the following features: –Multiple Document Interface – sub windows –Ability to dynamically change the viewport type –For the perspective viewport, being able to change the render style ( solid, wireframe, textured, lit etc ) –Drawing grid lines

Camera Controls Allows the user to pan, zoom, and rotate the camera independently in different viewports Not all controls may be applicable in all viewports – eg. No rotate in orthographic views Attach the appropriate mouse or key event handler to the control / form containing the render window this.MouseDown += new MouseEventHandler(MouseDownHandler);

Camera Controls MouseDown, MouseUp and MouseMove events can be used in conjunction for the detection of dragging operations with the mouse Use the appropriate KeyEventArgs or MouseEventArgs to determine what state the mouse / keyboard is in Use Cursor.Position to determine the current cursor position ( in screen coordinates ) Alternatively, the.x and.y properties of the MouseEventArgs gives the current cursor position relative to the control Use Control.ModifierKeys to determine whether any of the other CTRL, ALT, SHIFT etc keys are being pressed

Camera Controls Zooming in orthographic view should be implemented as a change in the camera’s FOV proportionally to the change in mouse Y coordinates, rather than ‘moving’ the camera forwards or backwards Rotation in the perspective view can be implemented as yawing and pitching the camera proportionally to the change in the mouse’s X and Y coordinates respectively

3D Picking Picking – when the user clicks on the screen, convert this into a 3D ray which can be used to check for collision with objects in the 3D world Supported under MOGRE with a simple call to: GetCameraToViewportRay Parameters are in 2D screen coordinates (i.e. [0,1] x: left to right, y: top to bottom ) Can use the.x and.y properties of the MouseEventArgs divided by the width and height of the renderwindow’s parent control

3D Picking A RaySceneQuery can be constructed from the picking ray and executed to return a list of objects colliding with the ray within the scene The collision test with the ray is only performed with the objects’ bounding volumes only, not on detailed a mesh face level Note that different scenemanagers may implement their scene queries differently The TerrainSceneManager requires the origin of the ray to be over the top of the terrain in order to register a hit

3D Picking void MouseDblClickHandler(object sender, MouseEventArgs e) { float clipx = (e.X / (float)this.Width); float clipy = (e.Y / (float)this.Height); m_RaySceneQuery.Ray = cam.GetCameraToViewportRay(clipx, clipy); RaySceneQueryResult result = m_RaySceneQuery.Execute(); for (RaySceneQueryResult.Iterator itr = result.Begin(); itr != result.End(); itr++) { if ( itr.Value.worldFragment != null ) {..} else if ( itr.Value.movable != null ) {..} }

3D Picking Two types of collision results: movable and worldFragment WorldFragment indicates collision with the world geometry. Can inspect property: singleIntersection to get the exact intersection coordinate Useful for marking a point on the level geometry for further processing ( placing spawn point etc. ) movable indicates a possible entity whose bounding volume has collided with the ray – can work with this further to mark this object as ‘selected’

3D Picking Other Considerations: –.SetSortByDistance() method, sorts all results based on distance collided with ray –QueryMask and QueryFlags – set QueryFlags on entities so that only those which pass the QueryMask on the ray query will be returned in the results list ( uses bit OR operations )

Lecture Review Know at a high level what game levels are Understand how game levels are designed and built Understand the motivations behind a level editor Understand the basic functionality for simple level editors Learn some fundamental design and implementation details behind some of these basic functionality