Monday, December 31, 2012

day 1 progress

Here's progress from Day 1. I didn't knock off much from my initial todo list, but that was expected. There were a few editor things that needed to be taken care of first, so now it's in a useful state. Previously I was generating the level contents from code, and I had only hooked up ways to edit existing objects in the level. Today I added a way to add and remove objects from a level. I can also load and save levels, which is sorta important :)

Added the PrimitiveMesh component. The engine has a few built-in primitives (cone, cube, cylinder) and I wanted a way to attach these meshes to a GameObject.

Adding new types of components to the engine is pretty straightforward. I'll paste the necessary code below so you get an idea. There is one bit unique to this particular situation - this is the first time I have a component with an enum member, so I manually had to write code for serializing it to json (since I wanted it to show up as a string in the editor). In the future I'll have an enum registration system so this code is completely autogenerated, and in the tool will automatically create a drop-down box in the tool to pick the value by name.

Also I need to add an Effect resource pointer to the PrimitiveMesh component, so you can choose the shader to render the mesh with. At this point is just uses a default shader. I also need to write a material parameter editor, so you can actually tweak the parameters of the shader you choose (textures, constants, etc).

Tomorrow I hope to actually tackle some initial gameplay.



Also, here's an example of a level file. It's called a level right now, but I'm going to rename this to prefab. It's really just a hierarchy of game objects with property values for components. Eventually there will be a way to reference other prefabs and override component properties, etc. For now everything is explicit. Here's the file:

January game, initial todo

Alright, I think I like the idea of a top-down "space shooter" with local multiplayer. I'll stick to 2-player for now. I'm sure 3 or 4 players would be interesting, but I won't realistically have time to test those modes as easily in a month.

So the idea is: square-ish stage where each player controls a ship. I'm thinking Geometry Wars style controls - left stick moves, right stick shoots. Let's stick with that for now - other buttons can drop bombs / fire rockets/lasers/whatever. Not important at this point, I want to get the core working first.

The stage should have walls, maybe more dynamic obstacles later (some kind of 'doors'). I'm not sure if the stage should be small enough that the entire field is visible at all times, or if I need to do split-screen with bigger levels (so there's some amount of not knowing where the enemy is). I'm going to implement the non-splitscreen version first even though I suspect the splitscreen version will be better. The engine already supports multiple viewports so there's no tech issue there.

Alright, so initial todo list:
- model a simple level in maya
- I think I have a cube in the engine Primitives library, so that will represent the ship/bullets. If not, add one.
- implement a PrimitiveMesh controller that acts like StaticMesh but exposes the engine primitive geometry
- implement a ShipController.
-- Attach a prim cube to a GO (GameObject)
-- left stick moves the ship GO
-- implement collision checks. This needs more thought to see what I can get away with. I already have ray vs mesh working for editor picking, need to extend it to return the intersection normal (which is just triangle normal). First pass just use raycasting to move the ship - this will mean we clip into walls for now (unless we dilate the mesh?)
-- right stick should fire little cube bullets - use the same ray vs mesh test to see when I hit something. I'll need a way for the raycast to return the GO hit so I can know when a bullet hits a wall vs another ship or bullet.

No camera work for now as I'll just use a fixed camera that can see the whole level.

That should keep me busy for a bit, and afterwards I'll have a little level I can fly around and shoot in.

Sounds like a game!

January game

Alright, so time to start brainstorming ideas for what to do for January. I usually brainstorm system design by trying to just jot down my thoughts, however things come to me. I usually do this on paper but in case someone out there is reading this, i'll try to jot everything down here :)


- simple mechanic
- remake a classic arcade game?
- space invaders? (have some code for this laying around)
- breakout?
- no skeletal animation system in yet, but meshes + lighting + controller input all works
- maybe do a non-interactive demo?
-- this might put pressure on turning it into a graphics demo, I think I'd rather make something 'playable' and leave pretty graphics for later months
- something Journey-like?
-- this could blow up in scope severely, and would have high art demands
- platformer?
-- not really feeling any ideas here right now, but I want to implement the logic for climbing up geometry, sliding across rails, etc
- something two-player (2 controllers at same PC)
-- top-down action battle game?
-- ie square levels with obstacles, geometry-wars kind of controls?
-- can have environmental hazards, powerups
-- this might be doable to some extent in a month.
-- i have no particle system/editor and transparencies don't currently render
-- i think it would be trivial to get transparencies working properly. I'm already building a light list for the compute shader based lighting I have, so it would be trivial to send the light list to a fragment shader instead and do "forward+" style lighting
-- need to write a quick tool to assign materials to meshes in maya. Right now it's hardcoded in the maya exporter
-- moving/rotating ships based on controller is trivial
-- 'bouncing' off of the environment will be the tricky part. I have no physics system integrated
--- integrate bullet?
--- write everything myself (some simple version!)
--- not completely familiar with what's all necessary. Can i solve this with just raycasting? I think so, *if* all walls are at right angles, can just raycast in 2 directions from each corner of ship square (in 2d) to see how far I can move

launching point

One goal for participating in OGAM is to push forward my pet engine I've been working on on-and-off for the last year and a half. Over Christmas vacation I started working on wrapping a GUI editor around the engine, and I'm quite pleased with how far it's gotten over the last week.

What I expect to do is start small. Pick one game mechanic to implement, get it working and push it out. That's just a cycle I'm going to need to get in the habit of doing. I shouldn't have too much concern over quality towards the beginning as I think it will be more important to just get into a cadence of quick iteration. I make games for a living, but I'm only really responsible for the technology behind them, and the cadence is years, not weeks. It's also going to take a little time to iterate on my own technology before it's really capable of delivering something cool. Up until now I've been building technology without a game in mind. I'm hoping that OGAM will help me turn that around - to concentrate on the game, and build the tech to support that. I think the tech is actually in a decent place where I can start doing this - a fair amount of fundamentals are working.

Here's a screenshot of the editor I posted to twitter last night:


Hello!

Well hello there. This morning I came across the OneGameAMonth project, and I'm in! I will chronicle my attempt here :)

Here is my OGAM profile: http://www.onegameamonth.com/MikeNicolella