ZioRed

any Entity has two properties GlobalPosition and Position (same for rotation: Rotation and GlobalRotation, same syntax as positions). I forgot to expose the global one, just now updated the examples above.

OOP syntax: Entity myEntity = new Entity(); myEntity.Position = new Vector3(1.5f, 2f, 4.5f); myEntity.GlobalPosition = new Vector3(1.5f, 2f, 4.5f); Core API syntax: Core.PositionEntity(IntPtr entity, float[] position, int global);

Some bugs are reported here.

Yes I'm checking it just now and agree to work on the same way and not waste time to create more libs. Mine was more an attempt for study purpose than a really implementation, I've seen that you added the GameEntity, AI and UI projects on SVN and I will work with you on those. I find useful if we release a complete game library, and may be an adapted editor with the concept of game entities if we have time. For the editor task would be very useful if the winform Control worked perfectly, so that the interface buttons and layout creation would not be a pain

Welcome again on our platform

One benefit is that you can easily modify the data handled by your component at runtime, in my examples I created properties because I like the classic way of class definitions but you really don't need to create properties, you can just access to them with the standard GetProperty(). At this moment and with the small games I have in mind for the near future, I don't see any great benefits from component based compared to the inheritance method except for the gamelib.

Yeah this is what a forum should serve I'll see Mike's GameObjects too when he will release, as the great Peppino Di Capri said: "exams never end" At least I'm doing my gamelib for C# only, Rick for C++, Mike ?bmax?C++?

