Jump to content

Game Framework feedback


photo

Recommended Posts

Hi guys!

 

We know that you are already using our game framework and since we really want it to be great, your feedback and suggestions are highly appreciated.
 

Thanks in advance!

Link to comment

hi Natalia:

    Just tried the game framework a bit. I like it so far.

    One question. Could i create multiple type of entities based on a basic entity? or I have to always inherit from entity? 

   Like Weapon Entity-> Pistol

                                 -> Rifle

                                 ->Knife....

 How?

 

thanks

Link to comment
Hi, you can create entity inherited from your custom entity.

For example, weapon hierarchy:

you have a basic weapon entity inherited from Entity

WeaponEntity : Entity with a base method "fire"

You can create entities inherited from WeaponEntity which separates weapons to the range and melee weapons with a implementation of the "fire" method.

 

Like this:

 

WeaponEntity : Entity

                    |

                     -> WeaponMelee : WeaponEntity

                    |                    |

                    |                    | -> WeaponKnife : WeaponMelee

                    |                    |

                    |                    | -> WeaponAxe : WeaponMelee

                    |

                     -> WeaponRange : WeaponEntity

                                        |

                                         -> WeaponRifle : WeaponRange

                                        |

                                         -> WeaponPistol : WeaponRange

Link to comment

Okay,

 

after two months of testing and start migrating my "old" code to the new framework I really like it. The Scheduler and entity balancing code is definetly a huge advantage in comparison to other engines (like Unity3D).

For me, I have two thoughts for the framework to make it better:

 

  1. The most confusing part is about the creation of levels and entities. Against maybe the most developers, I prefer to setup my custom game characters and levels via coding and copy&paste of the .prop and .entity files. And therefore the framework needs a little bit improving. For example: If you want to create an entity you have to define the .prop-filepath twice. First in the properties.prop_list and second in your <entityname>.entity-file. For me it was a little bit weird at the beginning and make bugfinding about that really hard. Same with my level files. You have to define a name for your level in the <gamename>.game-file, but you can totally setup different names for your logic and world files. Only the name in your .level-file have to be the same as in your game-file. At the beginning it was really hard to understand that framework structure.
  2. More a wish than any criticism: A entity-timequeuing-system will be great. The idea behind that: In our game (and in many others) a function of a class have to be executed after a specified amount of time passed. I created a very performance friendly queuing-system that calculates the time, the function of the entity will be executed and stores them in an array. The array is sorted from the least time (e.g. 0.2 seconds) to the highest (e.g. 5 seconds). The advantage: only the first entry in my array will be checked each frame, if the function can be executed, and if not, there is no further need to check the other one. For that, a periodic check for each entity in the onUpdate()-function will be obsolete. I created that system for a non-entity class, but it can be easily ported to the current entity-system. If wanted, I can share the code with you. In my opinion that would be a great feature beside the scheduler-system.

 

Link to comment

Well, I've only start hammering my understanding of the Unigine for 1-2 weeks or so but I will complain over the same issue:

 

1. Your documents: we cannot be search for child function in your web document. This makes it so hard to find anything. There's not a good organization of tutorials for beginner too.

 

2. Your editor interface: multi-frames editor not truly support. Very hard to organize textures in textures window when you have huge amount of them too.

 

This is a great engine by no means. Would be great if you can get these two points clear up, 

 

:)

Link to comment

One more suggestion:

 

Please add some lines into the documentation about any callback-function and the game.getLogicNamespace(), because otherwise the function won't be called. In addition, you have to manually clear the callback-function via NULL-operator, because the application will be crashed.

 

Thanks.

Link to comment

Thank you for your feedbacks. They are very important for us.

For sure, it can be difficult to create levels and entities manually because there are too many files, and framework may crash if you forgot to paste some files or were mistaken somehow while copying.
So it's better to create levels and entities right from Framework Editor, as it automatically checks your code and generates all of the required property files along with the .prop_list file.

Game Framework concept is designed in such a way that you can easily implement your already existing systems in it and I'm glad that it wasn't complicated for you. I believe in the nearest future we are going to come up with a tool for developers for easily sharing their Game Framework projects with each other.

An article containing examples of working with different callbacks in Game Framework is coming. It also will include physics, triggers and widgets callbacks examples.
If you have subscribed to the callback, you need to unsubscribe from it by yourself as neither trigger, physic body, widget nor framework know anything about if the instance the callback is referring to still exists. These systems just call your functions.

Link to comment
  • 2 weeks later...

question - the 3D shooter example - the player character uses PlayerDummy rather than PlayerActor, which seems a bit odd. Why was this done? What are the trade offs between using PlayerActor and PlayerDummy with custom logic?

Link to comment
Hi Danni. Yes, the player character uses PlayerDummy, which is very similar to PlayerActor. We did this to demonstrate you how to work with the camera and your characters' physics by using UnigineScript if logic of your script is different from PlayerActor logic. The logic of the Player can be more complex: for example, you can implement such additional effects as camera shacking.

Link to comment
  • 3 weeks later...

Maybe two more suggestions:

 

  • For debugging I get sometimes a "memory:ErrorLine Unknown member....". It's hard to find the mistake in your script if you can't get the real line in your code.
  • The Framework-Plugin for the Editor doesn't noticed any ExternClasses from my .dll-files. So the complete logic/game-files won't be loaded.
Link to comment

Hi Crisitan,
 

For debugging I get sometimes a "memory:ErrorLine Unknown member....". It's hard to find the mistake in your script if you can't get the real line in your code.

Full string from source code where error occurred will be printed in console in the upcoming SDK update.
 

The Framework-Plugin for the Editor doesn't noticed any ExternClasses from my .dll-files. So the complete logic/game-files won't be loaded.

