Entry posted by Paul Thomas ·
2,987 views
There are several here who already know me, but for those who don't, my name is Paul Thomas. I've been programming for a long time now; I started when I was 16 (I'm now 30) with HTML, CSS, Javascript, and CGI/Perl. Hell back then there wasn't a lot of people who even used the internet at home, lol. At least in my area, I'm sure others, especially in California, were a lot further ahead at that time in terms of technology and the interest in the technology.
Through the years I've learned multiple languages from strictly web-based to software based. My interest in computers when I was 16 was to make a game, but at the time I thought it would have been much easier to prototype the whole idea in a web-based browser game. I had completed the browser game, which was the original "Eternal Crisis," and worked nicely. My plan was to update the entire web-based system, polish everything, and officially advertise (I had invited friends to play the game). That's when I learned about a "fried hard drive" and eventually learned about "backup" and how to install a hard drive.
Those whom already know me, know what Eternal Crisis is, and my Blogger shows some of the history on that project. I had taken that project, along with another, over to Unreal Engine 3 because it best suit the project. Along the years of learning that engine I was using LE for prototyping ideas and so forth.
While I'm not working on my own engine (temporarily titled "3D Dice"), FPS/RPG framework for UE3, or R.A.T.S., I work on my framework for Leadwerks Engine 2.5. I've never shared this framework before, in fact it always felt like I had to pull it out of a shallow grave each time I added to the framework design and programming. I'm a notebook junkie, I plan out mechanics, structures, and so forth on paper, before going over to digital. Old habbits that die hard I guess.
Now I felt like sharing the progress, which isn't a lot, but it's a great start to me. It's a great start to me because it actually runs, lol. The state of the framework isn't even close to the final planned and written design, but progress is progress. Always move forward until it's finished, even if you can only pick that project up once every two weeks (by then I/you should probably take a look at your workload and fix it instead of attempting such project schedules; however this isn't vital to me and rates low on my importance scale), if it's updated then progress is moving forward. This is also harder to work with if you don't plan your software before actually programming (unless it's routine for you with available libraries for shortcuts in development).
As most programmers should know, the programmers "update" isn't as glamorous as an artists "update" as it's not about visual stimulation but overall program/software flow. In the case of my LE framework (obviously untitled) it's all about providing mechanics and how that is achieved is important especially in the case of LUA access and how everything works together; from configuration/data management, to input binding, and all the way down to AI.
Until occupied again by my other tasks I will eventually share the entire framework structure and I will always be showing examples of syntax; cause that's what programmers do. Just to clear the obvious questions that may come from the community:
Q) Do I plan to give away code, the framework, and be an open source kind of person?
A) No, not really. First of all, you would have to wait, to anyone else at the moment the framework is as useful is a partially finished library. How long you would have to wait would depend on how much time I can spend on the framework and in all honestly it's not much at all (read above, and actually read).
Q) Do I plan to sell or lease the framework?
A) No, don't think so. I even think that's against Leadwerks terms since it could be deemed an "FPS Creator," which is definitely in the terms.
Q) Is my framework really that great?
A) Nah, I mostly ramble, and I'm actually writing this to share with long time friends here at Leadwerks. Some won't even visit anywhere else to communicate because they are so used to using Leadwerks for that; it is indeed where we all met.
Q) Who are my friends?
A) I have none, it was a lie.
Now, about this framework. This "framework" isn't the same, exactly, as the framework that comes with LE. The framework that comes with LE handles some dirty work for you when it comes to creating the worlds, cameras for those worlds, shader effects, and helper functions. The framework I'm designing is technically similar to a game engine. I personally consider Leadwerks Engine as a rendering API with physics and this framework uses that rendering API and provides mechanics. The mechanics the framework provides is what makes up the detail of the framework.
INI
SQL
Application
Graphics
Game
The above are considered "managers" in that they only handle what they should be managing. The "INI" only works with INI files, such as a configuration manager. The "SQL" only works with SQLite3, providing helper functions for easier SQL management, and so forth. There are more planned managers than the above, but these are what are completed in terms of programming. The only real interesting portion to discuss about the framework is within the "Game" manager itself.
The game manager provides two special classes/managers; "Object" and "Actor." Actor inherits everything about an Object. What defines an Object is a game entity that is never interacted with by the player. Objects are useful as it can be used for multiple purposes without consuming a lot of resources for each "component" or "plugin" I'd like to add onto the framework. For example, a Timer would be an Object. You don't interact with a Timer in a game, but there is a timer running in the background.
Example:
class ETimer : public EObject
{
public:
ETimer(void);
virtual ~ETimer(void);
void Initialize(void);
void SetTimer(float StartTime);
void StopTimer();
};
While working with the framework you would do something similar to:
// EGame::EObject
// EGame::Objects
EObject Objects;
// ..
ETimer Timer;
Objects.Add("Timer", Timer);
// ..
ETimer Timer = Objects.Get("Timer");
Timer.StartTimer(0.0);
// ..
Timer.StopTimer();
// inherited by EObject
Timer.Unload();
An Actor inherits everything that defines an Object. The difference between the two is that an Actor is something that a player could see, hear, interact with, or can move, rotate, and so forth. If you can see how this is all going, everything starts extending the Actor, such as the character, weapon, or items. Here are some examples of working with Actors in the framework:
// EGame::Actors
Actors.Add("oilbarrel", "oilbarrel.gmf");
// ..
Actors.Rotate("oilbarrel", vec3(10.0f, 0.0f, 10.0f));
// ..
Actors.Translate("oilbarrel", vec3(10.0f, 0.0f, 0.0f));
// ..
EActor barrel = Actors.Get("oilbarrel");
// rotate with interpolation
barrel.Rotate(vec3(1.0f), 0.1f);
barrel.Translate(vec3(0.0f, 1.0f, 0.0f), 0.1f);
// ..
EActor Barrel;
// new name
Barrel.Name = "barrel01";
// new mesh
Barrel.LoadMesh("oildrum.gmf");
Actors.Edit("oilbarrel", Barrel);
A quick overview of an Actor:
//EActor ID Name Tag Parent Location Rotation Mesh Sounds Particles
Each Actor can also have children which are also Actors. This provides another version of parent/child relationships but also provides additional benefits which will be discussed in later blogs. The ID and Name variables are provided by Object and the Object provides more variables, but is listed for importance.
When creating an Actor it is automatically tagged for unique identification. In the above example "oilbarrel" is actually stored as "oilbarrel_0" and simply incremented for each Actor that is created. This is identified by the Actors "Tag". The "Name" variable is a forced name, therefore searching for an Actor by the name, with more than one Actor having the same name, the first result is returned.
Actors will be automatically created properly for each entity in a scene. The framework will be using a custom scene manager and handles initial Actor creation. Programmers/Scripters can then add to the Actors list with C++ or LUA like the above examples.
class MyGame : public EGame
{
public:
void Load(void);
void Update(float DeltaTime);
// ..
void MyGame::Load(void)
{
Actors.Add("custom_actor", "mymesh.gmf", "force_tag_name");
EActor actor = Actors.Get("custom_actor");
EActor actorCopy = Actors.GetTag("force_tag_name");
actor.Translate(vec3(0.0f));
}
void MyGame::Update(float DeltaTime)
{
EActor actor = Actors.Get("custom_actor");
// interp move with speed and threshold option
actor.Move(vec3(10.0f), 1.0f, 1.0f, 0.35f);
}
};
In upcoming blogs, when I do get the time, I'll post up some videos. Those selected for the invite only alpha testing will get their information on how to use the framework. Friends of mine that didn't get an invite and are interested in alpha testing please private message me; I most likely didn't send you the information because I figured you were busy with your own project(s).
Well, out of time. Thanks for reading.
-
4
4 Comments
Recommended Comments