Tiles, tiles, tiles...

So here I am again, a week later.. I did not really follow up my goals from last time. I have a hard time putting all my ideas on paper so I've decided to instead of writing a long and complicated design document I'm going to develop the game as it comes and instead make lists of features I want to implement and then create a planning to introduce them. So below follows first a little more describing image of my vision and a list of "steps" which will gradually build upon the game. These are a bit technical and doesn't really delve a lot into gameplay, as there's not a lot of it in these early stages.

"RPG4 is a hard, yet forgiving, strategic dungeon crawler similar to a rougelike. Turn and tile based with planning required in order to be successful. The game will be filled with interesting skills, spells, abilities and items you can flesh out you character with as you descend through the either handmade or procedurally generated dungeons RPG4 will have to offer."

The first step is creating the tile manager and the tile. The tile class is abstract and will be extended with different type of tiles. This step will be capable of displaying tiles on the screen with different textures, animations, depths, alpha values (different extensions of the Tile class). The tiles that will be available in this step: wall, floor, blood ("decoration"), rock and water. These tiles will be able to demonstrate the capabilities above. Some tiles have their texture determined depending on the surrounding tiles. The user will also be able to scroll around the map by holder the right mouse button and moving the mouse around.

This step will implement the actor and the player class. The actor class will be abstract and currently only exist for the player class to inherit from. The player class will be able to move around the map using the arrow keys and using the mouse by clicking on a tile next to the player. The player cannot walk upon some tiles, such as the wall and water tiles.

This step will refactor the player class moving anything that is not player class-specific to the actor class. The NPC class will be implemented and extending the actor class. The concept of turns will also be introduced. All the actors will be enumerated upon allowing them to update. On the player's turn it will wait for user input. All NPCs will each tick arbitrarily either move or just stand still for the time being.

This step will add the ability to interact with tiles and NPCs. Each Tile and NPC will have different actions when interacting with it. For the time being though, interacting with tiles will only cause the tile to change texture and interacting with an NPC will only cause the NPC to turn towards you.

This step will expand on the interaction with tiles. A list of Tiles will will also be added to the Tile class. This list will be the "targets" of a Tile. When the player interacts with a tile, each tile in the "targets" list will also be indirectly interacted with. This will allow for remotely interacting with tiles via another tile. This step will implement the switch and door tiles to demonstrate this.

This step will make it possible to save the map to an external file and load it. The maps will be saved as plain text for the time being. As the game will be a single player game, the only one being hurt by cheating is the player, therefore encrypting the maps might not be needed.

This step will add fog of war to the game. The whole map will be covered in fog of war and only the tiles closest to the player's starting area will be uncovered. As the player explores more of the map will be revealed. Only the closest tiles to the player and tiles within the players sight will be illuminated as the player moves around. Other uncovered tiles will be darkened but still visible, other actors on these Tiles will not be visible though.

This step will add a mini map to the game. This is the first GUI step. The tiles will be drawn a whole lot smaller in the mini map and tiles with special interactions will be highlighted. What the user sees on the main screen will be shown with a rectangle on the mini map.

This step will add a message box at the bottom of the screen. It will display important messages, what actors say and other valuable information to the player. This message box will also be used to interact with some tiles and actors. The player will not be able to type in the message box but mearly select options presented to the player.

This step will add dialogues to NPCs. The message box will be used to talk to actors. The player can select different options with responses in the message box to hold a conversation.

I think this kind of list of steps and implementations is just what I need to keep my mind clear and work on one specific task at a time. I've also decided to go down the route of C# and XNA. This is the language and framework I know best and with the ability to easily port it to Mono and MonoGame later on, possibilities of Mac and Linux ports are not far away.

As I am not really familiar with presenting ideas such as these to other people it's easy for me to presume you know what I'm talking about. I just discovered I didn't even tell you what platform the game would be for in the last entry so if there's any unclarities or questions you have I'd be glad to answer them as that also helps me develop the skill of presenting ideas to a totally new person that doesn't know anything about it.

That's all for now, I'll have a lot of other stuff to do the following week so I do not think a lot of time will be spent developing my game but the week after that I think I'll get to some programming!

You roadmap looks promising, good work. Here are my two cents to hopefully help you avoiding some misstakes I made:

I have a hard time putting all my ideas on paper so I've decided to instead of writing a long and complicated design document I'm going to develop the game as it comes and instead make lists of features I want to implement

