Jump to content
  • Advertisement

grasshopa55

Member
  • Content Count

    368
  • Joined

  • Last visited

Community Reputation

128 Neutral

About grasshopa55

  • Rank
    Member
  1. I personally do not work in the game industry, but have been eyeing it for some time. It's these types of discussions that I like to play close attention to. Much of what's been said here confirms my suspicions about the industry, that, it's really not all that different from the business world, but the chances of longer hours are higher when working on games. I've read the IDGA paper when it was first released and I found it fascinating. The notion of game developers working extra hours because they are "dedicated" or "eager to get the job done" may have been true in the earlier days, but, with today's software development costs, and the talent available, developers should be compensated for this. That being said, I work, on average, 40 hrs a week. During tense times, I've reached 55+, but only for a week or two, not two or three months. There is another paper available from IDGA that talks about crunch time: http://www.igda.org/articles/erobinson_crunch.php IMHO, it's time for game developers and companies to look to other software industries for help managing these large scale projects. Overall, I can see this already happening, but unfortunately, due to the volatile nature of the industry, these types of changes can be slow to progress.
  2. I think you may be looking at this the wrong way. 800 sprites and FPS > 100 is pretty good. Most games run around 30-60 fps. You may very well be able to get many more partilces on the screen while still hitting the 30-60 fps sweet spot. I don't really see the performance issue here.
  3. grasshopa55

    Your Game GUI's

    I just took a look at JUCE and it looks very useful. Personally, I would choose to use something pre-existing before I dove into building something myself. So my choice is #1. This actually helps you achieve #3 as well. By using a 3rd Party library, you can easily use it in other games. I can't really see going option #2 unless I was specifically building it as a learning experience.
  4. grasshopa55

    Fighting Game Hit Detection - Life

    The "Damage Dealt" concept worked great. Thanks for all your help.
  5. grasshopa55

    Fighting Game Hit Detection - Life

    Certain games use the "big block o' life" trick while others still calculate the total amount of damage and animate the life bar to show gradual loss of life. I've decided to go the big block of life route for now, just to get the area working.
  6. grasshopa55

    Fighting Game Hit Detection - Life

    Thanks guys. I'm going to try adding a "wasHit" flag to my player object and see how that works out.
  7. I'm having a small problem with the fighting game I am working on. The Hit Detection algorithm I am using works wonderfully, so I'm at the point where I need to deduct the appropriate amount of life-points from the non-blocking opponent. The pseudo code for this is below if( CheckCollision() ) { PlayerBeingHit.life = PlayerBeingHit.life - damage; } Seems pretty straight-forward, except this code is executed every frame. Since the frame of animation is on screen for a specific amount of time, this gets fired as long as the frame of animation remains on the screen. This varies depending on the current frame-rate of the application. So, my dilemma. What can I do to prevent the above code from firing after the damage has initially been removed?
  8. Quote:Original post by Myopic Rhino I find it interesting that he's recommending Alienware but bashing Dell. Alienware is known for being severely overpriced for what you get - much more so than Dell. I bought a Dell Inspiron 8600 a month or so ago. Coming from both camps, I've owned an Alienware Area 51m and recently bought a Dell Inspiron 8600. The Area 51m was a beast. It took whatever I threw at it and laughed, but I paid around $2,500 for it. Unfortunately, it died less than 2 years after I bought it. I decided not to get another Alienware strictly on price alone. Although I loved the performance, $2,500 is a lot to stomach. Also, my needs changed. I wanted something lighter with a bit more battery life, as the Area 51m only lasted like 45 minutes on battery. It all depends on what you want to use it for. If you plan on spending a ton of time playing the latest games, then the Alienware rig may be worth the dough, but if you are looking for something that's good all-around, go with the Dell.
  9. grasshopa55

    How do you design YOUR 2D sprite class?

    This is a great thread. A lot of good ideas here. Judging the replies I think the consensus is: 1. Manage your image data appropriately. If you are planning on drawing the same image many times, store those images in a Sprite Manager and have your game objects request a reference from the Manager. 2. Be sure about object ownership. As bL0wF1sH mentioned, if your game object stores various common information like position, velocity, etc... don't store it in your Sprite object. It's just not necessary. But, if you treat your Sprite object as a game object, as I have done, it can be easier to manage. But don't forget point #1 in this case. 3. Design what you need. As with any project, the needs of one may differ from another. Choose the design that best fits your application and do your best to be as efficent as possible. Please feel free to add if I've missed something!
  10. grasshopa55

    How do you design YOUR 2D sprite class?

    Quote:Original post by bL0wF1sH If you do go down this road, though, it is best to ensure that the actual image is stored in a manager or external source to the sprite so that you don't have several copies of the same image floating around in memory. Personally, I keep position and movement and such outside of the sprite so that all entities using that sprite can use the same instance (via a Sprite Manager of course) and do the necessary calls to render itself (by calling a Draw() method on the Sprite with the according values). I wholeheartedly agree here. My system is geared for a fighting game, so essentially there is a one-to-one ratio of images to object. In my case, the chances of having multiple copies of the same images in memory is very slim. But, say I was building an RTS, then creating a Sprite Manager would be ideal as my existing system would be problematic. So I guess it comes down to what you are going to use the system for. If I was to start over and build a more generic sprite handling system, I would use the Manager concept, and it has proved quite flexible in other parts of my project.
  11. grasshopa55

    How do you design YOUR 2D sprite class?

    I designed a system very much like gimbal_lock's. I store the animation and frame information in the individual sprite class. I also have the sprite's position, velocity, and other attributes stored there as well. Personally I don't see a problem storing these inside of the sprite class. It's more of a mangement issue than anything else. Take the sprite's position for example. By storing the position in the individual sprite object, drawing them at the right location becomes trivial. As you loop through each sprite, you get the position and draw. The alternative is to store the sprite's position elsewhere, say, an another array or data structure. If you have a large number of sprites, that may become hard to handle. By encapsulating this type of data, each sprite object knows where is should be drawn, how fast is should move, which animation should be displayed, etc... Making management of the objects quite easy. It all depends on what you define as a "Sprite". If a "Sprite" to you is just an image, then this type of design is overkill. But, if a "Sprite" is a player-controllable object, then this design is a good place to start.
  12. grasshopa55

    win32 edit box behavior

    I would take the route that anist suggested. The ES_NUMBER style is the real root of your problem. Edit boxes with that style set only trigger events if a valid number key is entered. So, since the Enter key is not a valid number, no messages are generated. Without clearing that style and writing your own input validation method, using WM_KEYDOWN and checking for VK_RETURN is your best bet.
  13. I don't quite understand what you are trying to do. The tile bar, where the program caption, system menu, minimize, maximize, close buttons reside, can usually be edited by altering the Window Class used to create your window. In MFC, use the PreCreateWindow() method and override the window style structure there. In Win32, in your CreateWindow/CreateWindowEx call, just specify the window styles as the dwstyle paramater. Other than that, I think we are going to need more information about what it is you are trying to do.
  14. grasshopa55

    I wrote a fighting-game move-combo system

    Quote:Original post by Karg You might want to consider mapping the physical keys to virtual keys( Jab, Kick, Jump... ). If you define the moves in terms of the virtual keyset, the you could allow the user to remap the keys the way they want them. Noone can complain about the keyboard set up that way. Plus, adding support for joypads is then a breeze. They're just a state of the buttons, up or down (kinda like a keyboard, eh?). Definately a "cool feature" I think belongs in most all games. karg This is exactly what I did. I found that mapping keys to in-game constants allows you to work with the player's actions instead of what keys they pressed. In building this, I found that it easily lets you implement user key-mapping.
  15. grasshopa55

    color-keyed 2d surfaces?

    Another possible solution is to use textures with an alpha channel already available. I personally like PNG. All you'll need to do is specify that you want your color-keyed value to appear as transparent, then save the file. Any decent image editing program will allow you to do this. Paint Shop Pro has a great PNG exporter that walks you through all the steps. Give this a shot too.
  • 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!