• 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.

sox

Members
  • Content count

    61
  • Joined

  • Last visited

Community Reputation

488 Neutral

About sox

  • Rank
    Crossbones+
  1. As someone who has done SE interviews, I can tell you a working demo of the game engine you described would trump any of the "Acid Tests" listed in that blog.  If someone asks you something you don't know, don't try to fake it... Admit you don't know, and ask intelligent questions about the topic.     Any good engineer can teach you the difference between overloading and overriding (or whatever) in five minutes.  What can't be easily taught is the work ethic needed to complete a complex demo on your own.  Plenty of people can talk the talk, then fall apart when they actually have to write software.
  2. I'd allow for points and boxes to added to each frame as metadata.  In addition to allowing a "center of gravity" element, it would enable the following features to be added trivially:   1) collision boxes (often not the same as the sprite boundaries) 2) vulnerability / attack boxes (the intersection of a player's vuln. box and an enemy's attack box would trigger damage, for example) 3) spawn points for bullets 4) sound triggers (lets you play sfx for attacks, footsteps, etc., at precise timings)   I've used systems like this in the past, and they can be surprisingly powerful.  You could write a fairly simple tool in a day or two to let you graphically edit and place boxes and points in your sprite frames.   The variable-sized frames sound good, but I'd stick with fixed-size until you're sure that the memory savings is worth the complexity.   The time-per-frame is a good feature.  90% of the time, you'll want your frames to be evenly spaced, but i could see it coming in handy for some specific cases.   have fun!  
  3. ZeroZero, The Mario Galaxy series is where i first noticed heavy use of rim lighting.
  4. I've had someone introduce me to their drug dealer, because a great idea for a game came to him in a dream. I met him for dinner, discussed the concept with him. It was a fantastic concept... easy enough to make, too. I was uncomfortable going into business with him, though. (Kinda worried about getting shanked if it didn't work out.) My instinct was pretty good, because some crazy stuff went down with him later, ending in an FBI raid. Still, it remains the best concept anyone has ever pitched to me.
  5. I built an image-based map system like this back in the stone ages (256 colors, DOS). The advantage of such a system is the conceptual simplicity of it... you're basically building a 2D lookup table that relates screen pixels to province data. There are several disadvantages, however: 1) An errant photoshop filter or export tool could subtly alter your color data, thus corrupting your province lookups 2) You double the space required for every map 3) You have to avoid lossy image formats The alternative is to use a triangle meshes. It will be a bit more complex to pick provinces based on point-in-triangle tests, but they will take a ton less space and will give you more flexibility. In the end, either system should do the job, so use whatever you're comfortable with.
  6. Of all the possible programming jobs you could do, I think game development benefits the most from a well-rounded education. Art. Music. History. Literature. Psychology. Business. Physics... You never know what will be useful in a game. Also, you never know what will be useful in communicating with your designers, animators, and managers. Also... no offense, but everyone's kind of a dumb-ass at 18... even geniuses. Go to University, kick some ass in the CS department, but explore as many other subjects as you can. Spend time with people that are different from you. Date girls, learn how to relate with the opposite sex. Sing at an open-mic night. Write a novel. Fall on your face, and realize failure is just another form of learning. Go be awesome.
  7. It should work fine, until you switch to another app. On iPhone at least, background processes are restricted to preserve battery life and responsiveness. If you [b]really [/b]want to try and make it work, you might to pretend to be a VOIP or music app. [url="http://developer.apple.com/library/ios/documentation/iphone/conceptual/iphoneosprogrammingguide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html#//apple_ref/doc/uid/TP40007072-CH4-SW3"]Here's[/url] a good place to start your research on that. Otherwise, you could just require your users to leave the app in the foreground at all times. Good luck!
  8. Nvidia tries to be developer-friendly... even if you do the wrong thing, the driver will try to fix it for you and give correct output. The real glitch you're dealing with may be that Nvidia doesn't fail where it "should". I don't know of any system that lets you emulate an ATI card with an Nvidia card, but there are different hacks and cheats in place for different retail games. Try running your game with the app profile of some AAA titles (BattleField 3, etc). Some games might be profiled to minimize the use of driver "training wheels"... you could use that fact to reproduce your bug on Nvidia hardware, and figure out what you're doing wrong in code. If all else fails, buy your friend some pizza and monopolize his system all day while he plays Xbox. That's what friends are for.
  9. 1) [b]Create your level designs and layouts before doing any "artistic" work.[/b] Good level design takes many iterations, so you want each revision of your level to be as quick as possible. Have a minimal tileset consisting of only 2-4 kinds of tile (Solid, empty, death, etc). Add the pretty clouds and shiny spikes at the end. 2) [b]Use good tools[/b]. Lets say you need to add one platform tile to your level... At a maximum, that should consist of clicking in your tile editor, saving the file, and rebuilding the game. If you have to hand-tweak any XML files, run any pre-process scripts, etc, you're wasting time that would be better spent doing design. Ideally, you'd be able to add tiles to your level from within the game interface without waiting for a recompile or data build. 3) [b]Know your mechanics[/b]. Exactly how many tiles can your character jump vertically? Horizontally? Running jumps? When you want to place a tricky ledge in your level, you should be able to do it on your first try (using math, diagrams, lookup tables... whatever works for you.) If you're resorting to lots of trial and error to get each jump working, take a step back and figure out why. Hope this helps... if you're not using it already, check out Tiled (http://www.mapeditor.org/), it might help you streamline a bit.
  10. 1) wqking is correct... you may end up with a lot of states, but that doesn't mean all your logic should be inlined with the switch statement. Break each state into its own function, or (if you want), create some high level states which each contain their own "sub-state" machines. 2) A button event (triggered down, held down, triggered up), should generally control state transitions, not direct animations. I'll give you a quick example: Lets say you're in an Idle state. When "PunchButton.Triggered" equals true, you'll call a transition function, something like "BeginPunchState()", which will[list] [*]change your state variable, [*]begin the punch animation, and [*]play any related sound effects. [/list] Now that our state is changed, once per update the state machine will call UpdatePunchState(), which will[list] [*]check for hits against the enemy, [*]check for additional key triggers that could transition us to a combo state. [*]check for the end of the animation [/list] When the punch animation is complete, UpdatePunchState will call ReturnToIdleState(), which sets our state variable back to "Idle", and starts the looping Idle animation again. 3) Grab your physical inputs at the top of your main loop, then translate them to game-related terminology and structures. You want your state machine to handle things like "Punch" and "Kick", not "A" or "X". One advantage of this approach (besides making user defined key mappings manageable), is that you can have "Virtual" buttons that don't exist on the gamepad. Virtual buttons can be things like interpreted accelerometer input (i.e. a quick shake means the "Leg Sweep" button has been pressed), or you can do pattern matching on the input to generate combos without muddying up your other states (i.e. "U+U+D+D+L+R+L+R + PUNCH + KICK" = KonamiFireBall.Triggered" One mistake people sometimes make is to try and keep the input completely seperate from the state machine. Collect and filter your input in one central location, but let your individual states handle the abstract triggers they care about... Your state machine exists to translate player input into character action, so don't get too meta with it. Have fun!
  11. I've found that 2D grid-based collision systems often have "spikey" CPU utilization, for the reasons you describe. If you're open to it, I would suggest trying a sort/sweep system ([url="http://en.wikipedia.org/wiki/Sweep_and_prune"]http://en.wikipedia.org/wiki/Sweep_and_prune[/url]). It can actually be much simpler to implement and maintain, with excellent performance characteristics.
  12. When you want the pressure to increase, you could start various obstacles across the road... fruit carts, baby strollers, grandmothers, etc. (They're all pretty standard movie cliches, but they're reused because they work.) You could time the crossings such that the player gets progressively less time to react for each one. Also, trains and drawbridges can be useful... either as something to avoid, or to make a last-second escape.
  13. I think that if combat-ready spaceships were widely available, some of the first technology upgrades would be making things fit the human brain. For example, in space, nobody can hear the enemy ships exploding because there's no air. It would be supremely useful to a combat pilot if the EM/light signatures from any nearby explosions or weapons fire were converted into binaural sound. The pilot gets instant awareness of what's going on all around him, much more intuitively than a heads-up display. (I always assume that's why we hear the X-Wing blasters in Star Wars movies.) As for Newtonian physics, an AI-based thruster system could easily interpret "no throttle" as "slow down at a pre-determined rate". I would think this would be the space combat equivalent of cruise control.
  14. I don't have time to write code for you, but here are some ideas for getting more information into your equation and simplifying the problem. 1) Keep in mind that there may be many jump angles/velocities that land you in the same spot. You can simplify by locking your angle to 45 degrees. (or whatever angle works best for you) 2) If you know the maximum height of your arc, and your acceleration due to gravity, then you also know the time it takes to rise to that point. 3) You posted a lot of formulas you're looking at, but i find diagrams and descriptions a little easier to convert into code: [url="http://www.physicsclassroom.com/Class/vectors/u3l2c2.cfm"]http://www.physicsclassroom.com/Class/vectors/u3l2c2.cfm[/url] I'll post more when I have time if this was too cryptic :-)