Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Aldacron

Member Since 16 Oct 1999
Offline Last Active Today, 07:59 PM

Posts I've Made

In Topic: The Week of awesome II! - The second annual unofficial gamedev competitio...

28 August 2014 - 04:23 AM

I'm in.


In Topic: LWJGL Cahce Textures in a Hashmap

07 July 2014 - 11:11 PM

I haven't used slick-utils, but if you can't find any option for caching in the documentation, then it's very simple to implement it yourself.

  •  
  • Create your own TextureLoader class which contains an instance of the slick-utils loader (unless the Slick loader uses static methods, of course) and a java.util.HashMap<String,Texture>.
  • Implement a load method that accepts a file name and returns a texture.
  • Inside your load method, take the following steps:
    • Try to fetch the texture from your cache by calling 'get' on your hash map instance using the file name as a key.
    • If the 'get' call returns null, call the Slick texture loader, add the loaded texture to the hash map with the file name as the key, then return it.
    • If the 'get' call doesn't return null, then simply return the texture.
  • Profit!

In Topic: Java LWJGL Need Help Designing more efficient texture loading.

06 July 2014 - 07:44 PM

Have your texture loader cache your textures in a HashMap keyed on the file name. When you ask it to load a texture, it first checks the cache to see if the texture exists. If it does, it returns the existing instance rather than loading it from disk again.


In Topic: java Constructor parameters

24 June 2014 - 08:24 PM

You seem to be fundamentally misunderstanding something. Your specific item types, like Weapon, shouldn't contain an item. That isn't going to help you at all. For a purely componentized approach, your item class should hold a list (or map) of Components. Specific components give the item its properties.

For example, you would have a Component base class and some subclasses might be WeaponComponent and BuffComponent. Your Item class maintains properties common to all items, like durability, weight, isTradeable, or whatever. A WeaponComponent would maintain properties that differentiate weapons from other items, damageAmount, damageType, requiredSkill, and so on. Using this approach, you could define your weapon components in a JSON file (or YAML/XML/Take Your Pick). Swords, maces, and bows become defined purely by data, rather than by concrete classes. Then, when you load in a weapon, you can do something like this:

 

WeaponComponent weapon = new WeaponComponent( /* values from wherever go here */ );
Item item = new Item( /* item values for this particular weapon * / );
item.addComponent( weapon );

// Let's make it magic
BuffComponent buff = new BuffComponent( /* buff values from somewhere */ );
item.addComponent( buff );

itemsList.add( item );

Using this, you can turn any item in the game, such as a chair, into a weapon. You can give any item, whether it's a weapon or not, a magic buff. It gives you a great deal of flexibility. However, you also increase the complexity a bit. For one thing, you'll need a way to tell if an item has a specific component or not. For example, when the player wants to attack an NPC, you'll want to check if the item he selects to attack with actually has a weapon component. How you do this mostly depends on what sort of container you choose to hold an Item's components, but also whether you want the item types to be fixed or want to allow modders to add new items, and so on.

Between the extreme of the purely data-driven component-based approach and the other extreme of the strict class hierarchy lies a middle ground where you can come up with a sort of hybrid system. In other words, there is more than one way to skin this cat. Every approach will come with its pros and cons. For games that are small in scope and that don't need the benefits of a component-based system, the class hierarchy is perfectly fine. Implementing one of these systems is the easy part. The hard part in making yourself aware of all of the options available to you and learning how to choose the approach that fits your needs.


In Topic: Just a couple of Data-Oriented Design questions.

16 June 2014 - 12:02 AM

Personally, I think we get too lost sometimes in the rigidity of the 'rules' of a given paradigm. It's the reason why you often see questions around here about "true" or "real" OOP. Instead, we should be viewing the rules as loose sets of guidelines that can help you achieve a specific end.

In the case of DOD, I see that the end goal is a more cache-friendly data layout. What that means in practice is going to vary from project to project. In some cases it may very well be possible to have a very clear distinction between data types such that you can keep everything in separate arrays and without sacrificing cache coherency in the slightest. In others, it may mean that some data ought to be interleaved, or it might mean a broader category of objects that group related data (like your Asteroids example with the xforms and motions).

The short of it is, in order to understand how best to layout your data, you need to understand how you're using it. IMO, you're absolutely on the right track and asking all the right questions. Just don't box yourself in by trying to fit into a rigid ideal, but rather adapt the paradigm to your particular use case.  


PARTNERS