Jump to content
  • Advertisement

The Beginnings of a Plan - Test Adventure Dev 01




It is time to really get my teeth into my new project. I'll be using posts on this blog called "dev diaries" (original huh?) for this project as a way to take notes and organise my thoughts. Also with luck I may get some practical input form more experienced people. I started on the general outline yesterday, so this morning I want to take a few moments to collect my thoughts on the project and consider what to do next.

Project: Test Adventure

The goal of this project is to learn C# in a practical environment by creating a text adventure game. If the timing allows I would also like to look at adding some features to make the project valid for the "Dungeon Crawler Challenge" @GameDev.net. This will require the additional inclusion of Sound and Combat which are not in my original plans for the project.

Game Design Goals :

  • The game will run in the Console
  • The game will be programmed in C#
  • The game will have a pseudo-Natural Language Processor. This is the main goal of the project and its main focus.
  • The project will contain: Rooms, Items and a Inventory.
  • It will use TxT Data Files to read content into the game so I can edit the game data in a easier way rather than directly in the code blocks.
    • This will require the development of a txt file phraser and some kind of formatting for it to read.
  • I would like to have a SAVE and LOAD system.

Lower Priority Design Goals :

  • A Map System for the player - as an expansion to the inventory system.
  • Sound, Music

Lowest Priority Design Goals :

  • Adding features to bring project inline with the minimum requirements of the GameDev.net "Dungeon Crawler Challenge".
    • Monsters / Combat / Loot

Dev 01: Test Adventure

The biggest issue I am having at the moment is trying to work out how to structure the application. As I have literally only ever made a single application (see my Tick Tack Toe Game a few weeks ago) the organisation of the classes and how the object interact seem to me to be the most complex part of this project so far. Actually fooling around in the logic to make the code do stuff is not that difficult (or so it seems at this stage) but working out an efficient and easy to implement / edit structure for the game is rather hard. I originally planned to get it all out on paper making flow diagrams and stuff.. but a very experienced programmer mate of mine said that I really should just get in there and get my hands dirty. In his experience redesign is a big part of development. The more you work on a project, in a practical way the better you understand its needs for the design. His attitude is that you simply can not predict everything.. so why try. All it dose is slow you down in very boring clerical work. This made a lot of sense to me.

Skeleton Classes (completed and functional)

  • Program - This is the main game loop. I want this to be nearly empty.. with just a initialisation start screen and then a game loop that runs until exit and then the exit messages.
  • Engine - This is a system I made up for the Tick Tack Toe Game, I liked out it worked so want to continue it. The Engine will handle all application function calls to other parts of the program including initialisation. The "Program" class itself should only consist of Engine Calls.
  • GameState - Again I used this in my Tick Tack Toe Game this class will simply track gamestates like end game and stuff and feed that to the Engine.
  • ConsoleBuffer - In Tick Tack Toe Game I had all the console printouts compiled into string lists of lines before being printed. This worked well I thought and I'll try and do it this way again.
  • PrintConsoleBuffer - This will contain some code to print out the buffer to the screen itself in various ways.
  • DataFiles - This will handles the reading of data files, and the save and load stuff for the game.
  • TextUltils - This is part of the main point for this project. It will handle all the string manipulation. Including the tokenisation for the pheudo-NLP code, input clean up and console word wraps.
  • CommandProcessor - This is part of the main point for this project. This will take the processed strings from TextUtils and use them to do things.

What Next?

So all the above classes are completed skeletons. This means I can now test the project as I add code to it. They are far from complete and some code is temporary to get the app up and running for testing. What I need to look at now is the items, rooms, level and player classes, with a mind for how I plan to do the various word lists. More on that in a future post. For now I need to get the skeleton completed to a point where I can test commands. Once I can start testing the command processor properly the entire project should start to take form.

  • Items will contain as a base :
    • Description, Inspect (inventory description), Get Text, and a Name
  • The Rooms will be one of the main classed in the game. They will contain as a base :
    • Descriptions, Items, Exits, Player Advancement Blocks, and a Name
  • The Level will simply be [ ][ ] array that contains Rooms. All the location code like getting player position and stuff will be stored in here as well.
  • The Player Class will be very barren at this stage. All I really need for the next phase is to be able to place the player in a given location inside the level.
    • Inventory Items, Location in level (posX, posY)

Once I have these done I should be able to place the player in a test room, with some objects. Then I can work on the meat of the project the CommandProcessor and all its parts. Which I will detail when I get to that phase.


Anyway.. thanks for reading!



Project: Test Adventure


Recommended Comments

Hi.  Good luck with your blog.  But from my point of view you've already started incorrectly.  You started designing classes first.  Always start with designing your data structures first.  OOP teaches very bad approaches to software design.  For more information, check out this link: https://www.gamedev.net/articles/programming/general-and-gameplay-programming/the-faster-you-unlearn-oop-the-better-for-you-and-your-software-r5026

I did not write that article but I agree with it wholeheartedly.  I have 20+ years experience writing video games and have written many text adventure games too during the 80s, so I like to think I know what I'm talking about.

Share this comment

Link to comment
3 hours ago, rogue6 said:

But from my point of view you've already started incorrectly.  You started designing classes first.  Always start with designing your data structures first.

I do not know how to use structs and stuff. I have only been programming for 2 weeks or something before I started and had only done about 2/3rds of a book called "The C# Players Guide". So, I have not used Interfaces, Structs and Inheritance at all in this project yet. Once I finish this project I want to find a new book to work though.

Share this comment

Link to comment

Good luck in your journey, A4L, don't worry too much about getting high performance data structures or anything just yet; just worry about picking up general programming skills and writing games is a great way to get started with that.

Share this comment

Link to comment

So you're using C#.  Well then you kind of stuck with OOP paradigms.  Fair enough.  I hope you learn a lot from this!

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!