Jump to content
  • Advertisement

lwm

Member
  • Content count

    102
  • Joined

  • Last visited

Community Reputation

2518 Excellent

About lwm

Personal Information

  • Industry Role
    Artificial Intelligence
  • Interests
    Design
    Programming

Recent Profile Visitors

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

  1.   Game engines are usually separated into two parts. The simulation, where all the game objects live, and a renderer, which pulls all necessary information from the simulation to draw what the camera sees. The simulation works in "world space" and doesn't even need to know that a renderer exists. A camera is just another object within the simulation. When the renderer wants to draw the world as seen by a camera, it constructs a view matrix for the camera. This matrix is what conceptually moves the world around the camera. But you don't do this yourself. That's the GPU's job, and it is very good at it. You may want to read a bit about world, view and projection matrices.
  2. One thing I would like to add: Learn how to write unit tests and how to write software that it is properly unit testable. This is valuable for two reasons: Firstly, "Test Driven Design" is one of those buzzwords that look good on a CV. But more importantly, thinking about the testability of the code you write almost automatically nudges you in the direction of the SOLID principles and can be a good place to start thinking about software architecture. From my experience in the "big business" world, having unit tests is the first step towards avoiding spaghetti code.
  3. Are you using some framework that we're not aware of? I suspect our definitions of the term "mesh" differ somewhat.   Each frame does basically the same thing: - clear the entire screen - for each "thing" you want to draw    - set up the pipeline (probably at least a vertex buffer, a vertex shader and a pixel shader)    - call draw - repeat   If you want to use a different pixel shader for a specific object, you just use that pixel shader when setting up the pipeline for that object. To start with, I suggest setting up the pipeline from scratch for each object. Optimizing for performance comes later.
  4. Each draw call uses the shaders (and other pipeline state) that were set on the device context previously.   Set Vertex Shader V1 Set Pixel Shader P1 Draw Mesh 1 (uses V1 and P1)   Set Pixel Shader P2 Draw Mesh 2 (uses V1 and P2)
  5. lwm

    Still Alive

    Good idea. I'll try to write up a description.
  6. lwm

    Still Alive

    My last entry was over a year ago - but I'm still alive. Now that the major coding phase for my master's thesis is behind me, I find myself tinkering again in my spare time. Here are some of the major changes since last year: SharpDX I really wanted access to some of the DX11 features and the SharpDX toolkit makes the transition from XNA very painless. I was never really a big fan of XNA's content pipeline, so I created my own. Turns out, Assimp is a a lot faster, more flexible, and robust than XNA's importers and crunch does an excellent job of compressing textures. Skeletal Animation I always thought the math involved in skeletal animation was scary. However, implementing it for myself was surprisingly easy. Besides simply playing and mixing animations, I can now easily sync gameplay actions with events embedded in the animations. Navmesh Generation While working on the AI, I realized that the classic waypoint graphs weren't working for me anymore. They had to be way too dense in order to allow the kinds of behaviors I wanted. So now I entered the 21st century and use navmeshes that are automatically generated from the level geometry. Since the walkable areas are 2D, I use the excellent libraries Clipper and Poly2Tri to generate and triangulate the meshes.
  7. So, what did I do since last time: Not as much as I had hoped, unfortunately. I catch myself all the time trying to optimize or generalize a system that's working perfectly fine instead of implementing more game mechanics. I'm probably going to put together a short mission statement over the next couple of days and start looking for some people to help me tackle this thing. I implemented some new behaviors for the AI and switched from the 2d grid to a much more nav-mesh-like representation. Since I still wanted to use the same data structure for both pathfinding and influence mapping, the graph has to be rather dense. But performance on the CPU-side is not really a problem, so I'm okay with it. I also had a look at Dave Mark's and Kevin Dill's talk on utility-based AI and promptly implemented some of the concepts. The shader for the skill that will essentially be the robot version of night vision turned out well, I think. I always thought the visuals of the night vision modes in other games were way too clean, so I put a lot of noise and blur in it. It looks much more coherent in motion though. Our brains are way too good at recognizing shapes. (Same scene with normal shaders). I love tinkering with a shader until it looks nice and I'm fairly okay at creating textures but I was definitely not born to be a 3d artist. Since everybody seems to love cubes nowadays anyway, I just decided to embrace a more abstract and simplistic style for now. We'll see how that turns out
  8. lwm

    My Current Project: Roa

    Thanks, everyone! The editor was a pain to build, but I really can't see myself (or anyone) building more complex levels in a text editor
  9. lwm

    Oh god, they're coming!

    I've mostly been working on the AI lately, because without an AI that gives the player at least somewhat of a challenge, a stealth-based game would be rather boring. Behavior trees seem to be very popular these days, so I implemented the basic node types using iterators in C#. "Abusing" iterators for anything other than lazily evaluated collections is a lot of fun, although it certainly takes a moment to wrap your head around the unfamiliar control flow. In my specific case, I found behavior trees to be awesome for fine-grained behaviors. For example, when one of the enemy avatars hears a suspicious noise, I want it to stop for a few milliseconds, turn around, raise it's weapon and look around for a couple of seconds. Using behavior trees makes that very easy. For higher-lever AI though, like deciding the most probable position of the player and doing a systematic sweep of a room (possibly with the aid of some allies), a simple hierarchical state machine turned out to get me the desired result much quicker and with less code. I decided to use an influence map to allow the AI to track the player's position. Unfortunately, the enemies would often run around in circles because by the time they had investigated one corner of the room, another, already visited part of the room had filled back up. Tweaking the momentum and decay only got me so far, so I added an additional "channel" to the map to slow down the momentum for areas the AI had already visited. I'm pretty happy with how it turned out, the AI seems considerably less stupid now. Here is a screenshot of my avatar being chased by an enemy: Better quality: [1]
  10. lwm

    My Current Project: Roa

    [quote name='ZBethel' timestamp='1343691176'] Looks great! What tools/sdk's are you using? [/quote] I'm using XNA. If I started a new project right now I'd probably use SlimDx or SharpDx, but the few small annoyances I see with XNA aren't really worth the effort of switching mid-project.
  11. lwm

    Roa

  12. lwm

    My Current Project: Roa

    Hi everyone, For the past several months, I've been working on what is supposed to become a 3d top-down action-rpg with a focus on stealth and subtlety. Now that the engine is working adequately well, I wanted to start this journal in order to make me focus more on actual gameplay. After a couple of exams in the coming weeks, I hope to put together a small demo for all of you to try with some preliminary gameplay. This is what it looks like so far: Better quality: [1] [2]
  13. lwm

    Generating Navmeshes

  • Advertisement
×

Important Information

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

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!