• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Roof Top Pew Wee

  • Content count

  • Joined

  • Last visited

Community Reputation

230 Neutral

About Roof Top Pew Wee

  • Rank
    Advanced Member
  1. 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. 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. 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. 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. 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. 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. 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. 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. 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 www.gamemaker.nl. Otherwise, what are you looking to get into? Art? Programming?
  11. 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. 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. 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. 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.