sox

Member
  • Content count

    61
  • Joined

  • Last visited

Community Reputation

489 Neutral

About sox

  • Rank
    Crossbones+

Personal Information

  • Interests
    Programming
  1. Programming interview FAIL

    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. How to make a shiny effect

    ZeroZero, The Mario Galaxy series is where i first noticed heavy use of rim lighting.
  4. "So I have an Idea for a game........."

    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. mixed feelings at Uni

    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. Designing levels faster?

    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. 2D Collision Management

    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 :-)