OMG, you don't want to write a GDD ... I'm too not a big fan of large documents either, but you should be really careful about feature-creep. Your vision will explode along while development your game, the desire to add all this little, but not really expensive, features will mount up ;) Best to define the core features first, reduce it as much as possible, and write all your other features to a separate list for later.

You should start with the following first:

1. This step will add a message box at the bottom of the screen

2. The first step is creating the tile manager and the tile

3. This step will make it possible to save the map to an external file and load it

4. This step will implement the actor and the player class.

The message box is important for debugging, which helps a lot. The save/load game feature should not be done too late (I've made this misstake). The hard part is not to load/save your maps, but to save a running game state (longer running actions etc.) and recover this game state again and it helps a lot when debugging (try to track down a bug which will only occur sporadically after 10 min into the game and that without save game support). The holy grail of save games is, from a technical perspective, save games, which will be valid even after you continued developing your game. This will not be 100% possible, but it helps a lot to keep this in mind while developing it.

In its very basic form, a User Story is a concise, normal-English overview of a feature you want to implement, which includes the person involved who would normally use the feature, and the outcome you expect to achieve with the feature's implementation.

The format is simple: "As a <user-type>, I want to be able to <feature>, so that I am able to <purpose>".

For example, "as a Level Designer, I want to be able to view a minimap of my surroundings, so that I am able to quickly determine the surrounding area just outside line-of-sight of my current location in the game world".

There are many methods to approaching User Story design, but a next logical step in the Agile development methodology is breaking down a User Story into individual tasks, sort of a check-list of To Do's which go toward implementing that User Story and achieving that goal. A rule of thumb for defining tasks, no task can be too small.

In the past, disorganized individuals came across the same organizational problems you've encountered, and invented an entire project management methodology to help them achieve the goal of shipping a project on-time. You'd do well to read up a little bit of what Agile really is, and how it can help you get your thoughts organized on paper.

You roadmap looks promising, good work. Here are my two cents to hopefully help you avoiding some misstakes I made:

I have a hard time putting all my ideas on paper so I've decided to instead of writing a long and complicated design document I'm going to develop the game as it comes and instead make lists of features I want to implement

OMG, you don't want to write a GDD ... I'm too not a big fan of large documents either, but you should be really careful about feature-creep. Your vision will explode along while development your game, the desire to add all this little, but not really expensive, features will mount up ;) Best to define the core features first, reduce it as much as possible, and write all your other features to a separate list for later.

You should start with the following first:

1. This step will add a message box at the bottom of the screen

2. The first step is creating the tile manager and the tile

3. This step will make it possible to save the map to an external file and load it

4. This step will implement the actor and the player class.

The message box is important for debugging, which helps a lot. The save/load game feature should not be done too late (I've made this misstake). The hard part is not to load/save your maps, but to save a running game state (longer running actions etc.) and recover this game state again and it helps a lot when debugging (try to track down a bug which will only occur sporadically after 10 min into the game and that without save game support). The holy grail of save games is, from a technical perspective, save games, which will be valid even after you continued developing your game. This will not be 100% possible, but it helps a lot to keep this in mind while developing it.

As this is more of a hobby project I'm not to afraid of feature-creep stalling any release but I will try to limit myself to a core feature list, release the game and then build upon it adding other features in later updates.

What your are saying about the list is totally true, I will definitely take that into consideration and revise my list a bit.

In its very basic form, a User Story is a concise, normal-English overview of a feature you want to implement, which includes the person involved who would normally use the feature, and the outcome you expect to achieve with the feature's implementation.

The format is simple: "As a <user-type>, I want to be able to <feature>, so that I am able to <purpose>".

For example, "as a Level Designer, I want to be able to view a minimap of my surroundings, so that I am able to quickly determine the surrounding area just outside line-of-sight of my current location in the game world".

There are many methods to approaching User Story design, but a next logical step in the Agile development methodology is breaking down a User Story into individual tasks, sort of a check-list of To Do's which go toward implementing that User Story and achieving that goal. A rule of thumb for defining tasks, no task can be too small.

In the past, disorganized individuals came across the same organizational problems you've encountered, and invented an entire project management methodology to help them achieve the goal of shipping a project on-time. You'd do well to read up a little bit of what Agile really is, and how it can help you get your thoughts organized on paper.

Good luck, and happy coding!

That seems pretty much like what I am doing yeah, but in a different format. I might adopt the user design way of writing the features though. I will take a look at Agile, looks like it's something for me. Thanks