UltimateWalrus

Members
  • Content count

    86
  • Joined

  • Last visited

Community Reputation

229 Neutral

About UltimateWalrus

  • Rank
    Member
  1. vstrakh's method is the most flexible way, but probably overkill if all you want is those guns to rotate with the sprite.  Let's say a gun is originally offset from the boat's rotation origin by <dx,dy>.  If you are rotating the boat's position by theta, just set the gun's position to: gun.x = boat.x + dx*cos(theta) - dy*sin(theta) gun.y = boat.y + dx*sin(theta) + dy*cos(theta)
  2. I guess that all jobs ask for C++, right?     It doesn't matter... just get good at the programming language you like the best.  Even visual languages aimed at beginners (like Clickteam Fusion/Game Maker) are actually an excellent place to start.  Once you feel confident, learn a few more languages.  A programmer is a programmer... once you get good enough, you can pick up a new language over a weekend.   Granted, learning C++ eventually is an excellent idea because most other modern languages aren't as low-level (close to the hardware).  Without knowledge of a low-level language like C++ you won't understand what's actually happening when you program in high-level languages, you'll just have to assume that computers are magic and things like garbage collection are necessary "for some reason," which is not a very good foundation if you want to become skilled.
  3. If you're programming because you just really want your game idea to become a reality, development will happen naturally and it'll feel more like playing than working. If you're programming just to make money (or fulfill some dumb class assignment), it'll feel tedious, agonizingly frustrating, even painful and soul-sucking. However, that's just the reality of life.  You're probably going to have to do at least some of the latter before you get to do the former.  Just do your best to separate them in your mind and don't let the latter ruin the former.
  4. Options 2 and 3 are bound to be very wonky.  I recommend option 1.  It's true that quick double-tap will result in a smaller jump (personally I'd leave this as it gives the player more control and they will quickly learn the difference).  However if this bothers you, you can try "caching" the double jump command when it's pressed early, and only actually executing it at the apex of the jump.
  5.   I couldn't disagree more with this.  The faker the physics, the better... of course there are always exceptions, but these games are usually most fun when the designer is cognizant of the fact they're breaking this rule.
  6. Remote freelance programming is becoming more and more common these days (I do it all the time, even internationally).  It could be rough to plan an entire career around that but you could certainly try.  It really boils down to how good of a programmer you are, and having finished (preferably solo) projects that demonstrate your skill.  If you're decent then I bet there will be people willing to hire you internationally (and you can work from home in your underpants). If you get good at programming you can shoot me an email (admin at ultimatewalrus.com), and maybe I'd consider subcontracting sometimes or referring people who don't want to pay my rate to you.
  7. Learning SDL For Game Development

      Well, my experience was different. I have written it here: http://www.gamedev.net/topic/677275-where-to-start-programming-games-c/#entry5282811     Everyone learns differently!  But it's still my belief that learning high-level development is the better place to start for most people, because it's a more rewarding experience, and it gives you an idea of what game development [i]should[/i] be like before you delve into the low-level world (which needs to be done eventually if you want to be any good) where nothing at all is spelled out for you.  Granted Unity is not the most accessible engine; I would recommend Clickteam Fusion, Game Maker, or Construct as a good first engine to learn.  Everyone is always eager to jump straight into 3D development but I guarantee it's a much more difficult path.
  8. Fbx Animation

    Here's what I would do:   *Make a tall box with a cross-section in the middle *Create a 3-joint skeleton for it, with one at one end, one in the middle, and one at the other end *Skin it appropriately *Load it into your code, and write a routine that slowly rotates the middle joint so you can see what happens If you experience bugs with even a model that simple, then you'll be able to debug it in a simpler way that is much more intelligible than looking at that garbled mess of polygons. If you don't experience the bug with that model, then that in itself will be enlightening.  Maybe your bug is related more to complex models, for example perhaps the way you handle complex joint hierarchies is messed up.
  9. Use your own judgement and try to strike a balance between readability and logical structure.  Sometimes it just makes more sense to nest things, since whatever you're doing isn't really important enough to warrant its own function, and it makes more sense for it to be part of the current scope.  Other times, it hurts readability.  Don't blindly listen to know-it-alls who claim you should always do things one way or another way (except for me when I say you should ALWAYS COMMENT YOUR CODE   :))
  10. UV mapping

    If I were you, rather than pour over long, unintelligible lists of indices, I'd do the following process in order to get the cube rendering properly: 1.) Get one face working correctly. 2.) Get two faces working correctly. 3.) Get three faces working correctly. etc...  :)
  11. Learning SDL For Game Development

    It's a very good idea to learn low-level game development at some point.  But I usually recommend beginners start by getting a grasp on the high-level (more abstract) concepts of game development.  If you don't know what it's like to work in a fully realized game engine, you're going to have a very difficult time building your own. Making a ton of small games in an easy to use environment like Clickteam Fusion is, in my opinion, a much more natural and pleasant way to learn game dev than slogging through making your own engine right from the get go.
  12. While a college degree certainly helps, your credentials aren't as important as being able to demonstrate that you can program.  From what I can tell, assuming you are a decent programmer you're virtually guaranteed to find some sort of job in the US, as there is rabid demand for programmers over here.
  13. [url=http://ultimatewalrus.com/santa][/url]   [url=https://vimeo.com/114949753]Trailer[/url] | [url=http://ultimatewalrus.com/santa]Download[/url]   s???? is a freeware isometric game about strategy and exploration, in which s???? is controlled. I just released it last night. It has some unique effects that I haven't seen in any other games. Check it out if you'd like!   Thanks for playing! ---Sebastian
  14. The biggest pitfall I can see in making a pixelly, retro-styled game is having inconsistent pixel sizes.  Many engines don't have a built-in way of rendering your game to a low-res surface.  If you don't do this, you'll get badly aligned diagonal pixels every time you rotate something, and badly aligned sub-pixels every time you resize something.  Some people don't care at all and even float-position their pixel art, making for some really cringe-inducing alignment between pixel art sprites.
  15. Mesh collision pushout resource?

    That might be what I have to do.  Thanks --- I appeciate the advice.  I may have the ability to code this custom collision system, but whether I have the endurance to spend so much time expanding the functionality of an engine I'm starting to loathe is another story. I would argue that many, if not most 3D platformers use cylindrical collision bounds (usually a little smaller in radius than the actual visual model is).  Just take any professional, AAA 3D platformer (i.e. not made in Unity) and gradually walk off the edge of a platform.  What you will see is not a gradual, unsatisfying fudge off the edge of the platform (as in Unity) but a deterministic, either-it's-on-or-it's-not sheer drop.  The people who made Unity may consider themselves professionals but they have a lot to learn about how to make a rock solid platformer.  Just because Unity's documentation says capsules are standard doesn't make it true. Also you'll notice that, when walking up ramps, many platformers will allow the player's speed in the XZ plane to remain constant, while moving them up and down in Y to match the ramp (difficult to accomplish with Unity's pushout), rather than slowing down.  You can also see players stick to declines rather than flying off them (granted, this can probably be kludged with raycasts in Unity).