Codename ShackRPG has an official name!

With the nearing of the Dream Build Play deadline, and the completion of a pre-alpha build, I have taken the ShackRPG code name offline and given it an official title…

Meir

There are quite a few things left that still need touchups and some sub-systems that still need to be written, but for now.. the pre-alpha build is up and ready to be polished for the Dream Build Play competition. The only dilemma for me right now is do I add more content to the game? (Temporary storyline, more encounters, items, quests, maps, dungeons, etc) or do I polish what is already in there and give the Dream Build Play judges less content but a more fun experience?

For example;
- The battle engine is in, but only 90% complete (Magic is not implemented)
- The collision system is still “Loose” and I would really like to tighten that up and make it feel great.
- There are no special effects such as particles or explosions
- Dialog system, while crude, is in place. I would like to expand this to create a complete “Cut-Scene” system.

The Pre-Alpha (DBP build) has 3 main areas and a 1 room dungeon (4 maps), 1 major quest line, 8 or so weapons and armor, several music selections, several different monster encounters, and a few random scattered quests. Is this enough? Maybe… maybe not? The deadline is still in a few weeks so I have time to polish a bit and expand the demo a little.

Everything has been a great journey so far, learning how to program through this project was both a blessing and a curse.. but the engine work is almost complete and now the story is being written and content creation is falling into place. Within a week or two, I should have some screenshots and a “promotional video” of actual gameplay that must be submitted to the Dream Build Play site, so I’ll share them with everyone here as well.

So hang in there just a little while longer, and I’ll start leaking some tidbits on the game itself! :) With the demo nearing completion, it is time to set my sights on a full length game for the Community games. My deadline is Christmas, but we’ll see how things work out.

360′s content pipeline gives me a headach!

Oh man, I’ve spent the last week learning the ins and the outs of the Content Pipeline, trying to write readers / importers / writers / data types etc, to the content pipeline… and it was all going well, until i hit F5 :( Damn thing wouldn’t build!

Creators Club msgboard and a few friends who know their way in and out of the 360 helped out a TON with my persuit of knowledge. I don’t know all, or even half, of what goes into the content pipeline programming.. but at least i know “WHY” its doing what it does.

So I’m back on track now, we’ll see if this set me back enough to where I’ll miss the dream build play deadline, but I hope not. And for all of you folks who are looking into the content pipeline for the 360, remember these fun facts that will save you a TON of headach if you don’t already know how to write your own custom readers / writers;

1) The ContentReaders should be placed in the same project as your class you’re reading, preferibly at the bottom of your class.cs file.

2) Content writers need to be in a ContentProcessor project file, and they will be created at build time (not run time) so make sure that any classes you’re referencing, either make a copy and put them into that project (IE: Player.cs from your main game, make a copy, and put it into your Content Extention project file with the name PlayerContent.cs so you don’t confuse the two) or do what I did and have a shared project “Data” stash.

3) HOWEVER, if you DO do what i did, remember that the 360 and windows needs their OWN VERSION since they’re different assemblies. This gave me the most headach :( So my solution now needs 4 projects; 360 game project, 360 data project, windows data project, content pipeline extention project.. Oi, pass the advil!

Thanks go out to Stephen and the whole crew that helped me through, and a BIG thanks to RomSteady and Mittense at shacknews.com … couldn’t do it without you guys :)

Next up, working on releasing a demo!

ShackRPG: Battle System Almost Complete

Battle system didn’t take as long to implement as I had thought, which is great news.. because it means I may just end up getting everything done in time for the Dream Build Play competition!! This battle system is by far one of my most complex systems in the game, for the very reason that makes it fun in the first place. I’ve tweaked it a few times because it was slow and un-interesting, but after playing through a few battles with the new system I think I have things tweaked enough to make battles fun and exciting.

So on to bigger and better things I always say. There are a few systems I’d like to have complete before the Dream Build Play competition, but not 100% necessary, including but not limited to:

Content Readers / Writers: With the current system of XML data, all of the content is being read in via the System.XML namespace. On the PC this doesn’t really give a lot of problems, but on the XBox things are terribly slow when reading new content.

Save System: Right now the game isn’t long enough to support such a system, but its an RPG.. you’ll need to save eventually! I have not even started working on a system to save your progress.

New Assets: While I am just using the assets from the RPG Template right now, I would love to eventually build my own. Not a priority right now, as I’d love to get a tech demo out first.

