I've been burning all time I have in improving the engine and the game systems, and its going pretty good.
The utility Foundation module is pretty much done and functional, Graphics systems are pretty well too.
Animation module was refactored too, and its working nice so far. Rendering support also improved greatly. libRocket is now working very consistently, it looks like.
Just to go a little deeper on the animations, the sprite animations are working nice, they are capable of defining an evolution along the time of image frames, and updates a sprite with it! This easily makes possible to create a character with different stances.
Also, the camera animations were started, you can now have a AnimationView associated with your camera, and when you do something like viewAnimation.createEarthquake(5(seconds), 20(intensity)); the camera actually starts shaking like crazy :)
The engine is now very functional from a low level perspective. The next systems that need to be done properly / refactored / documented are:
- Kinesis ( physics )
- Scripting (internal engine commands and AngelScript exportation)
- Content managing
- Networking
- Sound improvements
- SceneGraph high-level stuff / Entity system(component-model) / Quad-Tree rendering
It won't take too much time before you have access to a free complete 2D engine, fully documented!
Showing posts with label 2D Game Development. Show all posts
Showing posts with label 2D Game Development. Show all posts
Sunday, February 19, 2012
Saturday, February 18, 2012
Doxygen quick guide
Hello,
I really feel like I should share a quick guide on how to document your code with doxygen and I will explain why! (Doxygen just because its the one I use)
Many programmers, especially beginners, tend to not document the code at all, and use little or no comments in the code. Its not always imperative to use them, but it certainly doesn't make any harm and can be precious in many cases!
When projects start to grow bigger, the codebase starts to expand and it becomes harder and harder to maintain the complexity without proper documentation.
Most people underestimate this, but if you write a big chunk of code and leave it abandoned for some months, when you look at it, it won't even look like it was done by you. Many times, you just feel like refactoring it again, because you don't remember what was on your mind when you made it.
And remember that some projects are big enough that you are away from a "module" of your project months, just while working intensively on another module.. It gets that big often!
For maximum efficiency when working on your software projects, being them libraries, games or general applications, I recommend a lot of comments here and there and organized code. Just think that you will be needing it later, eventually.
But the purpose of this post is exactly to tell you quick and dirty how to write a nice documentation with doxygen syntax. Just follow the topics for what you want and you will be fine.
Please note that doxygen will by default parse documentation on header files only, which is where you normally make the documentation!
After you are done documenting your code, you can run the doxygen GUI application to generate the HTML automatically. Like a sir!
Documentation comment
In C++ you normally make block comments /* ... */ and line comments // ... , doxygen will ignore these and only parse block comments as /** ... */ and line comments as /// ...
Making a series of line comments will generally work as a single block comment.
Documentation indicators
When documenting your code structures, inside the doxygen comment blocks, you usually need to denote what specific detail you are documenting.
For that, doxygen accepts a few indicators, which I will explain next, that may be started with \ and(or) @.
Document a file
To describe a file you may make a doxygen comment, as stated previously, anywhere in that file, as follows:
/**
\file header.h
This file is all about doing.. hmmm. stuff.
*/
Then it will appear in the file listing of the documentation page.
Document a module
.. Also called a group, it allows you to make groups with your structures, so you can easily denote what belongs where. In its simplest form, you can define a group anywhere like this:
/**
\defgroup Graphics
This module contains all graphics related classes.
Cool text here to look like a mr. fancy coder.
*/
Document a class
It is a good practice to document things like a class, a variable, a method, etc by making a comment exactly before it appears in the header file. It is very desirable to follow that practice, both because it looks really neat and because in some cases doxygen will simply know what you are trying to document, without specifying it, just because it comes next. This is important.
Now the example:
/**
\ingroup Graphics
\class MyClassName
\brief This is a short description, which is shown in the class list in the documentation page.
This is a more detailed description, with a lot of details about my class.
\author I am the author!
\date when i made it!
\see MyOtherClass
@author Also works to tell who did it!
*/
class MyClassName{};
The \ingroup will make sure the class belongs to Graphics module from the previous example. You may include a class in many groups.
The \see line will make a link pointing to the other class documentation page.
I think it explains itself if you read the example, but it will become cleared as you advance the tutorial.
Document a method(function)
Something you probably will be doing a lot is to explain what your functions does, and what should be in mind when using it. Following the rule of documenting the method before it appears, check the example:
/**
\brief Counts the child nodes of a tree node
A more detailed description.
\code
A C++ suggested usage.
\endcode
\param recursive Whether the call is recursive and therefore counts each child's child count.
\return an int with the count
*/
int countNodes(bool recursive);
As you may see, you can use \brief to define the "headline" of what your function is for.
Then, you may describe your function's ways. The \code ... \endcode block will force a C++ like presentation in the document page, with proper indentation and highlight of the snippet.
Document a namespace
You can give detail about each namespace you declare, just simply as:
/**
\namespace global_namespace
All things in the library go into this namespace.
*/
namespace global_namespace{}
Document notes and warnings
Usually when documenting something, you may want to leave a note, with more highlight, so the reader pays attention:
/// \note my note
And other times, it is really imperative that the user gets your message, so you highlight a warning:
/// \warning CAREFUL WITH THE EGGS!
Document a "to-do"
When you are documenting a function or anything else, you may suddenly remember it lacks something, or there is just a detail that needs changing, whatever, but you can't do it right now.
When that happens, you may leave a todo note, and there will be a page in the documentation with all things that are left undone, as specified by you. To leave a todo note, just do:
/// This function is very crazy
/// \todo Complete this function support for eating brains of farmers
void func();
Document a page
In the documentation HTML, you find an entrance page, that you may use to write anything you want as an introductory page. It is important to fill this in to give details about the software.You can do it:
/**
\mainpage My Software main page
Now you're writing content to the entrance page..
You can add sections like:
\section Overview Overview
And now this is under a cool header title.
*/
Besides the main page, you can create other pages named as you want, which will go under Related Pages tab in the documentation HTML. It is pretty much the same, but change the indicator you use.
/**
\page FAQ
The most frequently asked questions and its answers.
*/
Finish
After reading this, I recommend that you do some experiments to get confortable with using it.
Just go to http://www.stack.nl/~dimitri/doxygen/ and start your journey, its a funnier task to do than you may think.
This was a really simplified guide, but if you think anything is wrong, missing or lacking, just inform me and I will change it!
I really feel like I should share a quick guide on how to document your code with doxygen and I will explain why! (Doxygen just because its the one I use)
Many programmers, especially beginners, tend to not document the code at all, and use little or no comments in the code. Its not always imperative to use them, but it certainly doesn't make any harm and can be precious in many cases!
When projects start to grow bigger, the codebase starts to expand and it becomes harder and harder to maintain the complexity without proper documentation.
Most people underestimate this, but if you write a big chunk of code and leave it abandoned for some months, when you look at it, it won't even look like it was done by you. Many times, you just feel like refactoring it again, because you don't remember what was on your mind when you made it.
And remember that some projects are big enough that you are away from a "module" of your project months, just while working intensively on another module.. It gets that big often!
For maximum efficiency when working on your software projects, being them libraries, games or general applications, I recommend a lot of comments here and there and organized code. Just think that you will be needing it later, eventually.
But the purpose of this post is exactly to tell you quick and dirty how to write a nice documentation with doxygen syntax. Just follow the topics for what you want and you will be fine.
Please note that doxygen will by default parse documentation on header files only, which is where you normally make the documentation!
After you are done documenting your code, you can run the doxygen GUI application to generate the HTML automatically. Like a sir!
Documentation comment
In C++ you normally make block comments /* ... */ and line comments // ... , doxygen will ignore these and only parse block comments as /** ... */ and line comments as /// ...
Making a series of line comments will generally work as a single block comment.
Documentation indicators
When documenting your code structures, inside the doxygen comment blocks, you usually need to denote what specific detail you are documenting.
For that, doxygen accepts a few indicators, which I will explain next, that may be started with \ and(or) @.
Document a file
To describe a file you may make a doxygen comment, as stated previously, anywhere in that file, as follows:
/**
\file header.h
This file is all about doing.. hmmm. stuff.
*/
Then it will appear in the file listing of the documentation page.
Document a module
.. Also called a group, it allows you to make groups with your structures, so you can easily denote what belongs where. In its simplest form, you can define a group anywhere like this:
/**
\defgroup Graphics
This module contains all graphics related classes.
Cool text here to look like a mr. fancy coder.
*/
Document a class
It is a good practice to document things like a class, a variable, a method, etc by making a comment exactly before it appears in the header file. It is very desirable to follow that practice, both because it looks really neat and because in some cases doxygen will simply know what you are trying to document, without specifying it, just because it comes next. This is important.
Now the example:
/**
\ingroup Graphics
\class MyClassName
\brief This is a short description, which is shown in the class list in the documentation page.
This is a more detailed description, with a lot of details about my class.
\author I am the author!
\date when i made it!
\see MyOtherClass
@author Also works to tell who did it!
*/
class MyClassName{};
The \ingroup will make sure the class belongs to Graphics module from the previous example. You may include a class in many groups.
The \see line will make a link pointing to the other class documentation page.
I think it explains itself if you read the example, but it will become cleared as you advance the tutorial.
Document a method(function)
Something you probably will be doing a lot is to explain what your functions does, and what should be in mind when using it. Following the rule of documenting the method before it appears, check the example:
/**
\brief Counts the child nodes of a tree node
A more detailed description.
\code
A C++ suggested usage.
\endcode
\param recursive Whether the call is recursive and therefore counts each child's child count.
\return an int with the count
*/
int countNodes(bool recursive);
As you may see, you can use \brief to define the "headline" of what your function is for.
Then, you may describe your function's ways. The \code ... \endcode block will force a C++ like presentation in the document page, with proper indentation and highlight of the snippet.
Document a namespace
You can give detail about each namespace you declare, just simply as:
/**
\namespace global_namespace
All things in the library go into this namespace.
*/
namespace global_namespace{}
Document notes and warnings
Usually when documenting something, you may want to leave a note, with more highlight, so the reader pays attention:
/// \note my note
And other times, it is really imperative that the user gets your message, so you highlight a warning:
/// \warning CAREFUL WITH THE EGGS!
Document a "to-do"
When you are documenting a function or anything else, you may suddenly remember it lacks something, or there is just a detail that needs changing, whatever, but you can't do it right now.
When that happens, you may leave a todo note, and there will be a page in the documentation with all things that are left undone, as specified by you. To leave a todo note, just do:
/// This function is very crazy
/// \todo Complete this function support for eating brains of farmers
void func();
Document a page
In the documentation HTML, you find an entrance page, that you may use to write anything you want as an introductory page. It is important to fill this in to give details about the software.You can do it:
/**
\mainpage My Software main page
Now you're writing content to the entrance page..
You can add sections like:
\section Overview Overview
And now this is under a cool header title.
*/
Besides the main page, you can create other pages named as you want, which will go under Related Pages tab in the documentation HTML. It is pretty much the same, but change the indicator you use.
/**
\page FAQ
The most frequently asked questions and its answers.
*/
Finish
After reading this, I recommend that you do some experiments to get confortable with using it.
Just go to http://www.stack.nl/~dimitri/doxygen/ and start your journey, its a funnier task to do than you may think.
This was a really simplified guide, but if you think anything is wrong, missing or lacking, just inform me and I will change it!
Friday, February 17, 2012
C++ Tutorial: Interfaces and virtual classes, Singletons and Exclusive ownership classes
Today I will try to help some people understand a little better about object oriented programming(OOP).
I won't do really in-detail explanations of the code, but actually try to explain the concept of taking these approaches from a software design point of view.
Let me just warn you that the names I may call to these concepts may not be the official recognized names, but that is not the point of the tutorial.
To begin, I would like to explain the common knowledge concept of an Interface.
An interface is when you create a class with some functionality, but leave the implementation abstract, without being defined.
A perfect example would be an interface class IRenderer, that would have methods to initialize the graphics library, to render shapes, models and everything else a renderer needs to do.
Then, you would inherit from IRenderer and implement all the methods, to actually make it work with a specific graphics library. Making a COpenGLRenderer and a CDirectXRenderer would be logical, for example. Each would implement all methods in IRenderer, both using different API's.
A purely virtual interface is when the base class, in this case IRenderer doesn't do anything on its own and can't even be instanced. This happens if the methods are declared as "virtual <type> <name>(<params>) = 0;" and you don't define its body at all.
Otherwise, you can have a virtual class that already works and does something, but can be extended by reimplementing those methods.
Singletons
This concept is also widely known, but often applied erroneously. Sometimes you have a class that you want to ensure that it is only initialized once. There are actually different approaches to do this, but i will recommend one that I find specially effective.
You could make all methods and variables static, which some may consider a dirty solution, since it is not the most safe solution because the unpredictable global initialization of a program. It can be avoided but normally demands extra checks that impact performance without necessity.
So, the first thing I recommend is a private constructor. A private constructor is very very useful because it will ensure that only a member function or a friend class can instantiate this class.
That means immediately you cannot do something like "MyClass object;", you will get compiler errors.
Though, you can create a pointer to it "MyClass* object". Now you need to make it valid, so you request its creation "MyClass* object = MyClass::create()".
MyClass::create is really a static method of MyClass. That is why you can call it without having an instance before. Besides that, it belongs to MyClass so it may instance it.
Here is a sample class of this lesson applied:
class MyClass{
public:
int getNumber();
~MyClass(){
myInstance = NULL;
}
static MyClass* instance(){
// Could instantiate on demand..
return myInstance;
}
static MyClass* create(){
if(!myInstance) MyClass(); // create an object so it becomes the static instance
return myInstance;
}
private:
int number;
static MyClass* myInstance;
MyClass(){
myInstance = this;
}
};
MyClass* MyClass::myInstance = NULL;
Hope you understand and make profit of using this!
To finish, in behalf of this understanding, you can easily create a class that can ONLY be created by specific classes. Just make the constructor protected or private so it cannot be instanced at all.
Then, any class that you want to be able to instance your exclusive creation class, just declare it as a friend class.
...
private:
friend class ThisClassMayInstanceMe;
...
If you know what i mean!
Hope it is clear for you! Any doubts, suggestions just contact me!
Good coding.
I won't do really in-detail explanations of the code, but actually try to explain the concept of taking these approaches from a software design point of view.
Let me just warn you that the names I may call to these concepts may not be the official recognized names, but that is not the point of the tutorial.
To begin, I would like to explain the common knowledge concept of an Interface.
An interface is when you create a class with some functionality, but leave the implementation abstract, without being defined.
A perfect example would be an interface class IRenderer, that would have methods to initialize the graphics library, to render shapes, models and everything else a renderer needs to do.
Then, you would inherit from IRenderer and implement all the methods, to actually make it work with a specific graphics library. Making a COpenGLRenderer and a CDirectXRenderer would be logical, for example. Each would implement all methods in IRenderer, both using different API's.
A purely virtual interface is when the base class, in this case IRenderer doesn't do anything on its own and can't even be instanced. This happens if the methods are declared as "virtual <type> <name>(<params>) = 0;" and you don't define its body at all.
Otherwise, you can have a virtual class that already works and does something, but can be extended by reimplementing those methods.
Singletons
This concept is also widely known, but often applied erroneously. Sometimes you have a class that you want to ensure that it is only initialized once. There are actually different approaches to do this, but i will recommend one that I find specially effective.
You could make all methods and variables static, which some may consider a dirty solution, since it is not the most safe solution because the unpredictable global initialization of a program. It can be avoided but normally demands extra checks that impact performance without necessity.
So, the first thing I recommend is a private constructor. A private constructor is very very useful because it will ensure that only a member function or a friend class can instantiate this class.
That means immediately you cannot do something like "MyClass object;", you will get compiler errors.
Though, you can create a pointer to it "MyClass* object". Now you need to make it valid, so you request its creation "MyClass* object = MyClass::create()".
MyClass::create is really a static method of MyClass. That is why you can call it without having an instance before. Besides that, it belongs to MyClass so it may instance it.
Here is a sample class of this lesson applied:
class MyClass{
public:
int getNumber();
~MyClass(){
myInstance = NULL;
}
static MyClass* instance(){
// Could instantiate on demand..
return myInstance;
}
static MyClass* create(){
if(!myInstance) MyClass(); // create an object so it becomes the static instance
return myInstance;
}
private:
int number;
static MyClass* myInstance;
MyClass(){
myInstance = this;
}
};
MyClass* MyClass::myInstance = NULL;
Hope you understand and make profit of using this!
To finish, in behalf of this understanding, you can easily create a class that can ONLY be created by specific classes. Just make the constructor protected or private so it cannot be instanced at all.
Then, any class that you want to be able to instance your exclusive creation class, just declare it as a friend class.
...
private:
friend class ThisClassMayInstanceMe;
...
If you know what i mean!
Hope it is clear for you! Any doubts, suggestions just contact me!
Good coding.
All is going well!
Good news, the engine is going great, and is looking better than ever, the game is also improving natural just by the fact that the underlying technology is getting better !
The basic systems of graphics are pretty much working good now, libRocket support was totally refactored and it now looks amazing! Let me explain,
There is a RocketPlugin class to control libRocket completely, becoming the interface with it.
You don't need at all to refer to it on basic usage of the module, what you need to know is the RocketContext class.
When you instance a RocketContext , you are immediately ready to load documents, update and render them.. Whats funny about it is that until you do so, libRocket is completely unused and therefore not leaving a footprint in the program performance. When a context is instanced, if library was shutdown, the RocketPlugin will ensure its proper initiliazation with all custom systems it has. When the last context is destroyed, it automatically kills the library again. I guess this works well for all cases :)
If anyone needs help on implementing libRocket feel free to contact me! I 've got mine working very good with SFML 2.
On a informative note, the Demon Eulogy Games website is for now located at: www.demoneulogy.comze.com
It is still under construction!
Monday, January 23, 2012
Different views
I've taken a little weekend pause from all work, and I traveled to London ! It was an amazing time and besides all the fun and beautiful things to see, I cared to take inspiration from the place, as well as ideas, which i expect to turn into game development in way or another. Stuff that need to be tought about and possibly implemented ! But mainly, ideas for the graphics of my games is what I had the most!
Little things of life :)
Monday, January 16, 2012
Yggdrasil Development 1
Here to bring you news about the game!
Today I've added plenty of new things, the damage dealing is way better now. Critical hits are possible, there is elemental special damage. Defense works against the Damage, among a lot of things.
Improved the environment configuration, now you define a stop line where the enemies stop to attack the fortress. The background was started just today, and its just a scrap of what it can become, for testing purposes i drew it and used it right away :)
Also, improved the animation support, meaning that you could take the game now, create a new enemy fully configured by you, and define exactly its animations to your own character sprites!
For now, there are 3 valid states to be made - run, death, attack :)
I've already tought what the magic system will be like, and you can expect something cool! Stay tuned for that, it just involves supercharged magic that can be mixed together :)
But today I dare to share a little demonstration you can try, play and modify. So you can get the taste of what the game is becoming slowly :)
Here's the link: https://github.com/downloads/DevilWithin/ParabolaEngine/Bin.rar
(I won't explain now how to use or edit, but feel free to find out)
Just notice i don't own the character that acts as our enemy. It is a copyrighted brand, and its being used only to build the technology and won't be included in the game at all!
Today I've added plenty of new things, the damage dealing is way better now. Critical hits are possible, there is elemental special damage. Defense works against the Damage, among a lot of things.
Improved the environment configuration, now you define a stop line where the enemies stop to attack the fortress. The background was started just today, and its just a scrap of what it can become, for testing purposes i drew it and used it right away :)
Also, improved the animation support, meaning that you could take the game now, create a new enemy fully configured by you, and define exactly its animations to your own character sprites!
For now, there are 3 valid states to be made - run, death, attack :)
I've already tought what the magic system will be like, and you can expect something cool! Stay tuned for that, it just involves supercharged magic that can be mixed together :)
But today I dare to share a little demonstration you can try, play and modify. So you can get the taste of what the game is becoming slowly :)
Here's the link: https://github.com/downloads/DevilWithin/ParabolaEngine/Bin.rar
(I won't explain now how to use or edit, but feel free to find out)
Just notice i don't own the character that acts as our enemy. It is a copyrighted brand, and its being used only to build the technology and won't be included in the game at all!
Saturday, January 14, 2012
Yggdrasil
Long time without time to post anything.. again!
I've decided to make a smaller scoped project, while leaving all others on stand-by. Even the engine is pretty still while this game develops, using it as well as means to get directions on what the engine should turn into.
This game was called Yggdrasil, at least for now, and it is a Tower Defense styled game.
Something i always found really hard and demotivating is the barrier between game mechanics and game content. It is hard to make content specifically for your game without a great deal of mechanics, like editors and well-established rules of what the game will be. Also, without content like maps etc, it gets hard to work on the mechanics.
Since this game is meant to be finished efficiently, i decided to make it fully data driven. Also, the data itself is only text, so even easier!
The following little definition, could be a portion of describing how a weapon behaves at a specific level. This is powerful because you can make new weapons, new everything, and configure everything!
WeaponLevel
{
CooldownTime="0.3"
Damage="70"
GoldCost="100"
CrystalCost="0" FireDamage="5"
CriticalChance="20"
CriticalMultiplier="1.5"
MultipleProjectiles="3"
MultipleProjectilesAngle="2"
MultipleProjectilesDamage="1"
}
To an extent, it is already playable, but in constant development. And i'ts funny because you can modify it big time. For that, i plan to make a little wiki with all properties when the game releases, full modding is possible :)
You can see a little screenshot of a in-development run. Things you can notice:
- It shows you the money, which is defined in your profile's file.
- The money will rise when you kill an enemy. The amount it rises is defined by the enemy's file in a x..y range.
- The first run ever of a profile is detected and shows a "Tutorial Mode" token.
- The series of quads will become magic skills!
- The background is completely dynamic, from files.
- Green circle is more or less your weapon, which can shoot projectiles, also configurable from files.
- You can see enemies running, animations fully configurable for all states. You see the hit box too and the health bar. All configurable.
- And more to come!
For today, this is it :)
Sunday, November 13, 2011
What's new
Lately, i've been working a lot even though there isn't too much to show. The Parabola Engine is getting better every day, but right now it has one or two issues in the graphics part. Maybe it needs some improvement in design, or just a few more fixes, but i hope i have a confortable rendering system that everyone will like!
Also been working in integrating UI better, the map editor, documentation and an entity component system, which is not so easy task, but will be worth it later :)
Sprite animations are working really pretty, but i will only publish a sample when i implement them in a character controller :)
Besides, i've been drawing a little. I am making a digital painting, which is not even close to finished yet, that i called Phyro. You can see next what it is about, but it should improve a lot with more work, its just a tought i had and decided to draw, learning a lot while making it without any aid except the tools for the job :)
See you.
Also been working in integrating UI better, the map editor, documentation and an entity component system, which is not so easy task, but will be worth it later :)
Sprite animations are working really pretty, but i will only publish a sample when i implement them in a character controller :)
Besides, i've been drawing a little. I am making a digital painting, which is not even close to finished yet, that i called Phyro. You can see next what it is about, but it should improve a lot with more work, its just a tought i had and decided to draw, learning a lot while making it without any aid except the tools for the job :)
See you.
Monday, November 7, 2011
Trying out the "mood" for the next game
I decided to paint a little scene, just to start fetching the right mood for the next game, I think it starts to capture what the feeling is. Just note that im not an expert in digital painting (yet, ahah ), and the amount of time dedicated to this was really low. More will come, hopefully better, and now back to coding!
Sunday, November 6, 2011
Little sample application
I've put together a really small example of Kinesis, the physics module of the Parabola Engine SDK.
Its pretty much a small sandbox to play with. When you press the R key, circles and boxes appear in the position of the mouse cursor, with variable sizes (actually random).
The simulation is drawn in debug mode, so it is nothing fancy, but should be fun.
To finish, you may drag around the objects with the mouse! I dare you to stack as many boxes as you can !
https://github.com/downloads/DevilWithin/ParabolaEngine/EngineDemo1.rar
Enjoy
Its pretty much a small sandbox to play with. When you press the R key, circles and boxes appear in the position of the mouse cursor, with variable sizes (actually random).
The simulation is drawn in debug mode, so it is nothing fancy, but should be fun.
To finish, you may drag around the objects with the mouse! I dare you to stack as many boxes as you can !
https://github.com/downloads/DevilWithin/ParabolaEngine/EngineDemo1.rar
Enjoy
Friday, October 7, 2011
Status update - 07/10/2011
Heys,
Been so busy lately, always working in the engine and demonstration/testing of its features. Whenever i'm home from work, i do my best to advance the code a little further. I'm aiming my effort at publishing the engine 1.0 version as something usable to make a full game. I would really appreciate having someone helping me with this task, at least with the testing part, which could help greatly to mantain bugs and create new features.
I'm focusing 50/50 in improving consistency of what is done, while inserting new features whenever they seem relevant.
Since i'm constantly learning to go through difficulties in implementation of so many systems, i feel in the duty to share my experiences a little more. So i will make an effort to build little tutorials to share with the world how to do little things. Then, bigger tutorials may come, which may use little tutorials in the middle, but that's for later :)
One big thing that was implemented into the engine lately is scripting support! AngelScript is integrated in Parabola Engine. What does this mean more precisely? Well, anytime, you can create an "AngelScriptEngine" object. It allows you to hold scripts, compile them into bytecode ( possibly saving to files, later), and running them at a specific entry point. You have the freedom to compile and run a script with 2 lines of code, at a function of your choosing, in the script of your choosing. Once you create a new "AngelScriptEngine", it is pretty much useless, tho, it provides auto-configuration utilities. That means you can limit your scripts access to the engine, to make different kinds of scripts for different ends. You can also configure the engine with everything and have a of freedom. This auto-configuration part is being done slowly as the engine goes further, since its passive to changes any time. There will be a scripting manual for each auto-config "module". Right now, you can print things to the screen from a script and use strings. Also, if the GameCore functionality is added to the engine, its scripts will be able to control the game that it was configured for by referencing the "Game" var. "Game.SetWindowTitle("New title")" is an example of a working function, usable already from the scripts.
Also, i've been writing engine documentation for doxygen api reference, as well as writing a wiki with tutorials for engine usage and general game making.
The physics system, Kinesis, an extension of Box2D is really easy to use, completely controllable as intended by Box2D specification. Besides, the physics world is renderable through the SceneRenderer for debugging the simulation. More importantly, i've written a small file format for handling physics. This means you can specify and configure physics entities through a CSS-like text file. Then, you take a KinesisWorld and tell it to parse and open the file, and everything specified enters immediatly into the simulation already existing. Here's a small example:
- Case Insensitive
- Comments as below are not allowed. You can use # to mark the rest of a line as a comment.
World {
Unique: yes; // is this world to be added to the destiny KinesisWorld, or completely replace it?
Gravity: 0,10; //gravity force
}
Body.mybody1{
Position: 300,400; //where in the world is this body center of mass?
// Position coordinates are converted internally automaticly, for optimal sizes
//(see Box2D manual)
BodyType: Dynamic; //is the shape dynamic or a static one? maybe a kinematic?
Shape {
ShapeType: Circle;
Pin: 0,0; //where to fix this shape, relative to the body position;
Dimensions: 20;
Friction: 1;
};
}
Hopefully, in the middle of everything i will find time to write a proper website with a proper documentation for releasing the engine as it deserves :)
There is more to say, but i will leave it to a next time!
Been so busy lately, always working in the engine and demonstration/testing of its features. Whenever i'm home from work, i do my best to advance the code a little further. I'm aiming my effort at publishing the engine 1.0 version as something usable to make a full game. I would really appreciate having someone helping me with this task, at least with the testing part, which could help greatly to mantain bugs and create new features.
I'm focusing 50/50 in improving consistency of what is done, while inserting new features whenever they seem relevant.
Since i'm constantly learning to go through difficulties in implementation of so many systems, i feel in the duty to share my experiences a little more. So i will make an effort to build little tutorials to share with the world how to do little things. Then, bigger tutorials may come, which may use little tutorials in the middle, but that's for later :)
One big thing that was implemented into the engine lately is scripting support! AngelScript is integrated in Parabola Engine. What does this mean more precisely? Well, anytime, you can create an "AngelScriptEngine" object. It allows you to hold scripts, compile them into bytecode ( possibly saving to files, later), and running them at a specific entry point. You have the freedom to compile and run a script with 2 lines of code, at a function of your choosing, in the script of your choosing. Once you create a new "AngelScriptEngine", it is pretty much useless, tho, it provides auto-configuration utilities. That means you can limit your scripts access to the engine, to make different kinds of scripts for different ends. You can also configure the engine with everything and have a of freedom. This auto-configuration part is being done slowly as the engine goes further, since its passive to changes any time. There will be a scripting manual for each auto-config "module". Right now, you can print things to the screen from a script and use strings. Also, if the GameCore functionality is added to the engine, its scripts will be able to control the game that it was configured for by referencing the "Game" var. "Game.SetWindowTitle("New title")" is an example of a working function, usable already from the scripts.
Also, i've been writing engine documentation for doxygen api reference, as well as writing a wiki with tutorials for engine usage and general game making.
The physics system, Kinesis, an extension of Box2D is really easy to use, completely controllable as intended by Box2D specification. Besides, the physics world is renderable through the SceneRenderer for debugging the simulation. More importantly, i've written a small file format for handling physics. This means you can specify and configure physics entities through a CSS-like text file. Then, you take a KinesisWorld and tell it to parse and open the file, and everything specified enters immediatly into the simulation already existing. Here's a small example:
- Case Insensitive
- Comments as below are not allowed. You can use # to mark the rest of a line as a comment.
World {
Unique: yes; // is this world to be added to the destiny KinesisWorld, or completely replace it?
Gravity: 0,10; //gravity force
}
Body.mybody1{
Position: 300,400; //where in the world is this body center of mass?
// Position coordinates are converted internally automaticly, for optimal sizes
//(see Box2D manual)
BodyType: Dynamic; //is the shape dynamic or a static one? maybe a kinematic?
Shape {
ShapeType: Circle;
Pin: 0,0; //where to fix this shape, relative to the body position;
Dimensions: 20;
Friction: 1;
};
Shape {
ShapeType: Box;
Pin: 100,0; //where to fix this shape, relative to the body position;
Dimensions: 20, 30; //dimensions of the box
Friction: 1;
};
}
Hopefully, in the middle of everything i will find time to write a proper website with a proper documentation for releasing the engine as it deserves :)
There is more to say, but i will leave it to a next time!
Monday, December 6, 2010
"Grudge" First Female Character
I've decided to use mostly pixel art to compose my game visuals. Though, i am going to build the characters in a 3D package, so i can have a lot of animations in a simpler and smoother way, in my opinion, and export the renders as bitmap animations. So, i will have my 2D art for characters being a "simulated" 3D and i will still have the 3D models to use in trailers, next games, whatever : )
I am using polygonal modeling to create the rough shape, then i add a smooth to get a better result. Sculpting will be ahaed : )
Here are two screenshots of the first night of work in the first female model, enjoy
I am using polygonal modeling to create the rough shape, then i add a smooth to get a better result. Sculpting will be ahaed : )
Here are two screenshots of the first night of work in the first female model, enjoy
More progress coming soon!
Subscribe to:
Posts (Atom)