Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

3141 Excellent

About FLeBlanc

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. FLeBlanc

    Demo and Explanation of Third Person Camera

    Woot, thanks man!
  2. What shader setup do you use for the silhouette material? It looks a LOT like the torchlight silhouettes.
  3. FLeBlanc

    Changing deep game mechanics

    Have you looked into navmesh-based pathfinding such as Recast/Detour? I've found that to be better than grid-based A*, due to the fact that finding a path returns straight lines to waypoints rather than the tile-based zig-zagging of a grid path. It's more natural-feeling. Plus, it's pretty fast, often faster than a grid-based approach since larger areas are often condensed down into a single triangle.
  4. FLeBlanc

    More screenshots of the pixel thingy

    The avatar is based on Segmented's gdnet avatar, sans animation. (He just slides around. It's very creepy.)
  5. And some footage showing point-n-click pathing and enemy following:
  6. FLeBlanc

    Pixel toy

    I'm not much of a blogger. Don't really do much game dev anymore, either. Mostly I just lurk in gd.net chat and throw stones at other people. But recently I started tinkering around with a project. Inspired by 3D Dot Game (which I've never played, but which I like the looks of) the project is kind of a pixely... thingamajig. I don't know how far I'll go with it, really, but here are a few screenshots. It's been fun. Been learning the Urho3D engine, which JTippetts introduced me to some time back. It plays sort of Diablo-ish: click and point goodness.
  7. FLeBlanc

    Bacterius made me do it.

    That is some rainbow-y rainbows right there.
  8. FLeBlanc


    Permadeath, or gtfo.   And I'm with riu. Stop talking and post some pictures. :P
  9. Is this thing still in progress?
  10. FLeBlanc

    Crafting Skills, and Ranting About UI Programming

    Man, I hear you. I hate, hate, hate UI programming. It's always ugly. Unfortunately, I've never seen any good solutions to the complexity. If you have a complex UI, you're going to have to write a lot of ugly code to get things hooked up. Like Servant said, duck-taping two paradigms together gets messy.   Looking pretty awesome, though. If you need any volunteers for your stress-testing, let me know. I'm not a huge fan of turn-based, but maybe a complete turn-based noob is what you need to find the weak spots. :D
  11. FLeBlanc

    The Mosin Nagant is here

    That's a nice piece of history right there. Lovely.
  12. FLeBlanc

    Stain glass windows

    That top one is awesome, seriously.
  13. FLeBlanc

    Scrolling 2D Block World

    This thing is kind of fun, thanks.   One thing I noticed. On my (overwhelmingly shitty) XP box at work, if the framerate drops low enough it will sometimes skip generating a column. I suspect this happens when the camera moves more than 1 unit between updates, since it looks like MoveCenter() assumes that if the center column changes, it only changes by 1. I'd suspect you could loop to ensure that columns aren't skipped. If someone were to bump up the scroll speed as well, this would probably start to happen on other non-shitty boxes. You can see a skipped column in this screenshot:     This was a fun little thing to play with, a good way to spend a boring morning at work, thanks again. Floating islands!     Any plans on turning this into a game?
  14. FLeBlanc

    Fighting the code backfire

    Actually, many experienced folks (myself included) will caution you away from too much reliance on polymorphism these days. Object attributes, behavior, etc... should be gathered together by composition rather than inheritance. (The old "favor composition over inheritance" guideline). If an object is intended to be controlled remotely, it would have a RemotePlayer controller rather than a LocalPlayer controller, for example. The game logic itself doesn't have to change that much.   Polymorphism enforces IS-A relationships, while object composition enforces HAS-A relationships. Too much IS-A in a game object structure can get tricky, or lead to serious identity problems. Consider, for example, containers. Object A wants to be a Treasure Chest to hold stuff. Object B wants to be a Backpack to hold stuff. You might think that since they are similar (container) each would derive from a base Container type, but that causes a problem. Object A can not be equipped/carried by the player, while Object B can. So then you have to fork Container into CarryableContainer and NonCarryableContainer. Now, some Treasure Chests can be trapped, so that leads to another fork: TrappedNonCarryableContainer and NonTrappedNonCarryableContainer. And so forth. Such inheritance hierarchies can [i]quickly[/i] explode into unmaintainable spaghetti.   On the other hand, using object composition instead, then Object A, which wants to be a treasure chest, would aggregate a Container component with a Renderable component. Object B would aggregate a Container, a Renderable, and a Carryable component. Object C (Trapped Chest) would aggregate a Renderable, a Container, and a Trap. You could even do a trapped backpack by aggregating a Renderable, a Carryable, a Container and a Trap. A Death Bag (looks like a backpack, explodes on touch) might aggregate a Renderable and a Trap. You don't have to worry about figuring out which node in a complex hierarchy a particular object needs to inherit from to get the desired behavior; you just aggregate together all the small behaviors and properties that, as a sum, define what your object is and how it behaves. A different aggregation results in a different object.   Typically when building such a system [i]some[/i] polymorphism is involved (especially at the system/framework level, to get your object system to behave) but usually such is limited to low-level framework code only and by the time you get to coding actual game objects the polymorphism is safely hidden away where it can't hurt anyone, and composition is used pretty much exclusively. (It is, of course, possible to sub-class particular components but that should be used carefully, since it can simply lead right back to the inheritance problems.) If you find yourself building complex game behavior/object hierarchies through inheritance, it's usually a sign that there is something wrong with your design.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!