Showing posts with label current development. Show all posts
Showing posts with label current development. Show all posts

Long Time... No Game

It's been a while.  Can't say I'm any closer to releasing a game, but I have become a better code monkey after two years at an IT desk job.  Microsoft has abandoned XNA in the time I've been away from it.  Monogame has [sort of] risen from its ashes and Unity is all the rage.  Independent game developers abound on every platform from the PC to the VITA.  Self publishing is a hot word with the coming of the new consoles this fall.  I don't think there's been a better time to be a hobbyist dev.

My wife and I also have a brand spanking new human child, so that takes a small bite out of my free time.  Still, I like to poke around in game development frameworks.  I picked up the old 2d XNA engine I started coding back in the 3.1 days.  After a couple of hours of mucking around, I've added 25% more dimensions.  Yes a simple 2.5 engine with the ability to zoom and rotate.  My dream was to create a more simplistic version of the SRPGs with which I used to spend so much time: Advance Wars, Fire Emblem, etc.  To that end, I implemented a couple new types of tiles for the engine.  I can now work with hexagons and isometric squares.

TileEngine screen capture
The basic tile engine displaying a hexagonal grid of water.  

Tile Engines

A 2D tile based engine will need to be implemented for my RPG. While I would have a lot of fun creating my own in between banging my head against the wall, a developer named Nick Gravelyn seems to have figured all this out in XNA 2.0. His development blog has a link the video series he created. It gets rave reviews on the App Hub forums, so as soon as school and work let up a tick, I'll start digging through these. It looks like a really nice roadmap. Hopefully I'll be able to adapt some of it to 4.0.

Beginning 3D Game Programming

Today I'm moving further into Learning XNA 4.0 and reading a bit about 3D game programming. There's just a little bit to know: shaders, particle systems, modeling, effects...

While I'm interested in the subject, it doesn't strike me as entirely necessary to reach my goal of developing a simple tile-based RPG and deploying to Indie Arcade. As much as I'm enjoying the book, I'm going to switch gears for a bit and look for more information on tile systems, map generators, and the infrastructure necessary for tracking all the systems that go into an RPG: characters, enemies, items, equipment, stats, leveling, etc, etc, etc.

Still, 3D programming is an interesting topic and I'm anxious to learn more.

"Matrices are behind essentially everything you do in 3D graphics."- Aaron Reed

Enticing isn't it? He reduces it to the point that it all sounds so easy. Well let me tell you that it wasn't perfectly simple to programmatically generate this triangle as a primitive in a three dimensional space:


Entertaining none-the-less. And the hipsters like them.

Making Some Progress

My place of work is closed today due to the weather. Only a slight surprise there given the storm - we received around 16" of snow. Even in Wisconsin, that's considerable.

I'm working on some game programming today. The demo app that is created in Aaron Reed's book Learning XNA 4.0 is complete. This was a good exercise for being introduced to the framework. I've learned a lot: collision detection, sprite generation, simple AI, and generally how the different basic parts of XNA work together.

I finally found a codec that works much better for capturing game video. Here's a video of the progress:



Each enemy sprite is spawned from a random corner of the play window. They are spawned at regular, though random intervals that decrease as the game progresses - more sprites are on the screen at once. You can see the simple animations of the individual sprites.

"Power-up" sprites are the skullball, bolt, and plus sign sprites. The skull slows the player down to half speed, the bolt speeds them up to 2x their current speed, and the plus doubles the player size. These are all cumulative.

Collision detection is simply a rectangular hit box. The size of that hit box is adjusted when the player is enlarged by the plus power-up. A score is totaled based on the number of sprites that do not collide with the player and are allowed to pass out of the game window. Certain sprites are worth more points based on their type and speed.

These are all incredibly simple and basic bits of coding, but it's an entirely new experience to me and it was very helpful to go through this exercise.