Please, make sure that you added parameter -extern_plugin "your_plugin" in the editor launcher.
 
Thanks!

Link to comment
  • 2 weeks later...

An article containing examples of working with different callbacks in Game Framework is coming. It also will include physics, triggers and widgets callbacks examples.

If you have subscribed to the callback, you need to unsubscribe from it by yourself as neither trigger, physic body, widget nor framework know anything about if the instance the callback is referring to still exists. These systems just call your functions.

 

Please add a comment into the docs about the typeof()-function. It was hard to find out that the result for it will be "EntitiesLogic::YourClass" in case you want to check the class-instance.

Link to comment
  • 2 weeks later...
  • 3 weeks later...

I was starting a very small game basically to get a bit more into unigine script (as i am no programmer). 

I found the whole script topic not easy to get. 

The frame work helped me to understand the connections between gameobjects and scripts more easily as for some kind of objects it seems to be more intuitive to think of behaviors. This is a model of thinking, which i guess makes it much easier for people to get into a more abstract thinking and opens Unigine to a different group of people.

 

(I recreated the same small game in the other U** editor to compare and see the differences.

The only real benefit to a person like me, is the more easy access to the scripting, but only in the beginning.)

 

Now after fiddeling around with simple problems, I give up the other try and come back to develop this further using Unigine and the framework, to see how far I can get.

 

My conclusio so far is, that the framework shows the right direction and it feels like, that it will be possible to access Unigine more easily in future once the framework is fully developed.

Even very small projects as my test seem to be quite easy to integrate now once overcome the start and get the understanding.

Yes of course, docu, samples and tutorials will definitely help, we all know.

 

I like it, please do develop it further.

 

thx. werner

Link to comment
  • 6 months later...

Can you please update the documentation for the new game framework? I have found some difference in some functions (e.g. getIntersectionObjectsEntity() which now gets 5 variables instead of 6 ).

 

Thanks

Link to comment

Hi Christian,

 

We surely will update all the documentation about Game Framework functions. At this moment you can find the function description in <SDK>/framework/game/level.h file (line 1074). Also, you can find usage example of this function in shooter demo: <SDK>/data/framework/samples/shooter/scripts/entities/enemy.h.

 

Sorry for the inconvenience caused.

How to submit a good bug report
---
FTP server for test scenes and user uploads:

Link to comment
  • 3 weeks later...

Hi,

 

Good work with the game framework, it looks really intuitive. But while porting my old code to framework I found some portions of the code difficult to fit into it. Some issues that come to mind are-

 

1. Entities - I need multiple levels of inheritances from entities. Eg: Entity -> AIEntity -> AnimalAI -> Rabbit. I can implement the inheritance fine, but for me only Rabbit is a placeable entity, rest are all abstract in theory. How can I stop anyone from placing other entities through editor?

 

2. Manager classes - They are neither entities nor levels. Where do I fit them in? Deriving a manager class from entity class is not quite logical. If I initialize it from unigine.cpp or world_script.h file I'm not able to access entities and levels.

 

3. Common level code - Each level is linked to its separate script file which helps me write level specific code. But if I have code common to all levels, where do I write them? If I use a single level logic file for all levels it might get messy. In short there is no base level -> specific level file differentiation.

 

4. I have a custom FSM written for AI that I need to port to framework. If as per the framework all code written should be either an Entity or Level, where do I fit this in? Will I have to rewrite the system to fit in the framework? :(

 

Thanks.

Link to comment

Hi Santosh. Thanks for a good words.

 

1. Unfortunately there is no abstract classes in Unigine script, so you can simply write a note that this class is abstract and it should not be add to the scene. Also you can write error in to log in onInit() function by a simple code:

class MyAbstractEntity : Entity {
	void onInit() {
		if(classid(MyAbstractEntity ) == classid(this)) log.error("don't create MyAbstractEntity\n");
	}
}

2. You can implement a completely different logic and its use in framework by simply include a file with the code.

// same logic in same file.h

namespace SameLogic {
	
	void init() {
		// some code
	}
	
	void update() {
		// some code
	}
	
	class MyClass {
		
	};
}

#include <some.../file.h>

#ifndef __TEST_LEVEL_H__
#define __TEST_LEVEL_H__

/******************************************************************************\
 *
 * class TestLevel
 *
\******************************************************************************/

class TestLevel : Level {
		
		SameLogic::MyClass my_class_instance;
		
		void onWarm() {
			
			SameLogic::init();
			
			my_class_instance = new SameLogic::MyClass();
		}
		
		void onPreUpdate() {
			SameLogic::update();
		}
};

#endif /* __TEST_LEVEL_H__ */

3. You can easily create base class for level and just include file with base logic to level logic file:

// same logic in same level_base.h

class LevelBase : Level {
		
		void onWarm() {
			// some code
		}
		
		void onPreUpdate() {
			//some code
		}
};

#include <some.../level_base.h>

#ifndef __TEST_LEVEL_H__
#define __TEST_LEVEL_H__

/******************************************************************************\
 *
 * class TestLevel
 *
\******************************************************************************/

class TestLevel : LevelBase {
		
		void onWarm() {
			super.onWarm();
			// some code
		}
		
		void onPreUpdate() {
			super.onPreUpdate();
			//some code
		}
};

#endif /* __TEST_LEVEL_H__ */

4. Not necessarily precisely use Entity policy for the development of your project. Game framework was created to make easy relations nodes with logic and you do not have to rewrite everything under the Entity.

Link to comment
  • 3 weeks later...

Hi Yingaz, sorry for the late reply. In fact after posting it I had reverted back to non-game framework coding. Now I might get back to using framework again thanks to your detailed response.

Link to comment
×
×
  • Create New...