Jump to content

  • Log In with Google      Sign In   
  • Create Account


Best way to implement new Items/Entities


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 PhilObyte   Members   -  Reputation: 250

Like
1Likes
Like

Posted 06 April 2013 - 03:31 PM

Hello Forum,

I've started developing a medium-sized XNA game some days ago and now that I have outlined the basic structure I was wondering which is the best way to implement new Items in my game.

 

The overall structure is clear:

Characters (such as Players and Enemies) have Inventories which is basically a 2d-Array of the abstract class Item.

 

Item has four virtual functions: Load, Unload, Update, Draw.

 

There are three derivated abstract classes from Item: Weapon, Armor and Potion.

Now every derivate of these classes overrides the virtual functions of Item to implement new features.

In my game-loop Update() is called for every loaded Item in the inventory.

 

What do you think of this solution? Of course it has much to do with personal preferences, but I want to know how others would do this.

I know interfaces or abstract functions also do the job.

 

Another question would be how Entities are stored in the game's main class. Is there one big array BasicEntity[] entities or are there many, many small ones like

Tile[,] tiles;

List<Character> characters;

Pool<Particle> particles;

Pool<Shot> shots;

...

 

Thank you very much, Phil.



Sponsor:

#2 french_hustler   Members   -  Reputation: 312

Like
3Likes
Like

Posted 08 April 2013 - 11:44 AM

I think that your solution is good if it works for your game's requirements.  However I do not think it is scalable if you will add many more different "items".  Eventually, with such hierarchies, you'll end up pushing common functionalities up to parent objects which will result in a "god" parent class.  If this works for you though, I don't see the need to change it.

 

The way you handle and store your entities will also be based on your game's requirements.  If holding the memory for enetities in big datastructure is good enough, then there is no problem.  This will not scale well if your have massive amount of entities.  You have to think about what you do with these entities and how many you have in the game and whether the datastructure you use will be efficient enough for your needs.  If it does become a bottleneck, then you might consider using different datastructures or reorganizing things in many smaller "pools".



#3 PhilObyte   Members   -  Reputation: 250

Like
0Likes
Like

Posted 08 April 2013 - 01:47 PM

Thanks for your reply,

I decided to leave it as it is since I don't want to include many different items. If this turns out to be not dynamic enough I'll just start it new and make it Component-based.



#4 Khatharr   Crossbones+   -  Reputation: 2612

Like
0Likes
Like

Posted 09 April 2013 - 12:16 AM

Do you really need to update items in inventory? Or draw them? What are you using a 2D array for?


void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

#5 PhilObyte   Members   -  Reputation: 250

Like
0Likes
Like

Posted 09 April 2013 - 01:11 PM

Do you really need to update items in inventory? Or draw them? What are you using a 2D array for?

 

I'll just call these methods for activated items. Maybe, a weapon needs to have it's own draw-methods to, for example, make a glowing lightsaber or somethink like this. Drunk potions need to be updated to have an effect. The 2d-array is the inventory itself. I think there might be an easier way but I just take it... when it gets too slow I consider to draw items normally without fancy effect.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS