http://www.gamedev.net/blog/1621-electronic-meteor/ Electronic Meteor Syndication Fri, 12 Apr 2013 19:39:54 +0000 support@gamedev.net (GameDev.net) IP.Blog 60 http://www.gamedev.net/blog/1621/entry-2256284-weekly-update-of-top-down-shooter/
All I have to show for it so far is a movable sphere on an invisible floor with a fixed camera. Most of the work is behind the code, in designing and planning it. Given the month-long deadline I gave myself, I don't want to get myself carried away in doing this. Also, I just got a new job and I have to work 40 hours (which I have not done in over a year) so I don't get as much time with this as I wanted to.

Components and Systems in the game

In the relatively little time I spent working on the game last week, most of the focus was on doing a design based on this. I have made Transform, Geometry, Movement, PlayerControl and Light components which already work for systems. Also, I found someone who wrote an article on using the ECS design for the same genre of game that I'm making, so this really helps a lot!

There are no specific classes for game entities/objects, just a generic Entity class that takes any kind of components, and only one of each. Some components are specific to the game, and other ones are more generic and general purpose. I'm fine with this- the low number of components still makes the code manageable.

I want to use more diagrams in my articles, so I will make one soon to give an idea of how the classes are laid out. For now I'll just write them out here:

Components
Transform: Stores position, rotation, and scale
Movement: Applies change to transform
Geometry: Model representation of object
Light: Stores color, intensity (and other attributes)
PlayerControl: Stores input for player actions
FollowTarget: References another Entity to follow (through Transform)

Entities
Geometry - Transform -> Any entity represented as a visible object
Geometry - Transform - Movement - PlayerControl -> controllable player entity
Geometry - Transform - Movement - Bullet -> a bullet entity
Camera - Transform -> a camera entity
Light -> Light entity

Systems
BasicRenderer -> Draws visible objects with a default shader
PlayerController -> Takes input from player, updates movements
BulletCollision -> Adds, removes and updates bullets, check for collision (soon)

FollowTarget will be used for making enemies that always chase the player, and to move the camera with the player.

I need to figure out a good way in grouping and pooling the entities. Currently I have a Scene class that keeps a list of Visible entities to draw, and lights. This is good for passing to the BasicRenderer, and you can use any Camera you want with it. Additionally, I store the bullet entities in another list, which gets passed to the BulletCollision system.

The problem is that when the objects are defined for other behaviors, such as bullets, they are referenced in more than one place. When I have to erase a bullet from the bullet list, the bullet still exists in memory. It remains in the Scene's list, so the bullet is still drawn and frozen in place. So for now I may just deal with putting ALL entities into one list, to have one place to add and remove entities to, and have each system filter them out in real time.

That basically sums up how far I've gotten with the game. Like I said it's just a sphere (placeholder for a player model) that is moved around with the keyboard, and in an empty background. I will be adding a "target practice" test before having enemies with some sense of AI. If there's more time next week, perhaps doing more work with the graphics as well.]]> Fri, 12 Apr 2013 16:31:00 +0000 http://www.gamedev.net/blog/1621/entry-2256284-weekly-update-of-top-down-shooter/ http://www.gamedev.net/blog/1621/entry-2256251-one-game-a-month-here-comes-a-new-game-project/
What? Another game already? That's right, but this one will not be as big as my racing game project, which I expect to be ongoing for several months and likely at least a year. No, this game will be a short-term project, only planned for one month as part of the One Game A Month quest. I want to get in the habit of finishing games quicker. (Maybe then I could rename the blog Electronic Meteor Games! Imagine that) I want a game I can make more quickly and easily, and just as well be leveraged by the coding experience I have gotten so far. So it will re-use some of the code I'm currently working on right now, but refactored to fit the needs of the game.

