Advertisement Jump to content
  • Advertisement

Roof Top Pew Wee

  • Content Count

  • Joined

  • Last visited

Community Reputation

230 Neutral

About Roof Top Pew Wee

  • Rank
    Advanced Member
  1. Roof Top Pew Wee

    [.net] Developing for Xbox Live Arcade

    XNA is what you want. MS has already announced at GameFest that XNA can be used for XBLA and hardcopy titles. Since you don't have any dev hardware and likely don't have a license with MS XNA is the best you're going to get to be able to run your code on a 360.
  2. Over the years I've greatly reduced the amount of code that the user sees to get FlatRedBall running. Now in XNA it's 3 lines: // In initialize FlatRedBallServices.InitializeFlatRedBall(this); // In Update FlatRedBallServices.Update(gameTime); // and Draw FlatRedBallServices.Draw(); I prefer the engine assuming settings like fullscreen and game titles so beginners see as few lines of code as possible.
  3. Roof Top Pew Wee

    stick rotation

    What I'd do is separate the analog stick into 9 areas: Center TopLeft Top TopRight Right BottomRight Bottom BottomLeft Left Then every frame when you poll the stick, identify which of the 9 areas the stick is currently in. Then I'd have a rolling list of the last N areas that I was in which only gets modified when the current area is different than the last. The size of the list depends on the complexity of the moves. For a full circle, you may want to have 8 or 9 ( 9 so that you repeat the Top area). One issue you may have is that the value reported by analog sticks can wiggle even when the stick is static, so you may want to expand the current area you're in when doing the test and checking to see if the user has moved. Hope this makes sense.
  4. Roof Top Pew Wee

    Combo systems in action games

    In the last fighting game I did, here's how I did collisions. Each character had 2D polygons representing where he could be hit. By the way this was a 2D game with 3D skeleton-like animation on the characters. Anyway, these polygons represented the areas that were considered vunerable. The head and torso since I didn't want feet and hands to be able to receive hits. Then every attack had a defined rectangle that it'd create. The attack specified when after the execution the rectangle(s) appeared, how long it(they) lasted, size, and damage. Then every frame you just check rectangle vs. character polygons to see if there is a collision. Each player would also keep track of which rectangles he's already hit to limit every-frame hits. Finally, rectangles had an ID representing the character who created the retangle. Polygons could be immune to certain IDs so that a player wasn't hit by his own attacks. Also, this immunity was used to allow players to fight on the same team and not take damage from eachother. This system worked out pretty well for the game we worked on. Hope it helps.
  5. Roof Top Pew Wee

    OOP being a bleep

    A constructor is a way that you can specify "options" when building a class. For example, when you go to Subway, they ask you what kind of bread, meat, and veggies you want on your sandwich. You specify these options (arguments) when the sandwich is made (constructor). For example, I might do something like this: Sandwich myFavorite(Bread.Wheat, Meat.Chicken, Veggie.Lettuce, Veggie.Tomato); Another example is when you buy a car. Although this isn't usually how it happens unless you get it online, you could specify some options you want on your car. Car someCar(Color.Red, Engine.V6); The constructor allows you to specify these options right when you create the class. It can be used both to specify "must have" properties of the object as well as just giving you the option to set properties which can be set later. Hope this helps clear things up (and I hope my use of enums doesn't confuse you).
  6. Roof Top Pew Wee

    Didn't know where to put this but...

    To add to SunTzu's post, regarding design I'd strongly suggest you avoid mallocs inside of your functions. The average user might not suspect that he'll have to delete the string. It's likely he may want the string temporarily as well. Therefore, taking a char* as an argument is preferred because it will automatically fall out of scope at the end of the function if the user created it on the stack for temporary usage. If the user wants the string to stick around, he'll be forced to do the malloc himself which serves as a reminder to free it later.
  7. Roof Top Pew Wee

    Game Engine

    I'd suspect that your game loop is being tied to something like the window paint message. Maybe you should post your main loop so we can see if anything is keeping your game from running faster.
  8. Roof Top Pew Wee

    Game States

    A state machine is a perfectly acceptable way to handle game/character states. OOP's good, but don't do it for the sake of OOP if you can solve your problem a different way (and I'm a C# guy :) ) However, one approach I've taken is that I've created classes to represent screens in my game. I'll have a different class for each Menu screen (main menu, options, credits, etc), then I have a class for InGame which is a generic class representing a level in the game. I write as much general-purpose code in that and I try to make it data driven. If there are specifics I need, I can inherit from that class for specific levels. In this case, you really don't need a state machine because each screen does what it needs to do and I have a system where each screen can move to another screen without any problems. I hope this isn't too vague.
  9. Roof Top Pew Wee

    quick question

    Assigning a literal to a variable is simply something like this: String someString = "Hello there"; or int x = 3; 3 will always mean 3, and "Hello there" is always "Hello there". What's it used for? Often for initial values or "magic numbers". You might want to initialize your variables when you first create them so that they're not full of random garbage. Regarding magic numbers, you might create variables (often const) to represent some commonly used value such as PI. Hope this helps.
  10. Roof Top Pew Wee

    Hey, guys

    Photoshop has nothing to do with programming. If you mean what's the easiest way to make a game, you might want to look at Otherwise, what are you looking to get into? Art? Programming?
  11. Roof Top Pew Wee

    Help with programming a 2D game engine

    From my experience with FlatRedBall, my #1 piece of advice I can give when developing an engine is: Let necessity be your guide. Lots of people try to make game engines, and to be honest, they turn out to be garbage because they didn't consider the purpose of the engine - GAMES! As Kylotan suggested, make a game. Any time you need something new like movement or collision or input, stop for a moment, and think how you could code it so it will not only be useful for you in this game, but also in the next game you make, and the game after that. It takes a bit of time and experience to be able to make these kinds of "predictions", but the exercise is well worth it regardless of how much engine work you've done before.
  12. As John Bolton suggests, a modified Euler implementation will fix all of your problems (it's what I used in my platformer as well): position += velocity * deltaTime + acceleration * (deltaTime*deltaTime)/2.0f; velocity += acceleration * deltaTime; That should do it for ya.
  13. Roof Top Pew Wee

    A Simple Char Buffer Problem

    Why do you initialize the array? When you add a character at index, why not add the '\0' at index+1? That way, you know where the valid characters end and where the garbage begins. It'll also result in a valid string you can do stuff with later if you need.
  14. Roof Top Pew Wee

    a speed question

    About batching, it depends on the number of texture switches you are going to have. However, all else equal, does batching cost you anything? I mean, even if you draw 2 Sprites in a batch, switch states, then draw 2 more, you'll probably be slightly faster as you'll be saving yourself an extra draw primitive call. Since you'll be sorting things by Z, your render breaks will likely be dependent on texture swaps. This will give you further incentive to use a sprite sheet rather than individual textures for each object.
  15. Roof Top Pew Wee

    namespace Framework?

    Have you added the DirectX .dlls to your reference folder? In Visual Studio in the Solution Explorer, expand and check the References folder. You should have all of the DirectX .dlls referenced there. If not, you can right click and add which will bring up a dialog box which lets you add the .dlls you need.
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!