Cutscene / Scripting system: Cut scenes are possible with the systems I have in place, but I’d love to implement a dynamic scripting system that lets the user really experience the story.

Polish!!: Naturally everything will have to be touched up, working good, bugs squashed, and looking pretty.

So while everything is going along at a fairly quick pace, it is time for me to start putting together something you all can enjoy. I hope to have a few trailers up in the next few weeks and some screenshots of some action, and a demos worth of story hammered out for the Dream Build Play competition.

ShackRPG: Deployed to the Xbox360

With the battle system framework completed, i took the opportunity to deploy ShackRPG to my 360 for testing. The surprise? Things went very well and I didn’t experience any crashes or major bugs!! I’m happy to say that with the exception of a few details, things went pretty flawlessly.

Having said that, there are quite a few things that I messed up with so far during development, that I have to now go back and change.

Window locations: Fixed
I tried to keep everything in enough so the game would render correctly on a TV, but there were a few windows that I forgot to convert to my % system, and they were cropped.

Movement Speed: Fixed
For some reason, movement speed on the computer felt solid but when I deployed the project to the 360, it felt way too quick. Character feels solid all around, and the way I did collision detection and movement feels really solid with the controller, but I just had to turn the movement speed down a tad.

Debug Components: Fixed
There were a few components that were written with the PC in mind, and I had forgotten to change a few things with the 360 development. For example, the FPS display was at Vector2(5,5) which was off screen on the television screen. Also, in order to view active screens in the screen manager, you have to press Ctrl+Alt… obviously there is no Ctrl or Alt keys on the gamepad.

Loading Times: In Progress
The one minor mess up I had was with loading times. Anytime I had to access an XML file i would get between 1 to 5 seconds of loading time lag. This is most notable with loading a new map, but you could also see it when completing a quest. Talking with a friend of mine, he says the XML reader is not as efficient in the lite version of the .NET framework, and I should convert them to the Content Pipeline. Good advice? Sure, not what I wanted to hear however since I am trying to finish things up on the engine side so I can begin story development. This news means I may just end up missing the Dream Build Play deadline unless I can research the necessary fields quickly.

So there you have it, my first Xbox360 deployment was a huge success in my eyes. Some things needed to be tweaked, others changed, but for the most part everything works and works very well. The battle system is about 25% complete, and it is looking very solid and action packed at the moment. We’ll see how it all ends up, but for now its looking like a winner.

ShackRPG: Quest Demonstration

Quest journal functionality

This section was quite fun to write! The quest system is not overly complex, but flexable enough to enable some pretty creative quests to be executed. It is my feeling that alongside the battle system, your quest system is one of the most important aspects of your game. To this end, I’ve enabled several aspects including;

Prerequisites: Items or equipment in your inventory, Monsters slain, Npcs Visited, or previous quests completed that must be obtained before the quest may become active.

Objectives: Could be but are not limited to: Talking to several specific NPCs, killing a specific monster or monsters, or the possesion of an item or amount of gold. (Several of these are demonstrated in the video below)

NPC Dialog: Changes based on the stage of the quest.

Quest Journal: A journal to keep tabs on your active and completed quests, along with a marker indicating if the quest is repeatable.

Rewards: And what quest would be complete without its rewards?

A lot of these aspects are demonstrated in the video below. I think the quest system works for the type of game I am writing, and so far its even passed the “non-gamer” test… sit a non-gamer in front of the workstation and have them run through your “Demo” and see if they understand it / can navigate through the demo.

Well, now its time to finish up some polish, and who knows… I may actually get a demo out in time for the Dream Build Play competition :) Here’s hopeing!

ShackRPG: Menu, Inventory, and Equipment systems

Finished work on the GameWindow class, so I’ve been implementing a few items that would take advantage of this window class, mainly the Menu system!

Main Menu options

As seen from the above screenshot, once you hit the “Menu” button on the controller, this screen pops up. From here you have access to a variety of options including ways to customize the look of the system, your inventory, and your Equipment. The system structure is in place and needs tweaking for sure, but at least the groundwork is done.

As always, below is a video of the progress. Just a few more systems and a demo will be released, exciting huh! Thanks to everyone who gave me some opinions on the menu system. As always, if you have any questions, feel free to send an email my way to CraigGiles9@yahoo.com

Video of the menu system in action

ShackRPG: Engine Progress