The game will be a twin-stick top down shooter. The idea may not be original, but carrying it out should be fairly easy. I do not have a name for it yet, only know at least some features in it will include multiple levels and upgradeable weapons, local multiplayer (not sure yet if I can finish online networking code in a month), and a cool lighting atmosphere for the graphics. So basically what one may expect from a top-down shooter. Characters and setting will be fairly abstract and basic. I don't have much know-how for modeling human characters so it will be robots blasting other robots.
Here are the main goals I intend to follow for the month-long project:

• Simplistic but nice to look at graphics and setting
• Multiple weapons and enemy types
• Controller support (gotta really get a controller for that though )
• Learn some more AI programming as I go along
• Use what I learned from Meteor Engine for the graphics
• A lighting mechanic to hide/show parts of the map (somewhat of a "fog of war" for a shooter)

I have been mostly inspired by some of the fast-paced games being put up on Steam Greenlight to do a top-down shooter. It's a genre that is simple fun and engaging for many people, and I believe that a (stripped down) top-down shooter can be another good game for budding programmers, comparable to platform games. So for this month, I will be slowing down progress of the racing game to work on this one.

On the AI side, I have been reading this set of tutorials to create a state machine. Many game programmers may be familiar with the game state switching pattern to code a complete game. These tutorials take it further in applying it to other ways, like setting up rooms for a dungeon crawler or computer-controlled AI characters that follow their own motives. The latter is the one I'm most interested in. I plan to implement the tutorial code for this game to give me a head start on the AI. It won't be pretty but the functionality is what counts here.

For graphics, I mentioned the Meteor Engine, but I will not be using it as-is. Rather, the game will have its own graphics code that will take several ideas from the engine. It will be a trimmed down, sort of "lite" version of the engine code, using mainly deferred rendering for graphics. The intent is to provide a setting with many moving lights, and most outdoor daytime scenes aren't good for that. Features include mostly dark rooms, bullets that light up the room along the path they take, reflective surfaces on characters and level objects, and point light shadows. A lot of the visual inspiration comes from the Frank Engine demo, so expect the game to look more or less like that.

I will code this with XNA, as usual, but I will also try to get it portable to MonoGame. I have been researching this for a while but attempts to port any of my code to other platforms haven't gone well so far. MonoGame (in its current 3.0 version) on Mac seems to be a no-go with Snow Leopard, something to do with the Apple SDK's not being up-to-date with what MonoDevelop uses so I would have to upgrade XCode to 4.2 which requires a Lion upgrade. Not up to doing that right now. So it will likely be on Linux before Mac The cross-platform support is not part of the month-long deadline, it's just something I would like to do to take my game further like online multiplayer.

I would like to get started today with programming the game, if I want to finish it before the 30th. Just for today to use a placeholder model for the character, draw everything with basic graphics and make the character shoot in all directions. At that point it's not very different logically from a scrolling shoot-em-up. So look forward for more posts related to my month-long game. It's been a while since I actually release a game and I want this to be the most complete game I've released so far.]]> Wed, 03 Apr 2013 22:09:00 +0000 http://www.gamedev.net/blog/1621/entry-2256251-one-game-a-month-here-comes-a-new-game-project/ http://www.gamedev.net/blog/1621/entry-2256232-terrain-picking-solved/
In the meantime, though, I can move on to creating the brush and mesh placement tools. Mesh placement should be easy, as I want most objects to be touching the ground. Placing meshes will also be treated as brushes so you can fill the landscape with loads of objects quickly. For now I have this video as a proof of concept for testing.



Some ideas on the placement tools:
- Mesh brushes will likely be done the way of Poisson Disk sampling as demonstrated here, so the spacing of objects looks natural and you don't have to think much about how their placement looks.
- Objects can still be changed individually if you wish. A single Selection tool will make it possible to change an object's scaling and location.
- Rotation can be done on a basis of either having all objects orient towards the surface normal, or ignore the Y component. Rocks, for example are fine for rotating in all directions, but trees and buildings should generally point up.
- A toggle switch for each object so you can snap its vertical position to the ground surface in one click.

Physical interactions with the objects will come a bit later. I will at least need a wrapper class to associate mesh instances with BEPU Entities.]]> Thu, 28 Mar 2013 19:57:00 +0000 http://www.gamedev.net/blog/1621/entry-2256232-terrain-picking-solved/ http://www.gamedev.net/blog/1621/entry-2256223-hitting-the-crossroads/ Long post ahead! This will mention several things. First, I still want to keep working on Meteor Engine but doing it concurrently with a game means I will not put as much time into it as I once did. However I will try to keep you updated in a better manner, so to seperate game progress from engine progress, I will be headlining them separately. (A changelog of my engine is found at my blog if you're interested.) I also want to do more visual documentation of my work. As of now I am a crossroads with my game and trying not to juggle too many things at once. I guess the scope of the project is starting to catch up with me, but I do not want to see this become another piece of abandonware.

The puzzle known as terrain picking

Now back to the game. I'm at a point where I have several options to choose from on how to continue on with my racing game. I gave it a temporary name, Custom Racer, for now. It's gotten to where I would have to document and pre-visualise more plans for taking on the various aspects of the development process. Time to break out a pad of paper and start drawing out some stuff!

So I have a terrain viewer, some test menus, and a screen system. I wanted to move first to the terrain editor, and I have some idea on how to implement some of the GUI, to activate different states, editing modes, etc. I tried a immediate mode GUI sample that works but I decided against it and just wanted to build on the menu system to make the editor GUI.

But I am stuck on how to write the functions to edit the terrain. More specifically, terrain-to-ray intersection code. It's stumping me. I have a RayPicker class that can cast a ray out from a spot where the mouse is clicked, and it can pick and highlight chunks of the terrain where the ray intersects. Progress! It looks neat and all, but I need to find out exactly where in the terrain the ray hits. I know how to apply triangle intersection code for finer level of picking in the mesh chunks, that's not the problem. The problem is I also want to know exactly where in the triangle the ray hit. Something of that precision is needed for my terrain brushes.

If I limited myself to only picking triangles, the triangle can be any of three points in the terrain. When looking straight down, all the triangles look like right triangles, so I can simply pick the point that is halfway along the longest edge. But I'm still snapping to points on triangle edges. I don't want the brush cursor (and its area) to be limited to jumping from point to point.

I'm using third party code for triangle picking and I don't know what some of its single-letter variables mean, and hoping they have barycentric coordinates so I can project from them the exact location on the map. Looking at this Lighthouse3D article for sample code, it returns a point with two coordinates, but barycentric coordinates have three, so those are probably not the same values (or at least not directly).

Cleaning up the menu system

Also, I've been fiddling around with the menu system and trying to make it easier to use. This is not as big of a priority as the terrain editor, but some of its components will be used in the GUI anyways. The menu system is a mess of sprite batching, quad rendering, and skin objects with optional XML to load. All Menu components are drawn pretty much outside of the context of the Meteor Engine. Not good, you say, for tight integration, but as they are just 2D sprites that approach will have to do for the time being. Ideally the best way to make interactive menu movements and events is with scripting. But I'm not ready to deal with an added hassle of using a scripting engine. I'm fine with data-driven behaviors for now.

While working on this, I renamed the abstract GameScreen class to ScreenElement. It makes more sense to call them this because I tend to think of a screen as the program's window where everything is drawn, and several of these come together to fill up the screen. I'm deciding whether to make each text element and button its own ScreenElement, complete with transition animations.

Instanced models and interactions

This one has been on my list for a while and more to do with the graphics engine itself- how to interact with specific instances of a model. Right now they have no IDs- they're just a number in a list. Great for stuff you just want to set and forget, but if you want to make a hundred boxes and have them all interact as physical objects, there should be a way to keep updating all of their positions.

I knew that way back when, I did get physics to work with instanced objects, and it's good thing I still have the project. It was one of my first 3D XNA projects was some kind of test program with you controlling a ball similar to Marble Blast or Super Monkey Ball, and subject to the laws of physics. It would spit out 5 boxes in different directions which then become part of the world. It was also my first time using BEPU Physics, and thanks to the straightforward sample demo, I was able to get it working in my program quickly.

Looking back at the code I remembered how I accomplished this, which basically was putting in the physical Entity data into my drawing code, and always storing it in a Model. Straightforward for a simple game, but I now want to keep my graphics code and physics code separate. I can't simply make a function that passes both a physics Entity and a Model mesh to create a new instance because then the engine will have be aware of physics-related classes. So I will either make a wrapper class in the game to associate the Entities with the Models, or write a class extension to the engine. The class will also need to keep pumping the Entity data into the renderer to update it on every frame.

That's a lot of stuff I have to think about, but writing it out here helps me in planning it. There's gotta be other programmers out there that tend not to pre-visualize their projects for one reason or another, but somehow must follow through with it.]]> Wed, 27 Mar 2013 17:42:00 +0000 http://www.gamedev.net/blog/1621/entry-2256223-hitting-the-crossroads/ http://www.gamedev.net/blog/1621/entry-2256184-the-current-game-plan/


Now to move on to the game structure itself. I'm not too keen into drawing UML diagrams or other fancy charts, also because I have not gotten really comfortable with pre-visualization tools on the computer. I'd rather sketch them on paper and take some photos of it with a phone. Guess this calls for getting a drawing tablet (anyone have one, does it greatly increase productivity even for programmers?) However, at least I have a tree-like structure for my code organization.

This planning comes easier as I figure out the first thing I want to do with my terrain loader is to put it in a game state to represent the in-game map editor. I have barely mentioned it in this journal, but I made a puzzle game clone as a learning experience in building a screen and menu system from an XNA sample, where multiple states and screens run independently of each other. The game may not be 100% done, but its code is stable enough for me to be able to port the system into this new game. Because this would be the most complex game I've attempted, I look forward to seeing how far I can take it. With a loading screen and transition to game modes are in place, it will at least finally start feeling more like a game than a tech demo.

The graphics engine is still a work in progress so I will work on it together with making the game. The game code will be organized in three different areas: Core, Game, and Screens.

Core

• Graphics engine (my own)
• Physics engine (BEPU)
• File saving/loading
• Input
• Networking
• Screen system (from my last game)
• Menu interactions
• Screen drawing/updating system

Game

• Game logic, AI
• Player interactions
• Game objects
• Editor
• Editing tools and functions

Screens

• Background(s)
• Loading screen
• Menus
• Gameplay modes
• HUDs and interfaces

Core contains all the systems that deal with the lower-level workings of the game. Sending data to the graphics engine, setting up and managing physics (using BEPU for this one), input management, and the loading and saving of files all go here.

Game contains all the very game-specific logic that's all about setting the rules, game modes, and specific interactions with game objects. They all tie into Core in some way, depending on what they are responsible for doing. A more specific area, Editor would include all the tools and functions used for the game's map editor mode.

Screens can be seen sort of like game states and also like components that, when grouped together, can describe a game state or mode of behavior. They are loaded and ran from the screen system, and either specialize on displaying information related to the game, or tell the user what actions are available. Background screens, gameplay screens, HUDs, inventory screens, and menus would belong here.

As you may have noticed, the three groups tend to progress from low-level to high-level code. This was not really intended, but does give me a better idea of how to pass data around.

When the program launches it add a Screen to a list, which loads the content to be rendered. Here is the game loading a terrain in real-time, with some interactions handled by an "Editor" screen.



There are a few issues I have to take care of with the screens and graphics. Both the screen system and graphics engine are loaded as XNA game components, which means they draw and update automatically within the game, outside of the screen system's control. Although the content loading code is in the Editor screen, I need the option to make the explicit choice of what order the graphics should be drawn, so that any graphics that are set in a particular screen get drawn with that screen's Draw call.]]> Wed, 20 Mar 2013 16:47:00 +0000 http://www.gamedev.net/blog/1621/entry-2256184-the-current-game-plan/ http://www.gamedev.net/blog/1621/entry-2256162-quick-screens-triplanar-normal-mapping/
Without shadows or post-process FX, the view in the first screenshot takes about 9-10 milliseconds for one frame using forward rendering and 4x MSAA, and 16 ms with deferred rendering. Shadow mapping remains a big GPU-heavy step, taking up to 25 ms in the process.

I also achieved my goal of making the forward renderer's output indistinguishable from the deferred renderer, at least without shadow support (the shadowing code has still not started for the forward renderer). The program can be written in a way to make both renderers switchable on the fly, which is useful when many dynamic lights enter the scene.

Edit: Some more screenshots, with better textures. These are free textures from FilterForge.







Next, I'll be starting the terrain editor in raising and lowering the elevation. The engine currently draws the terrain with geo clipmaps which just aren't working well enough for me. I will be switching to geo mipmapping.]]> Sun, 10 Mar 2013 21:36:00 +0000 http://www.gamedev.net/blog/1621/entry-2256162-quick-screens-triplanar-normal-mapping/ http://www.gamedev.net/blog/1621/entry-2256148-more-details-on-the-racing-game/ Hey, you know that racing game that's supposed to happen? Well, I still plan on making it happen, and my ideas are becoming a bit more solidified now. I always planned on making anything but a super-serious racing sim, because those take too long to get all the details right in the physics and the authenticity of the look and feel. Also I won't have permission to use real-life cars in the game. Previously, I said I wanted to make an off-road racer, but that might still lead to some high expectations on the landscapes and environment. Also, I would have to limit myself to how the vehicles should handle. So for now, it's a general arcadey racer that will just happen to have some trucks and ATVs in it.

Now on to some of the main features of the game.

Multiplayer

One of the things I want my racing game to have- MULTIPLAYER. That's a big one. I want people to race other people, and especially across different computers. So this also means including network play. I have never done a networked game before, so this part would be completely new to me. I don't know how to set up a waiting area, or find available players online. Should I use client-server or a P2P architecture? So many things to figure out. Lidgren is a popular library for online gaming in XNA, which I will probably use anyways for reasons stated later. Work on this likely won't start until about halfway through the development process.

Before that, and easier to test, is to have local multiplayer. My graphics engine will make split-screen support a breeze, with the way I can hook up different cameras to the same scene and draw it several times. The multiple controller support should be easy as well.

Customizing tracks

Another big one, is wait for it- track creation. Yeah, it sounds ambitious but I figure if I am gonna aim for making the track creation tools easy for me to program, it might as well be user-friendly and simple enough for players to use. See ModNation Racers and a bit of TrackMania for inspiration, but moreso ModNation Racers because their editor looks more fun and inviting to use. And I don't mean to brag much, but holy cow, my graphics engine looks about as good as MNR's... I'm basically halfway there ;) Their splatting techniques do not use a million textures, and cliff textures automatically appear in steep sides.

"Why are you making a clone?" You may ask. Well, it's obvious it's one of my favorite games and it gets me inspired. Other people have made clones other than for learning purposes, like CounterStrike clones or _gulp_ Minecraft clones. (Is it just me or are MineCraft clones the new MMO clones?) However one important point is that MNR is only sold on Sony's platforms, and I do not plan on making something to directly compete with the other popular customizable racers. Besides, TrackMania and TrackVerse seem to co-exist well on the PC and TrackVerse has put their own spin on the genre with a faster-paced WipEout feel. It would be great if a WipEout like game could come out for XBLA or XBLIG but I digress.

Other platforms

That brings me to another feature I plan later down the road, which is cross-platform support. The ultimate goal would be, aside from Windows, to run it natively on Mac and Linux. This obviously means I cannot use XNA forever, and going to MonoGame for non-Windows builds looks like the most attractive option. For those platforms I will need to rebuild the engine library with the MonoGame references instead of the XNA ones. The sooner I can test out the engine on Linux, the better. Lidgren is also used with MonoGame, which will smooth out porting the networking code when I get to it.

