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.
The basic tile engine displaying a hexagonal grid of water.
A very high level draft of my design document has been completed. Since I'm learning more about XNA daily, I wasn't too specific regarding some of the technical details. The document does outline a few technologies that I'm certain will be used: a 2D tile engine, spritesheets, an XML based map-editor, etc. I've spent the most time on the story. That's what every good RPG needs, right?
The idea is that some bland everyman from an office is transported to a fantasy realm for some RPG fun. If it were a pitch for a movie, I don't think it would sell too much popcorn, but I'm excited about some of the specifics. I'm starting to appreciate the writing in RPGs. Yes they are often rife with terrible dialogue, endless male power-fantasies, and flat characters. I've been highly critical of many RPG stories, but now I see how it easily happens. I fell right into a number of cliches as I was writing. No, Final Fantasy series, I still think you have gone off the rails, but it's definitely challenging to write an interesting story while remaining in an RPG framework.
Players have certain expectations when they play an RPG. Those expectations dictate many parts of how the story must develop. For example, there has to be a number of things to fight, there must be a number of locales to explore, there probably should be some sort of climactic boss encounter to close out the experience. I'm not going to buck convention when just trying to actually get a functioning first RPG, but I still want to deliver a mildly interesting tale.
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.
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.
So now I can post from my smartphone. Look out, internet. Prepare to have a tiny drop of my drivel plink into the near limitless bucket of one your servers.
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.
I'm working further into Aaron Reed's Learning XNA 4.0. So far, it's been a very helpful introduction to XNA. Unlike some other books, he focuses entirely on the framework's capabilities instead of wasting any time bringing people up to speed in the C# language. Learning to design object oriented programs in vb.NET has allowed me to segue comfortably into C#, but I still have had to look up a few syntax and design choices in the language.
For instance: auto-implemented properties. This isn't supported at all in vb. It is a nice simple feature in C#. If you don't need any extra logic in the accessors of a public property, then all you need is something like this:
public int index { get; set; }
In vb.NET, you would have something like this:
Private Shared _Index As Integer
Public Shared Property Index() As Integer Get
Return _Index End Get
Set(ByVal value As Integer) _Index = value End Set End Property
It is a nuisance typing out all that extra junk just to return a variable in vb.NET, even if Visual Studio is a lot of help. I would never accuse C# of being as friendly as vb.NET, but that is handy.
Today I have redesigned the code to make it more flexible and extensible. There is a good class structure in place that will allow for quicker additions going forward. I have a base Sprite class and the subclasses AutomatedSprite and UserControlledSprite.
I've also begun to work with sound using the Microsoft Cross-Platform Audio Creation Tool (XACT). It's a nice tool for integrating audio into the content pipeline. A little clumsy in how files are added to a VS project, but once in, XACT allows for some nice design-time editing like volume control, looping, etc. You have to embrace acronyms to survive in programming.
I'm looking forward to adding some more functionality to the design that's being built with the help of Aaron's book.