These last few weeks, I’ve taken the opportunity to re-write my RPG Engine, and base it closer to the RPG Template engine released by Microsoft for the XNA platform. I did this for a few reasons, one of the primary reasons being I have not seen any RPGs to come out of that RPG Starter kit hosted on the XNA space. With a basic demo, and a little creativity, I wanted to show people what can be done with the tools given by Microsoft.

Current Map, Developed by EvilNando’s editor; http://xnafantasy.wordpress.com/

Fast forward a few weeks and I’ve pretty much got the tile engine done, and put together a few quick maps with a great map editor made by my buddy, and fellow XNA RPG Creator, EvilNando (Website located at http://xnafantasy.wordpress.com/ ) Changes to the Microsoft engine are plenty, but some of the notable ones include:

Modified content importers – I have not used the Microsoft importers, choosing to instead use just .xml files. Because of this, all methods of importing content from the content pipeline have been done using the System.XML namespace

Audio Engine – I really liked what Microsoft did with their audio engine, so I just tweaked it to include a “Playlist” system. Basically this is just a stack, and new music can be pushed onto or popped off of the stack at any given time. If there is no music in the stack (playlist) the general background music will play.

Collision System – I really, REALLY didn’t like the way Microsoft handled collision detection with tiles, mostly because it wasn’t compatible with my system at all ;) So instead I stripped out what they wrote, and modified my old version to handle collision in the new tile engine.

Screen Management – I used a modified version of my old screen management, and discarded Microsofts completly. It works for what I want it to do, and I made it a little more modified to handle Update Blocking and Draw Blocking on gamescreens. For example, You’ll notice in the video, the “Gameplay Screen” is the last one on the stack, but the first screen is the “Main Menu.” Obviously you wouldn’t want the Main Menu screen updating or drawing if it is being covered. Because of this, the main game screen blocks updates and draw calls to all lower screens.

Animation – Since my old animation method worked quite well, I just modified that to work with the new system. Nothing really new.

Video of the new engine in action:

There will be more updates soon, especially when I finish the next few stages of the engine (which includes NPCs, Quests, and Combat, which I will be taking an entirely new direction.. you’ll love it)

Questions, Comments, Opinions, feel free to drop me an email at CraigGiles9@yahoo.com.

ShackRPG: Game Menus, and Combo Battle System

It has been a while since I’ve posted, and for good reason. I’ve been trying to get the next segments done, but I’ve hit a few snags with a few of my design choices from before. Working through those however, I’ve been able to make a pretty cool little menu system for ShackRPG that keeps your focus on the game world without being too intrusive.

Since the game is being designed with a gamepad in mind, there are only 4 buttons being used to control everything within the game. Press the inventory button and a new screen pops up containing the game menu. Not all of these sub-screens are implemented, and because of this I have not updated the codebank yet, but I will!

Above is the character screen showcasing your equipment as well as character stats.

Modifying your equipment, currently in the ‘Weapon’ slot equipping a new weapon.

When the sub-screen menus are complete I’ll update the code bank. Below is a video of the combo system within the combat, as well as the Game Menus in action!

Keep in mind, all code can be found at code.google.com;

ShackRPG: Updated Tile Engine Part 2

With the Map class complete, we can no start working extra things into our Tile Engine to display each map to screen. In its current state, the tile engine is incomplete for a few reasons including collision detection between characters and drawing order of all layers. However, i do have enough to get the basics of the engine up and running and continue to work on the rest of the systems of the game. So, on that note, lets begin!

I have 6 seperate regions to help organize the tile engine;
TileEngine Data – Houses all data associated with the engine. 3 data fields and properties; a true / false statement on if we’re loading a new map into memory, a Map file, and the mouse location for the editor.

Constructor(s) – initializes the tile engine on startup

private void Initialize()
{
map = new Map();
map.Load(“Map001″);
}

Update / Draw – … can you guess?
Update right now does nothing, but will call the “CheckCollisions();” method.
Draw just calls “map.Draw()” … so thats very easy.

Clamp Camera – Aah this is a fun one. I’ll post the code and see if you can make heads or tails of it.

public void ClampCameraToBoundries(Vector2 position)
{
//clamps the camera to the players position
Globals.Camera.Position.X = position.X – (Globals.Graphics.GraphicsDevice.Viewport.Width / 2);
Globals.Camera.Position.Y = position.Y – (Globals.Graphics.GraphicsDevice.Viewport.Height / 2);

//Clamps the camera within the game screen
Globals.Camera.Position.X = MathHelper.Clamp(Globals.Camera.Position.X, 0, (map.Width * map.TileWidth) – Globals.Graphics.GraphicsDevice.Viewport.Width);
Globals.Camera.Position.Y = MathHelper.Clamp(Globals.Camera.Position.Y, 0, (map.Height * map.TileHeight) – Globals.Graphics.GraphicsDevice.Viewport.Height);
}