The reason I'm sticking with XNA for Windows is because it uses DirectX, while MonoGame for Windows uses OpenGL, and driver compatibility is more of an issue with OpenGL on Windows. I had Linux Mint installed before, but removed it a few months ago. DarkGenesis' blog looks to be a good resource for porting MonoGame applications, so I'm bookmarking that for now.

Gradually I will be integrating the screen system code that I wrote for the puzzle game I worked on a few months ago. It includes (almost) everything I need to create menus and screen states for the game. This code is big enough to be in its own library, and it may be easier if I just build it as such.

So these are some of the main features of the game. It's gonna be a tough road ahead, but I think I can make a lot of progress in a few months. Out of these three, the first one I will begin work on is the track editor. It's going to be the backbone of the game development process, so it makes sense to begin here first.]]> Thu, 07 Mar 2013 00:43:00 +0000 http://www.gamedev.net/blog/1621/entry-2256148-more-details-on-the-racing-game/ http://www.gamedev.net/blog/1621/entry-2256134-how-low-level-should-you-go/
Many stick to what they know and keep on keeping on with XNA, or are moving to the cross-platform MonoGame. A couple others want to focus more on getting things done quicker and go with something high level. One of the prominent XBLIG developers (creator of the million-selling FortressCraft, among 10 other games) spoke about his future with games and his abandonment of XNA for Unity, though he expressed it much more bluntly. Given his short experience with Unity, I felt he jumped the gun too quickly on what's the best way to go for indie development. No, I don't think it's a bad way to make games, and I am trying it out and hope there's enough scripting for the avid programmers to do. But this feels more of a "first impressions" view on Unity, and made it sound like it's the only right way to go for indies. That's on top of a jaded feeling that Microsoft pulled a fast one on him. I'm worse off, though, I haven't released one XBLIG game and sadly I don't even have an Xbox at this point.

He stated that he put a lot of initial work and received a lot of experience with coding in XNA as his games grew more complex. But much is clear about the overall message- some people just want to make some goddamn games. His few last statements were of particular interest to me:

If you want to spend a huge amount of your available dev time re-inventing the wheel, go with XNA. Go with MonoGame. Enjoy scratching your head about calculating tangents for reflections, wondering how cascading shadows work, and if you should implement A* or Dijkstra’s for route-finding. Me, I’ll be busy getting on with writing the game.

The tone of this paragraph seems to say "While I'm making a game, I'm also leaving those engine programmers in the dust". Oh wait, this kinda does sound familiar.

Every developer has their own interest and affinity towards a topic. Just going from his write-up, he seems to be more interested just about the things that define a game. Its rules of play, its design, etc. I have an affinity (or at least I want to improve) towards graphics programming. Which is why I don't mind scratching my head over shaders and shadows. As a counter-example, I do not really fancy AI or physics programming. I plan to use BEPU Physics or Bullet XNA (especially since I'm already familiar with them) to make things move and bounce all over the place. And for AI I will just follow code tutorials with just enough custom work to make it feel decent.

That preceding article could probably be a debate starter about high-level versus low-level style of game development. I'll give him something though- I realized that I could put most game programming blogs into two main categories- blogs that talk about their games mainly to non-programmers, and blogs that contain very down-to-the-metal, get your hands dirty with code and math articles. Those "Luminance-based edge detection techinques" articles tend to not live in the same home as "New level packs today!!" articles. Personally, I would like to get a following that consists of a healthy mix of both game programmers and all those gamers that don't know anything about programming, and I will need to work more on the latter. There's still a glimmer of hope of getting something on XBLIG, just to follow through my goals.

Barring that, is there any amount of re-inventing the wheel that should be tolerated? How much time can be spent on low-level algorithms until it becomes a hindrance to your productivity and bore your readers that eagerly wait to play your game?]]> Mon, 04 Mar 2013 00:17:00 +0000 http://www.gamedev.net/blog/1621/entry-2256134-how-low-level-should-you-go/ http://www.gamedev.net/blog/1621/entry-2256111-a-first-look-at-the-forward-renderer/ Here's a few quick test screens with the forward rendering in the engine, now that I have added shader support for terrains. The differences are subtle but somewhat surprising. First I'm testing out normal maps to see if they look OK.


