Ok having slight problems with irrlicht event handling.

according to irrlicht documentation there is only one function which needs to be overridden



currently my code can load in player objects from a data file, setting position and assigning a typeId.

How can i implement event handling for movement for my player object only. my player class is derived from a game object class



my main function is



nice huh but how do i get the movement working aaarrrggh pulling hairs out , if you need anymore explanation of the code just let me know cheers

I'm not sure it's a good idea to go crazy with object oriented programming, it may be handy to do it for the idea of an object but the main 'nucleus' of the program should just be one big loop without making the game itself an object. For example, it makes sense to have a map object where you can randomly add entity objects to the map which all have their own behavior, but too much can be a hassle. In JAVA it's expected to do weird stuff like this but it makes sense that way- not very fast though, but at least I can make it like this way.

Anyways, to get the player to move I see you have three bizarre named vectors for position, velocity, and acceleration. I see it seriously lacks comments, you need to add some major comments to explain what everything is but from what I can tell of what you have of me you need to add the following in whatever method that is called every frame on every object (some method like handleMovement() or to combine stuff every game object has to do every frame into handleObjectFrame()):

// Note this is generic stuff this only references the idea behind your code but since you're using OOP it looks like you'll understand
velocity.x += accel.x;
velocity.y += accel.y;
...
position.x += velocity.x;
position.y += velocity.y;

Basically you add the acceleration to the velocity first and then you update the position with the current velocity. Note- you have to multiply the values on the right of the += with a time coefficient which is derived from how long the last frame took, usually a double or something. This way you can get movement that moves the same speed despite how slow or fast the frame rate is.

It's much much simpler to model the class all your in game objects that need collision and movement systems with simply the data used for it and a single method which is called upon by the game every frame for all active game objects. I've done this much more often in JAVA where I can simply have gameMap.add(new Enemy("RAWR!"),player.x,player.y)); or something where the map itself doesn't care exactly what the object is but it knows it has a handleObjectFrame() method which it knows it calls. They're all drawn with a drawObject() method which is kept separate of all of this so I don't have to fret about how the object will move and how it will look.

This post has been edited by WolfCoder: 15 Jun, 2008 - 06:20 PM

Irrlicht has a lot of nice examples and tutorials. I think this tutorial is what you're looking for.

@Wolf

I would have a game engine object so you can declare a pointer to it and manipulate it in the loop as such.

The thing is i know how to move objects ive been doing it in a a nasty none OOP way for a while. I just wanted to know if there was a way that i could move around my player object once hes loaded from a text file, this is definitley possible and makes creating scenes and changing them so much quicker. what i really want to know is how i can refer to an object that is loaded from a text file instead of having to hard code a pointer to a node.

Thanks Tom but those tutorials are quite hard to implement into my engine as they dont use any OOP which i like

so the thing is i know how to move objects just dont know how to implement it into my own code by referring to my player object :s

i could just create a pointer to a node then make players have there own constructors rather than using the gameobject base class constructor with there name and x and y and z values passed in, but then i would have to allocate memory to them and hard code them with new. i am trying to avoid this as i want my game to have no hard coding. i want to be able to load all types from a data file and they will do there thing, as you can see game is a singleton class so i can create instances of it.

the loop does exactly what you said wolfcoder, it draws all objects Game::Instance()->Draw(); and updates all objects Game::Instance()->Update();

but if i had a handleInput() function how could i refer to my player object as it doesnt have a pointer and isnt allocated memory until the game is running

oh and my wierdly named variables are member variables therefore m_velocity and such guess thats a c++ thing

This post has been edited by stayscrisp: 16 Jun, 2008 - 04:58 AM

That's not necessary, I just have the main code file with parameters as global variables. Even though it's almost exactly the same thing, there's a reason many games are written flat with object entities. If you've only got one instance of an object ever, then it shouldn't be an object at all and if it's big enough place it in it's own code file. But if you're making a struct, having an array of them and functions placed in it's own lil code file- you might as well use OOP since the langauge supports it. Honestly what, do you want to run two of your game at once for the "woots"?

I keep my main flat because I have a mode handler function that's easier to write and look at when it's written in flat code.

A good use of OOP is object, but remember you can easily add functionality to them- which makes things like writing a save feature REALLY EASY (because I wish I did this before sometimes>_<)

Basically "OOP Support" means the code was designed with features or requirements for it. For games you have to use it cleverly, but if you overuse it, things get slow. Nothing beats a good ol C at being as close to assembler as possible without actually being unless there's a language I don't know about.

@staycrisp
OK well actually, you write a function that opens the file and reads a number denoting how many entities there are in the file to load. Then, you have a loadObjectFromFile(HANDLE handle) for the object which used the handle for whatever method you're using to open the file and initializes the fields with what's in the file. You need to initialize room for all the entities (using their constructors with a constructor that takes no arguments- doesn't need to) in the map either ahead of time or one-by-one as long as there is more data to read.

After initializing, you then call the method and the newly created object has the properties in the text file. You do this for each object. Basically the function doing all this is your map loading function.

This post has been edited by WolfCoder: 16 Jun, 2008 - 06:09 AM

i figured it out cheers anyway.

wolf coder dunno what you were on about lol cheers tho, dunno if you fully understood my code. My bad with the lack of comments :s



This post has been edited by stayscrisp: 16 Jun, 2008 - 12:55 PM

Do as you like, I can't say I'm a big fan of OOP for everything. Keeping it simple is my programming mantra. OOP is great for things you have many of, like "entities" in a game, but for other things I would stay away from it.

In my example the "game engine" does have its own code file, but you want to manipulate it, hence a pointer.

That's basically it^^ you get the idea. It also makes it easy to add new features to a game making sequels and revisions very fast and amazing~

@KYA
I meant where you have some global variables, a main function, and perhaps a few functions that change the global variables. I don't ever need two of those in run-time so I don't have to make an object if I don't want to. Same thing as if I wrote a set of basic screen effects, it effects the whole screen and you only need one so flat code will do- it's easier to read and understand there's only one and it's easy not to get confused.

@staycrisp
I'm basically telling you that I have no idea what Irrlecht Handling is, but it looks like a fancy way and a confusing way to code something simple that I know already.

This post has been edited by WolfCoder: 16 Jun, 2008 - 04:52 PM

Oh, in that case we agree and we were talking about different stuff