Jump to content
  • Advertisement

Motorherp

Member
  • Content Count

    651
  • Joined

  • Last visited

Community Reputation

613 Good

About Motorherp

  • Rank
    Advanced Member

Personal Information

  1. Motorherp

    Use a game item

    Passing a pointer to a structure of predefined hardcoded entity statistics to your item to modify can work. Either that or passing your item to your entity to handle. These simpler methods have their limitations however in that your properties are hardcoded and each entity must contain the full set even if many of those properties dont apply to that particular entity. Either that or you end up in a situation where your entities have to be aware of every possible item that could exist or vice versa so that they can interact correctly. That's not a big deal if you only plan on having a small number of different item types or entity properties and you know in advance what they all are. If you start adding in lots and lots of different effects though then a hardcoded system like that can become pretty cumbersome and difficult to manage. That's where a system like I describe starts to shine. It's more complicated to setup but the extra effort will pay dividends if you start to make lots and lots of additions to your game. Another feature of such a system is that properties and entities aren't hard linked to each other and can be freely mixed and matched which if well designed can lead to lots of unexpected interesting emergent interactions and mechanics. Of course that could be considered an advantage or disadvantage depending on the type of game you're making.
  2. Motorherp

    Use a game item

    If you wish to create a really flexible and extensible system you could tackle this by having entities and properties as different classes. Entities would be objects in your game such as the player, monsters, potions, weapons etc, and properties are things which describe the state of an entity such as its physical strength value, its endurance value, whether the entity is resistant to fire, whether the entity is consumable or equipable, etc. The entity base class would contain an enum describing its entity type so other entities and properties know what it is, and a list or vector of properties which apply to that entity. Similarly the property base class would contain an enum describing its property type, and the derived property class could contain any additional data needed for that property. Entities can then interact with each other appropriately by adding properties to each other, scanning for the existance of propeties to see if they can undergoe appropriate interactions with each other, and altering the values of existing properties to effect each other. Some basic rough psuedo code as an example of how you could begin to build and use such a system to give you an idea: // base classes class Property { Entity* m_pOwner; PropertyType m_myType; void Update(); }; class Entity { EntityType m_myType; vector<Property*> m_myProperties; void ApplyToEntity(Entity* pEntity); void UpdateProperties(); }; // some derived classes class HealthProperty : public Property { float m_value; HealthProperty(float value) { m_myType = PropertyType_Health; m_value = value; } }; class FlamableProperty : public Property { FlamableProperty (float value) { m_myType = PropertyType_Flamable; } }; class OnFireProperty : public Property { float m_dpu; // damager per update OnFireProperty (float dpu) { m_dpu = dpu; m_myType = PropertyType_Flamable; } Update() { if(m_pOwner->HasProperty(PropertyType_Health)) { m_pOwner->GetProperty(PropertyType_Health)->m_value -= m_dpu; } } }; class Monster : public Entity { Monster() { m_myType = EntityType_Monster; m_myProperties.push_back(new HealthProperty(100)); m_myProperties.push_back(new FlamableProperty()); } }; class FireBomb: public Entity { FireBomb() { m_myType = EntityType_FireBomb; } void ApplyToEntity(Entity* pEntity) { // apply damage from the initial explosion if(pEntity->HasProperty(PropertyType_Health)) { pEntity->GetProperty(PropertyType_Health)->m_value -= 10; } // set entity on fire if it is flamable if(pEntity->HasProperty(PropertyType_Flamable)) { pEntity->AddProperty(new OnFireProperty(2)); } } }; Its not a perfect example but hopefully you get the idea and can see the scope and flexibility that a system like that can give you. Might be worth considering if you intend on making a large roguelike game or something like that.
  3. Motorherp

    Springs and cameras

    I cant really give any feedback without seeing your implementation. If you want to post up some code then I (or someone else) could have a look at it. Yes, using just Hookes law will result in your camera continually oscillating. To get a stable camera which comes to rest you'll have to introduce spring damping (that is a force which is applied opposite to the cameras velocity direction and is proportional to the cameras speed).
  4. Hiya OneEyed. I know a fair bit about vehicle simulation so maybe I can help you out. Your calculations aren't making much sense viewed out of context though. Could you give a higher level overview of how you are handling your vehicle simulation and where these calculations fit in to that scheme?
  5. Motorherp

    PhysX vs. Bullet (again...)

    Using an open source engine has advantages other than giving you the ability to write mods and extensions. Having black boxes in your code can make it very difficult to trace and debug issues, so that's something else to consider, especially since unless you buy a liscence you wont be getting any support.
  6. Motorherp

    poker stats

    Quote:Original post by ToohrVyk Quote:Original post by plywood I have a feeling that depending on where you sit at the table, that because this affects how many cards are currently left in the pile at the time your card is dealt to you, that this affects the probability of you getting a particular hand. No. All permutations are equiprobable when dealing cards. Meaning that swapping places with another player does not change the odds. So no, position does not affect the probability of being dealt something. Indeed. When working out probablities you should only concern yourself with how many cards you've seen compared to how many you've not seen, regardless of where those unseen cards are. Position can change the odds though. For example if you're under the gun the probability of at least one player still to act having a good hole card combination are greater than if you were on the button and everyone up to that point had folded to you. That is one of the reasons why you should tighten up your starting hand allocation from early position and loosen up in late position. To a certain extent this effect is balanced by the fact that if the early position players have all folded, that increases the odds of the deck and remaining dealt cards being stacked towards high cards. In other words you can make reasonable assumptions about the cards which have been mucked. This is more of an issue for full ring games and can pretty much be ignored for short tables. The only reason you can calculate this into the odds though is because as players act you gain more and more information since you can make certain assumptions about how players will play under different conditions. If you find yourself at a "no fold em hold em" table then non of this applies and ToohrVyk is correct.
  7. You could try using an iterative process along these lines: Whilst your character still has movement left for that frame repeat the following two steps: 1) Determine how far the character can move using his current velocity vector before he hits a wall. You can do this by casting a ray in the travel direction and intersecting it with your planes. Move the character this far. 2) Remove any elements from the characters velocity vector which lie in the normal direction of the plane he collided with. Go back to step 1 if the character still has more movement available for that frame and his velocity vector is non zero.
  8. How do people. The latest shmup-dev competition is now over. We've had an amazing turnout this time around with 21 finished games. If you like shumps then please go and check it out and play the games. Link in my sig.
  9. If you're after spline motion then take a look at this tutorial I've written over at my website: ShmupDev Spline Motion Tutorial. Hope that helps
  10. Motorherp

    problems with new [] (c++)

    Not the safest or most flexible solution but one that will give you something which you can use in code in an identical manner to pre-defined multi-dimension arrays is this: // create m by n tile multi array Tile** tileArray = new Tile*[m]; tileArray[0] = new Tile[m*n]; for(int i = 1; i < m; ++i) { tileArray = tileArray[i-1] + n; } // use array just like pre-defined array, eg: Tile& rTile = tileArray[2][5]; // delete array when done delete []tileArray[0]; delete []tileArray; Like has been said though, stl or boost is much better.
  11. Motorherp

    SHMUP-DEV Competition 2k7 Round 2

    Hello again. Just a brief update. The competition theme has now been announced meaning the contest has now begun in earnest. We've also had an update of prizes which now include copies of Torque Game Builder, Cosmigo Pro-Motion, and a total of 275 USD worth of cash coupons to spend at PlayAsia. Get on over and join in the fun.
  12. Hiya folks. For those of you interested in shooter development you'll be glad to hear that our latest competition is now winding up to start over at SHMUP-DEV. Everyone is welcome, even if you've never made a game before. Please have a gander over my site when you find the time and check out our prizes and rules. The more that enter the merrier. Have fun. Link is in my sig btw ;p
  13. Motorherp

    Orienting a vehicle on Terrain

    Unless you're willing to move the wheels up and down on there suspensions relative to the car body you might not actualy find a solution for exactly the same reason why 3 legged stools never rock but 4 legged stools can. The usual way to handle the problem is to follow these steps each update loop: 1) Shoot rays from your car's suspension hard points along the car's negative y axis and intersect these with the terrain. 2) Place the wheels at the intersection points (+ wheel radius * car Y axis). 3) Calculate the displacement of each suspension spring from its rest point (distance between wheel and suspension hard point along car y axis - rest length) and use this to apply forces to the car body according to your spring equation. (You'll also want to track wheel velocity along the car y axis so you can apply damping forces too). 4) Intergrate your car's rigidbody equations forward in time. Over several loops the car body and wheels will eventualy come to rest in their equilibrium positions.
  14. I'm no expert on image file formats but from what I understand if you're going to be using pixel art you're far better of with png than jpg. The reason being that in this style of art every pixel counts and the sprites are usualy created with limited colour palletes. Png will give you an exact copy of your art where as jpg's compression can change your colours and introduce artifacts which detracts from the crispness of your art. As well as this png allows for transparency and partial transparencies which will be vital for 2d sprites.
  15. Quote:Original post by Haladria Maybe you should take a look at Havok physics. http://www.havok.com/ You can see a movie of it here: Looks really nice although i haven't tried it myself. That's not Havok, someonw has just posted it up wrong. The ragdoll/animation stuff with Indiana Jones is done with Euphoria, and the destructable physics is done with Digital Molecular Matter.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!