Now for some money shots- comparing deferred and forward side by side.


Then I changed the splits so each half of the view is rendered separately. Deferred rendering is on the left (with shadows in the first image) and forward rendering is on the right.




I've noticed some harsher lighting in the forward renderer, but these screenshots are a bit out of date now. But I discovered last night that I forgot to gamma-correct the texture colors in the forward renderer. Now they look more or less the same.

These are not post-edits by the way. These are taken in real-time, as I decided to use the engine's ability to handle simultaneous rendering profiles and output the buffers to split-screen. This is a good way to compare and tweak various results as I'm creating new shaders, like a "before and after" test. It's simply a matter of adding an extra constructor to the list of profiles, and the engine loops through them. The only big limits are the buffer memory and GPU performance.

For these tests both images are actually rendered in full resolution, but cropped/resized for the frame buffer. It's not efficient, but it's good enough for early testing right now. However, the ability to swap in a forward renderer is a game changer for development- now I can test and compile my builds on my old MacBook. It will be pretty nice to see how it holds up to its crappy integrated GMA X3100 chip, which only supports the Reach XNA profile. It will be made selectable on runtime depending on the graphics adapter support.

This means possibly downgrading to Shader Model 2.0 for the forward renderer. Or maybe just have two versions so if your computer supports SM 3.0, use the more advanced one for better visuals. There's no way I could transfer my current shadow mapping setup to 2.0 without some serious nerfing of features. As long as it doesn't run very choppy on integrated graphics, I will be fine. Speaking of shader changes, all my scene shaders use the same vertex shader programs, so it looks like a good time to break up the .fx files into smaller parts.]]> Thu, 28 Feb 2013 00:15:00 +0000 http://www.gamedev.net/blog/1621/entry-2256111-a-first-look-at-the-forward-renderer/ http://www.gamedev.net/blog/1621/entry-2256083-where-i-am-now/
Over several years I've coded in C++, Java, some Processing, HTML, PHP (which I do for a job right now), and currently C#. I got into the XNA when it was entering its middle years, and my first game with that framework is still a goal that's not close yet. So I am not sure how I would feel about releasing an Xbox Indie Game well into the twilight years, but for now I'm sticking to XNA. I've already managed to build a basic graphics framework while learning DirectX 9, and moving to XNA helped me approach more advanced concepts without a lot of the low-level fuss.

With that said, I'm building a graphics engine and a game to go with it. They will be worked on at the same time, so if there's something my game needs from the engine, for now I will give that feature a priority for the engine if it helps on finishing the game.

Engine thingies include:

• Component-based rendering system, meaning each rendering step is contained in its own class. The steps are chained together with inputs and outputs, just in code for now.
• Mesh instancing and frustum culling by instance (I plan to add quadtrees eventually but brute-force culling isn't a botteneck right now)
• Blended cascaded shadow mapping for directional lights
• Post processing effects like FXAA and soft-focus DOF (again, as discrete rendering step components)

Without further ado here are some screens of my engine at work:



I plan to make an off-road racing game, which will be more quick arcade-like action than sim racer. Think MotorStorm with a bit of Excite Truck. I have already started a separate project for the game, but for now it's nothing more than an empty terrain with a first attempt at getting the physics engine (BEPU Physics) working with the graphics. Here's the current list of my important things to do.


Racing game

• EVERYTHING!!! (but especially starting on the physics)
• A rudimentary level editor (at first), will not have a very visual interface at first
• A controllable physical body, just as another way to move the camera for now

Engine

• Easier manipulation of mesh instances
• Forward rendering
• Impostor/billboard drawing
• Easier-to-configure shaders

That's all for now. I will probably explain more about how I will tackle the issues that come from making my first 3D level editor. This will be the biggest challenge, but my productivity should skyrocket from there.]]> Fri, 22 Feb 2013 18:57:00 +0000 http://www.gamedev.net/blog/1621/entry-2256083-where-i-am-now/