• Advertisement

MrMorley

Member
  • Content count

    32
  • Joined

  • Last visited

Community Reputation

137 Neutral

About MrMorley

  • Rank
    Member
  1. Writing Tests For Your Code

    I advocate the test-first approach.   Write the test, then write the code that satisfies the test. This forces you to think about how the code is used, how it's tested, exactly what it's effects and responsibilities are and whether or not it has too many of them. Ugly tests indicate the code under test is ugly. The solution is to clean the code, and make the tests just as beautiful. If you can't think of a test, then you don't adequately know what the thing your trying to write is supposed to be doing, what it is responsible for.   You may not be able to test certain aspects of the lowest levels of your code automatically (I disagree with this notion, but accept it may be more effort than it's worth in many situations), but anything using those levels can be tested by mocking those lowest levels. This keeps responsibilities clean and this forces you to keep the low level at the low level, and separate your game logic from your inputs and outputs. And that's the main advantage of writing tests. If you do it well, commit to it and importantly if you accept the benefits given to your code by taking the time to refactor, the code practically keeps itself clean. The time invested in tests and refactoring is regained in the reduced number of bugs, the less time spent in the debugger and the ease of making changes to clean code.   And if you need to change legacy code that lacks tests, wrapping it in tests before making the changes also accomplishes this by highlighting the issues and providing a safety net as you refactor.   Things that violate the single responsibility principle and inversion of control become so cumbersome to test that you need to clean them up to maintain productivity. Which is an important thing to remember: When the tests become ugly, it's not the fault of testing, but the code under test.
  2. Passed the year by performing so well in everything else I got compensated credit for the one module I failed. I'm just that epic ^^
  3. Cold is a state of mine, like pain, happiness and penguins
  4. Lack of female devs 'a cultural issue' http://t.co/A2IqnfJ I give my opinion in the comments
  5. Beat Hazard Ultra is cool game, see some songs http://t.co/HYDzP3l
  6. ?"Who run the world?" "Corrupt politicians and Ruthless tyrants." "Well...you've sucked the fun out of that song."
  7. What Graphics Library to use?

    Powerful enough? It's not inefficient for a 2D library and has the basic rendering features as well as pixel shaders, Audio and Keyboard and Gamepad support. Graphics and Audio file loading is simple, and sprite rotation, scaling, and the like are all easily implemented and for your average 2D game I'd consider it more than apt, yes. It does lack built-in render-to-texture functionality though which does limit the flexibility of pixel shaders somewhat, though somebody may have implemented that as a 3rd party library, or it could be in the next-version beta. "Power" isn't exactly a measurable element... "Game physics" on the other hand is a very wide ranging subject. For example, collision detection and handling falls under the field of game physics. Jumping, gravity, friction, explosions, systems can become very complicated or be very simple. Generic physics systems, such as [url="http://www.box2d.org/"]Box2D[/url] exist but it's up to you to decide if so flexible a system is what you desire based on the type of game. Asteroids, Super Mario Brothers and Portal 2 all have very different physics systems after all.
  8. What Graphics Library to use?

    Plus Steam's support of the Mac is bringing a lot of titles over to that platform... As for what graphics library, well it depends. You could use something like [url="http://www.sfml-dev.org/"]SFML[/url], which is Object-Orientated, Open Source, Cross Platform and rather simple to use. It's essentially a 2D OpenGL wrapper that removes a lot of the complexity. Of course there is a school of thought that if you really want to learn, it's best to try and "reinvent the wheel" and use something like OpenGL or DirectX even though odds are the wheel you'll invent will be noticably elliptical...
  9. Programming for OpenGL & DX

    Quote:Original post by Fiddler Another thing to keep in mind is that Direct3D and OpenGL shaders are not compatible. If performance is your goal, you will have to write and maintain two sets of shaders. Or use C for Graphics for shaders?
  10. I consider "Tile-based systems" a sub-type of what I like to call "Node-based systems". Each tile is a node. I would consider a system where each node (tile) knows of what actors it contains. As an actor moves from node to node they remove themselves from invalid nodes, and add themselves to new nodes. Then you do collision detection on a node-by-node basis. This also means you can easily consider inter and intra tile path detection as different processes. e.g tile(6, 4) contains ann tile(3, 2) contains bob, player tile(3, 3) contains player You therefore know where each actor is, and that the player is currently on the borders between tile(3, 2) and tile(3, 3). With these three actors you need only check to see if bob and player are colliding.
  11. A significant chunk of voice actors will ad-lib their characters when allowed, and I know of several games that encouraged this during development. Basically the writers came up with how the conversation would flow, but the voice actors, after getting a feel for their characters, had some freedom in how they matched this flow. This lets the characters "unique personality" get through without stepping too much on the plots toes, or intervening with the writers characterisation too much. It works in movies, like Iron Man which was largely improvised, and a lot of the side dialogue (comments in conbat etc.) for characters in video games tends to be or towards this.
  12. I like NetBeans for C++. It actually seems to handle relatively large projects well (better than Eclipse at least), and has decent intellisense that can handle templates very well and is, in my opinion, almost if not as good as Visual Studios. So far it is the only IDE I've found that doesn't throw a fit and have it's intellisense die if you use the C++0x feature Variadic Templates. If not perfectly, it at least handles them it very well. Personally I rank it quite close to Visual Studio as an IDE, and since I can use it with other compilers and therefore gain access to more of the new C++ standard much sooner (Variadic Templates and default and delete constructors are so very useful features VS2010 lacks)...
  13. Rendering System into own OpenGL C++ app

    The code for some 3D modelling programs (such as Blender) is Open Source, and therefore the methods it uses to load and render models is available to use. But it's not exactly optimised to be used in situations like a video game (where quantity and efficiency are somewhat more important than quality) and you are restricted by the license that code is under.
  14. I had a problem like this in OpenGL once. Turns out I foolishly had declared the Orthographic projection as going from (0,0) to (319, 239) -.- Changing this to (0,0) to (320, 240) fixed the problem.
  15. If I were to program games without XNA, what would I need?

    Quote:Original post by GraySnakeGenocide Right now i'm using the 3DBizz XNA/C# tutorials, how am I supposed to remember every single thing these tutorials are teaching me? They have like, hour long videos pertaining to certain code, etc. Don't memorise, utilise. Many programmers have shelves of programming books next to their desk for a reason, you can't expect yourself to be able to memorise every little detail. Besides, it's amazing what sticks in your head so long as you use it often enough ^^ Legends tell of programmers back when 3D graphics were first made reality who could write the code for a teapot solely from memory ;D Well aside from XNA for C# you have DirectX, System.Drawing, OpenGL, Irrlicht, SDL, they all have either at the very least wrappers for them =P And all of them require at least as much to remember as XNA. Also, new to programming? May I suggest ditching graphics altogether, just doing some console window learning and work your way up from there? Graphics introduces whole layers of complexity on top of what you're already having to learn -.-
  • Advertisement