Framework for Game Engine Tools
Tuesday, March 23, 2010
Update
in Framework for Game Engine ToolsThe level editor downloadables can be found here:
Level Editor Executables
Code Documentation
Several files, merged the C++ side documentation with the Nebula 3 one. Level editor info found in nebula3.chm -> Namespace list -> LevelEditor
Tool Framework Implementation Guide
Did one last update to the interface to remove some clumsy buttons.
Monday, March 15, 2010
Main Features Done!
in Framework for Game Engine ToolsI have just finished all main features for my level editor. Here’s a 2:45 minute long video displaying its features:
I know it’s silent, I couldn’t find any (decent) copyright-free music :/
The main features include:
Object management: Create, Delete, Translate/Rotate, Duplicate - All of which are undoable.
Create new, save & load level.
Next up is implementing a small game that uses the saved levels, and finishing all other requirements till MS3.
Monday, March 08, 2010
First Look
in Framework for Game Engine ToolsI’ve now implemented most of the groundwork and undoable create/delete actions. With some test buttons my level editor currently looks like this:
Tiger-tank truck!
About a week ago I sent a mail to Floh and asked him to clarify how he wanted the command system to be designed. In his answer he told about extending their NIDL system to generate both C++ and C# code, and then send serializable message objects between the two sides. As I have to get a usable level editor until the last milestone, I have already implemented my own design for the message/command system. It won’t meet their standards, but it will get the work done.
Though my goal is to code something that can be used for the Nebula 3 system. So I’ll aim to finish my level editor with base functionality and meet my requirements till the last milestone, and then start anew implementing his solution. I won’t have much time then but I’ll try to get at least the communication/messaging part done.
My current implementation looks like this:
There is three threads working, the main thread for user interface (View), one for receiving/sending data through the network (TcpConnection) and the last one taking care of received data in the inbox (MessageParser). The message parser will only manage thread-safe containers to avoid collisions.
Actions and commands will start through the user interface controls, and then be executed or sent to the Nebula viewer.
At this side it’s mostly interface controls that I haven’t implemented.
Here I got just one extra thread for the communication except for the viewer application threads. This part mostly just awaits XML commands from the C# tool, and then let the CommandHandler extract and forward the data to its respective instance for processing.
What I haven’t coded here is the LevelLoader and some ObjectManager methods.
Monday, March 01, 2010
Additional work and reprioritizing
in Framework for Game Engine ToolsWhen redesigning my parsers to more easily read and write xml text, I realized that my current command structure is incomplete and partly incorrect. As it is now, both the C++ side and C# side got their respective set of commands along with a command handler (my original idea was that the command sets were to mirror each other). This is incorrect because it is the level editor interface side that is supposed to give the commands and the Nebula 3 application will mainly receive and execute them. The N3 app will still send messages as data to be stored, eg. undo data or a list of models.
I’m going to remove the C# side command handler and container and instead write commands through the xml parser. All available commands will be defined in a xml document with their respective input, that the parser will use when writing a message - this should be more according to Floh’s idea.
Last week I implemented and finalized the connection classes so the communication is smooth and problem-free. I also implemented some base interface features for debugging and set up the synchronized start/stop of the level editor and nebula viewer. I had planned to start on the actual level editor features at the beginning of this week but I’ll have to postpone that a couple of days as the above tasks appeared. Those tasks have a higher prio as they are a prerequisite for the object creation/editing actions.
With only three weeks left I’ll have to exclude some features. I won’t have time for the object attribute panel or the extensible interface part of the framework, the final result will only have a simplistic UI. Though the level editor will still have the core features of creating a level, managing objects and saving levels to files.
Monday, February 22, 2010
Connection setup
in Framework for Game Engine ToolsI’ve now finished the C# side of the tcp connection. Before implementing it I had the problem of figuring out how to let a listener thread both send and receive data, to the other side and with the main (application) thread. My solution is a inbox and outbox queue that both the listener and main thread got access to, along with variable locks to make it thread-safe and avoid collisions. The listener loops and with each cycle adds eventual received data to the inbox for the main thread to handle, then checks for outbox items and sends all of them.
Next task is setting up the equivalent threaded tcp connection in the Nebula 3 application. After that I’m going to test the capacity of the connection, how much and how often data can be sent without delays or errors. All this happens on the same computer and should therefore be fast but it will still need testing and adjustment (such as waiting time for receiving data), and proper error handling.
I’ll need to have these tasks and the synchronized start/shutdown feature of the two applications done by the end of this week to meet my goal of having all main features finished by march 12th.
Friday, February 19, 2010
Command Structure
in Framework for Game Engine ToolsI’m done with the command handlers on both sides, and though their functionality is similar the command function structure still differs a bit.
Note: I’ll refer the command handler class as the Handler and the command class (containing the functions) as the Container for simplicity - and by “commands” or “functions” I mean the method with their respective implementation.
Both the C++ and C# Containers are singletons because commands must be called through an instance.
On the C++ side all Container functions are private and must be registered together with a text string in a map - in order to be retrieved through the GetCommandFunction method. Each command may require a different number of parameters, but for a function to be accepted in the map they all must only accept the same input. Therefore I’ve designed commands to accept two items: a string array containing parameters and their attributes (more of that below), and a single text string for content. Because of this each function will have to first parse its input before its execution (for example retreiving matrix data to a variable). The Handler can accept and parse a message in order to execute commands along with their input.
The C# side is a bit different as .NET got more functionality. The command functions are easily accessed but can only be executed, or “invoked”, with an array of type “object” as input. This brings problems as each command might need different input, therefore I’ve designed commands to either accept a single “object”, or no input. This single object consists of a string array with content and the parameters with their attributes that need to be extracted at first in each function. This Container need all the command functions to be public in order to be retrieved and called from other classes. This Handler may also execute commands through a message.
Commands on either side got input values and content as strings and arrays. The arrays contain a number of elements that is double compared to parameters (“numParams”), where the first half are the input names and the second half include their respective values. For example, the value of the input at index T is at index T + numParams. If param “A” got attribute “1”, “B” got null and “C” got “foobar” then array would look like [A, B, C, 1, null, foobar] as if it were a two-dimensional array.
In the C++ side, each command accept one such array and one string with content. Though in the C# side, functions only accept one object, so the content is added as last element. This will result in the array having size numParams * 2 + 1.
New commands are created in C# just by implementing a public function in the Container with either no or one “object” input. In C++ they’re created by first implementing a function in the Container (preferably private), and secondly mapping it through AddCommand with a key string (will be the name of which the function is called, can differ from function name) and reference to the function. Currently the function mapping is done in the Container constructor.
Then they can be accessed and executed from their respective Handler, note that the command access names/keys are case sensitive.
With this done, I’ll finish implementing the connection between the two sides next.
Wednesday, February 10, 2010
Commands & Progress
in Framework for Game Engine ToolsI’ve structured my commands as two text strings to be sent to the XMLParser via the command handler, on either the C# or C++ side, where they’ll be generated as XML. The first of the two texts contains the command with eventual parameters, and the second holds content which is optional. The parser classes also work the other way, to convert a XML document into the initial command strings.
The command text need at least command name which is placed first. Each item in the text are separated by one space, and parameters are notated with a “-” sign (can easily be redefined). Any non-parameter text item after a parameter will act as an attribute.
Other content such as entity lists is added as a separate string but may be empty.
Here are some examples with arbitrary names and attributes:
“myCommand -foo -bar test -numbers 1234” and “qwerty”
becomes
“shutdown” and “”
becomes
The parser can also convert the other way, inserting the XML generates the initial commands.
Week progress: Doesn’t look like I’ll be done with my work tasks for this week - I’m done with the C++ side XML parser and what’s left are the C# version of it, the command handlers, then finally tcp connection handlers. I will have to complete them after this week as they’re needed for the following tasks until the third milestone.
Monday, February 08, 2010
Design
in Framework for Game Engine ToolsI’ve sketched on a class design that I’ll start implementing this week, full sized version can be found here.
These parts for commands and sending/receiving data are needed for both the C++ and C# side and are therefore quite similar. The exceptions are the TcpConnection where one side has to act as server and the other has client, and the command handler may have different functionality. Available commands are listed separately as they must mirror each other on respective side, but can’t be set as one file/source as each command will need pointers to functions on each side. I see it as a must to have a function for each possible function, this’ll make command extension easier.
My approach is to let the C# editor interface hold session data such as action history/undo data and entities, and the C++ side mainly hold data for rendering. The C# side will also be responsible for error handling; if the C++ parser recieves incorrect XML or its respective command handler recieves and incorrect command it will simply send back an error message for the C# interface to handle.
It might seem clumsy to send data and commands back and forth, for example with a matrix to represent entity placement - but thanks for the Nebula utilities it’s easy to simply convert such data back and to strings for C# to store. Action storage in C# might also look a bit weird as most of them affect N3 objects, but I intend to keep the C++ side as “clean” as possible and implement most functionality in the C# tool side. Multiple action/undo lists on both sides is out of the question because such management will only lead to synchronization errors and complications.
I’ve excluded the other classes and their functionality for now, I’ll put down a concrete design for them next week. In this diagram, they’ll be reached through the command handler classes. For the C# project I’ll structure the form and its controls in the model-view-controller pattern, which will be initialized from a Wrapper class which I’ll set as a singleton.
Friday, February 05, 2010
Third week with more testing and creation of task list
in Framework for Game Engine ToolsThis week I’ve examined the nebula classes and hierarchy in order to see how I’ll develop object management.
My task list is mainly done, I’ve prioritized tasks and features until the end stages for final documentation and presentation. My work plan is inspired by Scrum, to first and mainly focus on the most important features and frequently updating tasks and their importance. I will only work by the primary list until all of them are done, then I’ll start with the secondary ones. A feature or task is done when it has been implemented and tested for usage, errors checked and handled, and code documentated.
Next week I’ll start the actual implementation. Before the second milestone I should have an embedded Nebula 3 app into a minor tool base, and with a way to display the communication between them.
Monday, February 01, 2010
Level Editor Specification
in Framework for Game Engine ToolsIn last week Floh sent me a mail with specifications, kudos to him for taking his time to help me.
A quick summary: Focus should be on extensibility both of the C# application in the form of specialized editor panels, and for Nebula 3 in the form of extensible command protocol (based of XML) and command handler classes (will be very basic and require implementation for new projects). Planning an undo function is important right from the beginning as it is hard to apply later.
They’ve indentified a core set of features:
1. Camera Navigation, 2. Create Object, 3. Duplicate Object, 4. Object Placement, 5. Object Deletion, 6. Some sort of generic object attribute editor panel.
A standard for providing category and attributes of available objects is needed - Nebula 3 got a database with tables that might be used - and simple wrapper classes for the C# editor to use.
“It would be great if there exists some sort of standard framework to implement new functionality. Such an extension would consist of three parts: a set of new XML commands, the C# side (UI stuff and creating commands) and the C++ side which handles the received commands.” I’ll aim to design and implement this, along with a how-to-use guide.
What he didn’t mention is a way to store and load levels though don’t think it’s optional for a level editor. I’ll include it as one of the core features and probably implement it by using XML.
I will prioritize the above first and focus on core functionality only in order to get the most important parts done first, for example only including “fps-controls” for the camera view and exclude maya-controls for later, or implementing only simple object placement functions for movement and rotation. I will do this because it is quite easy to get stuck developing one single feature further and further only because you know how and you want to.
Therefore I’ll set up two lists for the features above, one primary which covers all core functionality and a secondary for extras that give a more “whole” framework. This will be done at friday, along with a wishlist of features (excluded in this project).
Aside from that I’ve studied other commercial level editors in order to find other common properties:
The Unreal Development Kit level editor
The Hammer Editor by Valve
Spark Editor by Unknown Worlds
As well as the level editor for Farcry (thanks to Hirche).
I know that all those editors are mainly for first-person-shooters, but some of their common functionalities will probably be useful for any 3D game which Nebula 3 is intended for (these will be added to the secondary prio list):
- At least one (usually three) extra different views of the level, usually viewing the level in wireframe along an axis
- A grid with an editable size
- Snap-to functionality, objects with other objects and objects with grid
As well as some other features I will have to exclude from this project because of time limits: Basic shapes and colors, vertex altering, browsing and editing object textures.
In the rest of this week I’ll test exactly how to implement its core parts and find out possible additional features, and have most features defined and prioritized in a excel document by friday.
EDIT: Completed project plan with editor features.
Friday, January 29, 2010
Testing
in Framework for Game Engine ToolsI have tested application embedding and communication, it has been very straightforward to set up and it works like a charm. This covers the core part of my project until the second milestone, what’s left is some additional testing and the designing of the system before implementing it.
Next week I will test the features for milestone 3, I have now a list of features so I got something to work with.
A C# app sending and receiving data with a C++ Nebula application.
Embedding only by using a small parameter in a Nebula test viewer and a simple C# application.
Monday, January 25, 2010
First Week
in Framework for Game Engine ToolsToday’s the day for the first milestone and I’m done with the first version of my project plan and research.
My overall plan for the second milestone is that I’ll embed Nebula 3 viewer into a C# application and handle the communication between them using XML via tcp/ip. For the third and final milestone I’ll implement the actual level editor framework, I’m going to ask Floh for specifications but if I don’t happen to get them for whatever reason I’ll list my own - in either case I’ll have the framework features defined and prioritized by the end of next week. I can probably get some inspiration from the world editors Hammer by Valve and Spark Editor by Unknown Worlds Entertainment, which released Natural Selection and is currently working on its sequel.
The next immediate step will be to prototype a embeddable N3 app, and then setting up the connection between the Nebula process and a C# based system.