Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Everything posted by FLeBlanc

  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. And some footage showing point-n-click pathing and enemy following:
  5. 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.)
  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.
  15. FLeBlanc

    Skipping Ahead

    This still just seems to me like an extremely convoluted method to achieve some rather 'meh' results.   First, you have the rigid structure of "ridges here, rivers there" that precludes any sort of interesting terrain variation that isn't composed of neat ridges in relative isolation. Secondly, you seem to waste a lot of work, building a map full of ridges only to discard it and rebuild something different later. Thirdly, the midpoint displacement algorithm just seems to be a needlessly complex means of generating randomized detail. The only real redeeming characteristic I see of the algorithm is the ability to flesh-out a ridge/river map with fractal detail, but you don't really need to jump through all of these weird hoops just to accomplish that task.   From what I saw in the linked paper, the resulting terrain just feels... off. Erosive features just don't really look like that. You can achieve much more realistic results from a simple raindrop erosion simulation: seed a terrain with some generated fractal noise, spawn an arbitrary number of raindrops across the map, and simulate stepping their movement as they run downhill to their lowest neighbor, simultaneously raising the sample they run to and lowering the sample they run from by some fraction of the difference in their heights. It's brain-dead simple, it relies upon a single pass of a noise generator plus a single pass of the erosion simulator, and if you enhance the erosion simulator to model raindrop accumulation and to track traffic "heaviness", or flow of raindrops, then you get lake/pond collection "for free" and a detailed flow map showing the most heavily-used waterways. Here are some quick examples, erosion only, performed upon a basic ridged noise fractal:     Even given the hideous quick texturing, the shape of the terrain feels much more natural to me than the ridges-and-rivers technique can produce.
  16.   Easier said than done. Especially in light of...     Just the simple fact that you think making the 3D assets is a simple matter of taking the 2D assets and "transform[ing] them into 3D" makes me cringe just a little bit. After all, the assets in the Rochard game you linked to are so very much [i]not[/i] made of simple cubes mapped with tiled textures. If you are aiming for something more like a 2.5D-ish Minecraft look, though, then you should be fine doing your graphics that way; but then that sort of eliminates the "very detailed" aspect of things, since low-def cubes tiled with textures is almost the anti-thesis of "very detailed".
  17. "Better" is very subjective. The important question is, do you have the budget and resources to make Cuboidz into a 2.5D game similar to the game you posted? It's definitely a [i]lot[/i] more asset-hungry than the existing version. If you're a solo dev, you're adding months, if not years, to the schedule to try to create that 3D content yourself. If you contract it out, it's definitely going to cost a lot more than a few simple sprites will cost. Would the game be fundamentally different, gameplay-wise, or would it be purely an aesthetic change? If purely aesthetic, you can just write it as pluggable back-ends, do active development on the pure 2D back-end, and if budgetary concerns change focus efforts onto the 3D backend. That way, you don't inflate your schedule only to realize, months in, that you lack the resources to complete it.
  18. FLeBlanc


    Seems like a fairly convoluted algorithm to implement, given that the results aren't really all that fantastic. Have you thought about just doing a basic erosion simulation on a ridged fractal generated terrain? After the erosion pass, you can do a waterflow sim to trace the rivers and fill the lakes, and the results are pretty decent.
  19. FLeBlanc

    Navigation mesh picking

    Also, I don't know if I've said it before or not, but this project looks awesome.
  20. FLeBlanc

    Navigation mesh picking

    These are the kinds of problems I find enjoyable to solve. I've been doing gamedev for long enough now that the "obvious" problems (the foundational technical issues, in other words) are technologically solved and boring to tackle, but these little edge cases and implementation-specific problems still pose for me a creative challenge.
  21. Ah, thanks @Stormynature, that did the trick. I was just clicking, not dragging. Pretty cool game so far.
  22. FLeBlanc

    Combat mode camera

    I'm with MARS on this. That second one is freaking cool.
  23. I might just be stupid (it's extremely likely, btw) but I couldn't get my little goblin follower to dig the tunnel at the X sign. (Spoiler alert!) I had him follow me, went to the M screen to try to assign orders to dig, but he just wouldn't do anything. His status says he is in state Work, regardless of what I do or how I try to get him to Idle or anything else. Maybe I'm just a little dense on how to control these guys.
  • 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!