It displays three buttons (I'm working on GUI as an extended game component) and an health bar (which extends a generic ValueBar GUI component) which belongs to a living (which is still a game component) and show its life points in value and % and is updated and rendered by the GUI component. Each component (and relative children) registered in the Game object is updated and rendered at each _game.Update() and _game.Render().

A very quick answer that comes to mind is to reproduce the game assets of Unity (and may be a visual editor to manage them if I'll have time), an abstract entity which could have many components for rendering (you could have an entity with 2 meshes, set their offset and then move them simultaneously just moving only one object). However I'm writing a very generic gamelib so that it could be used as base for any kind of game or application and extensible by writing new components as plugins as Rick says.

Well I have to say that Rick's excitation let me wait a moment to think about this design and he has inspired me to go deeply in this argument, so now after some huge (not too much indeed) design and code and revamp, I have begun my own new C# gamelib based on components idea (which I could share if interested) with which now I'm able to execute the following code: public static void InitializeGame() { _game = new Game(); _game.Initialize(Configuration); zrGamelib.Components.GUI.GUI gui = _game.CreateComponent<zrGamelib.Components.GUI.GUI>(); gui.DefaultFont = Font.Load("abstract::Arial12Shadow").Pointer; // Create a new image button zrGamelib.Components.GUI.Button btNewGame = new zrGamelib.Components.GUI.Button(gui); btNewGame.Position = new Vector2(20, 50); btNewGame.Size = new Vector2(200, 30); btNewGame.BorderSize = 0; btNewGame.Image = Texture.Load("abstract::ui_new1.dds").Pointer; btNewGame.ImageFocus = btNewGame.ImageClicked = Texture.Load("abstract::ui_new2.dds").Pointer; // Create a new text button zrGamelib.Components.GUI.Button btMultiplayer = new zrGamelib.Components.GUI.Button(gui); btMultiplayer.Position = new Vector2(20, 100); btMultiplayer.Size = new Vector2(200, 30); btMultiplayer.Text = "Multiplayer"; btNewGame.BorderSize = 2; // Create a new component GameLiving for our player zrGamelib.Components.GameObjects.GameLiving player = new zrGamelib.Components.GameObjects.GameLiving(); player.Name = "player1"; player.Initialize(); player.Health = 100; player.MaxHealth = 100; // Create a bar to see our health points HealthBar hpBar = new HealthBar(gui); hpBar.Owner = player; hpBar.ShowValue = true; hpBar.ShowPercentage = true; hpBar.Size = new Vector2(150, 60); hpBar.Position = new Vector2(400, 0); hpBar.Font = Font.Load("incbin::Arial9").Pointer; _game.AddComponent(player); } /// <summary> /// Avvia la sessione di gioco /// </summary> public static void StartGame(FormGames splashScreen = null) { if (splashScreen != null) splashScreen.Close(); GameLiving player = (GameLiving)_game.GetComponent("player1"); while (!Keyboard.KeyHit(Key.Escape) && !Window.HasRequestedClose()) { if (player != null) { if (Keyboard.KeyHit(Key.NumpadSubstract)) { player.TakeDamage(5); } else if (Keyboard.KeyHit(Key.NumpadAdd)) { player.RecoverHealth(5); } } _game.Update(); _game.Render(); Graphics.Flip(); } // Free the engine resources Engine.Terminate(); } This is a sample classes: class HealthBar : zrGamelib.Components.GUI.ValueBar { public HealthBar(zrGamelib.Components.GUI.GUI gui) : base(gui) { } public override void Update() { base.Update(); Value = (int)Owner.GetPropertyValue(zrGamelib.Components.GameObjects.GameLiving.HEALTH); MaxValue = (int)Owner.GetPropertyValue(zrGamelib.Components.GameObjects.GameLiving.MAXHEALTH); } } public class GameLiving : GameObject3D, IGameObjectLiving { #region Properties definition public const string HEALTH = "Health"; public const string MAXHEALTH = "MaxHealth"; #endregion #region Properties declaration public int Health { get { return (int)GetProperty(HEALTH).Value; } set { GetProperty(HEALTH).Value = value; } } public int MaxHealth { get { return (int)GetProperty(MAXHEALTH).Value; } set { GetProperty(MAXHEALTH).Value = value; } } public bool IsAlive { get { return (Health > 0); } } #endregion public GameLiving(IGameComponent owner = null) : base(owner) { AddProperty(new GameComponentProperty(this, HEALTH, 0)); AddProperty(new GameComponentProperty(this, MAXHEALTH, 0)); } public void Move(Vector3 position, bool global = false) { } public void TakeDamage(int damage, IGameObjectLiving enemy = null) { Health -= Math.Min(damage, Health); } public void RecoverHealth(int points, IGameObjectLiving healer = null) { Health += Math.Min(points, MaxHealth - Health); } }

AAAAAAAAArgh.. procedural programming, what a bad thing to me Luckily it doesn't exist in C#, it's full OOP and use namespaces and classes. The usage syntax and function names and namespace and almost all the code from C# wrapper is completely different from any other language here, both C/C++ and LEO (some similarity here) and BMax and Lua. It needs its own placeholder in the dropdown list if you wish to support it, I can help in writing the C# syntax documentation and examples. I'm also planning to add summary comments in the wrapper itself for all the functions and constructors so that we can use something like Doxygen to automatically create CHM and HTML help files.

EDIT: sorry I was wrong in the C demo which I tried, I was trying LoadMesh instead of LoadModel, now it's confirmed that you have the same behaviour on both C/C++ and C#, that is setting collision type to a model does not affect the collision type of its children if you don't set 1 to recursion parameter of EntityType. So this is not a bug.

Have you tried TurnEntity or AlignToVector (may be this last should work better for what you want)?

Mh.. well I will do some tests on C/C++ to see how it works in the different situations (Entity, Mesh, Model, etc) and I will update the wrapper accordingly if needed. But it's strange if on C it works differently, since the default value of the recursion parameter in EntityType is 0

Nice, and agree con Andy, "Button" is redundant. And you can easily create a base class like "GuiElement" which have some of these methods (for sure Position, Update and Draw) so Button can extend it.

Well I joined this community relatively recently, I guess our thanks should go to Tyler and Lazlo.

Well for C# wrapper I have no other interest than use my preferred language (that all now know is C#) to code a game or just only help someone if it's in my possibilities, no real money interest for now is binding me here but my passion for C# (8 years) and programming (~17 years) and curiosity in game development (few months) are worth enough for my interest and you can be sure I will support the C# side of this community (again if it's in my possibilities and knowledge) PS: at this moment the commit members on C# SVN are only Tyler and me (no one else seems to have requested write access), and I costantly log on the C# forum every change/update on SVN as you can see, so it seems we are organized from that side too (recently me and Tyler are connected on MSN too, so we can discuss any heavy update before commit, which rarely happens). @Lumooja: I would be grateful if you (or someone else) could notify to me any change to the header declarations so that I can update immediately the wrapper too.

The only difference between your Entity.CollisionType set and Core.EntityType call is that CollisionType set EntityType without recursion while your direct call to Core.EntityType applies recursion to its childs (last parameter = 1).

Here we missed some posts during the revert: Version 1.32.7 released Log message - Updated default parameters declaration in many functions - Added multiplier operator to Vectors - Added Vector6 class - Added default value parameter to Entity.GetKey() - Fixed Emitter constructor - Fixed Core.AbstractPath

I think this design is very useful in some situations, but I really cannot think to use it as base structure for a complete game because I think it do things more complex than it would have with a well structured inherits and base class (I usually create interface and abstract class with the fewest information as possible and then derive them as needed). First of all I don't like very much to have to remember the string constant of a property or event, and this may cause more "syntax errors" which the compiler cannot find and so generate logical bugs. And even if you use constants for properties/events names, yet the code will result very less readable than an explicit one: float health1 = obj1.GetComponent<HealthComponent>("HealthComponent")->GetAttribute<float>("health"); float health2 = obj2.Health; I think that the component/properties pattern design is very useful if you are going to build a generic game library (and still it needs more methods to hide that way of get value under the hood), but not for a specific game structure.

+1 here Since the engine is capable of loading a file directly from the .pak as it does with LoadModel, LoadMesh etc. could be very useful to give us a command LoadFile("abstract::mydata.dat") which returns the content of file as string (and we can parse it splitting, deserializing etc). I would need it for the Gamelib porting too since atm I'm writing a file system managament by myself for the AbstractPath problem

If you don't want LEO you can use normal C way and TFramework (it is called C++ in the Project Wizard). However I think that if you really go to use OOP way then you'll love it and never come back to procedurally programming... my 2 cent

File Name: C# Project Templates File Submitter: ZioRed File Submitted: 04 Jun 2010 File Updated: 27 Sep 2010 File Category: Tools and Utilities Who chooses to develop games using Leadwerks and C# (with the .NET wrapper) will be interested in adding the C# project templates and so make it possible to create a new Leadwerks game project directly from the Visual Studio wizard. Just download the file and uncompress it in your Project Templates folder, usually your user's: Documents\Visual Studio 2010\Templates\ProjectTemplates\Visual C# You should now have other 2 ZIP files into the destination folder (Leadwerks Console Game.zip and Leadwerks Windows Game.zip), launch the VS IDE and choose NEW PROJECT: two new items should appear in your list for Leadwerks *** Game. Note that you still need to manually copy the engine files (engine DLLs, shaders and scripts). WHAT YOU HAVE TO DO BY YOUR OWN: You must manually copy the file engine.dll from your SDK folder into the bin\Debug or bin\Release folder (so you have to save your project before playing in the debug mode). The templates assume that the SDK folder is located in "C:\Leadwerks Engine SDK" and the NET headers Leadwerks.dll in "C:\Leadwerks Engine SDK\CS", who has Windows Vista or 7 and hasn't this path for SDK folder, then can create a symbolic link (from a prompt run as administrator) to the correct path, e.g.: mklink /D "C:\Leadwerks Engine SDK" "D:\LE\LE 2.40" ============= Changelog: * v2: - Templates updated to the Headers 2.0 Click here to download this file

May be you can check the lastFrame just before Animate call: _frame = AppTime() / 30.0; _frame = fmodf(_frame, end - start) + start; if(_lastFrame > _frame) { _lastFrame = 0.0; _playerState = PlayerState::Idle; _frame = 0; } else _lastFrame = _frame; Animate(_entity, _frame);

The _lastFrame set inside the Reload case switch is not setting the real LAST frame since _frame is changing after few lines. I think you should move the _lastFrame check after the Animate call (however it will affect the next cycle and not the current one).