Make sense? Basically you give the method the players current positional vector and it keeps the player within the center of the screen. If the player moves right, the camera moves right. If the player moves left, the camera left. However, after that it keeps the camera on top of the game world so if the player moves left to the edge of the map, the camera will stop when it reaches the imaginary edge.

Player Movement – This region does 4 things and is quite long compared to the camera clamping method. It will take the keyboard data collected by the games Update() method to determine if the player should be moving, and which direction. It then takes the positional vector of the player, and the speed modifier of the player, and calculates what the new position will be. Finally, it will take that new position, check to see if the player is on a tile it can walk on, and if so passes the new position to the game for update. If the player is on a tile they shouldn’t be on, it passes the old position, in essence, the player has not moved. Confusing huh? It can be.

Save / Load / Create New Map – map editor functions, and these are quite long and deal with loading and saving from an XML file from within the content pipeline. I do not write my own content importers or processors, so I’ve been using the System.XML namespace. If you want to know how its done, inquire within!

I tend to organize my programs by clumping things together. I know some people do “Data fields” “properties” “Constructor(s)” “Public Methods” “Private methods” but in bigger programs I’ve gotten into the habit of clumping everything together that goes with eachother. Might be a bad habit but to each his own. I’ve spent a few days on other systems for the Tile Engine and I’ve updated the code at the projects site. Next update I’ve had a request to post about my particle effects system, so I’ll get that in order and have it out here in a few days. I also will go into my in-game map editor.

As always, if you’re interested in checking out the full source code (newly updated), just head on over to code.google.com;

ShackRPG: Updated Tile Engine Part 1

Over the past few days, I’ve been re-working my Tile Engine and Map Editor, and before I post on it I would like to say that it has been quite a bit bigger than I had anticipated. For that reason, this post will be broken up into several posts to show the basic features of the various components of the Tile Engine / Map Editor, but without having one big 30 page post on the whole sha-bang.

So on that note, we’ll start with the Map.cs file. This file will hold all of the map information, which is actually quite a bit of data. Some of the data fields include:

string Name – Map Name
int Height – Map Height
int Width – Map Width
int TileHeight – Height of each tile on map
int TileWidth – Width of each tile on map
string Tileset – Tileset used to draw the map

Point PlayerRespawnTile – Players respawn Location

List Tiles – List of textures used for map tiles
List NPCs – List of all NPCs on the current map
List Items – List of all world-items on current map (IE: Treasures)
List Portals – List of all portals leading to OTHER maps

string MusicCue – Music data to be used on map

int[,] BaseLayer – Base Layer Layout (Things you walk on top of, grass etc)
int[,] FringeLayer – Foreground Layers layout (Things you can walk behind)
int[,] ObjectLayer – Object Layers Layout (pots, barrels, plants, etc)
int[,] CollisionLayer – Collision Layer (Tiles you can not walk on)

This is most of the information needed to make a map work with this tile engine. The next step in getting the Map.cs file in order, was a way to Save, Load, and Initialize a map. Obviously for a complex role playing game, you’ll want to have several maps. Maybe a few towns, dungeons, an overworld map, city at sea, a sky level… The choices are limitless, but for every region you have in your game, you’ll have a map to hold the information. All of these maps will hold the same structure which makes it easy for the game to load and display

I really did not want to write my own content importer / content reader in the XNA engine, so I’ve stuck with the System.XML namespace. Because of this, each map will be stored in its own XML file and fed through the XNA content pipeline, but with the map.xml property set to “Do Not Compile.”

Below is a screenshot of a test map I did while testing the map engine showing off some of the map editor.

Red P = Player Respawn
Blue P = Portal to a different map
I = Item
M = NPC / Monster

The map name is called “Map001″ and you can see the XML file HERE

Not too many problems came up while working with the Map.cs file, more-so when trying to get the editor up and running.. but I’ll save that writeup for another time. Could this map file be smaller? Probably. As it stands now, it is just under 1300 lines of code. There are also several other systems needed to display the map to screen, but for anyone interested in writing their own map engine in XNA, I figured the best place to start was the map itself.

Full project source code can be found HERE
Project homepage can be found HERE

Next time I’ll go more in depth on the Tile Engine, and some of the Map Editor.