Welcome to Yet Another ASCII Game (YAAG).

Why did I name this journal YAAG? Well the initial name comes from a programming term that is used when you develop your own programming language Yet Another Compiler Compiler (YACC). But this journal is not about writing a programming language it is about my journey in creating a game I loved to play as a child on the old BBS systems. You may hear from time to time that I call this game The Arena which was a name I called my own version of this game in the late 80's. Its now been 20+ years since I had worked on a project like this so my old code is gone and I have started from scratch building the game and engine together.

Why did I build an engine on top of the game? The short answer is I love writing engines and learning how to write optimized code. That and I read an amazing book on Game Patterns that inspired me to try and make a game and after a bit I decided on this ASCII game. That and I wanted to focus more on Game Design then graphics. All the graphic game projects I have worked on typically get bogged down with tedium work while game play gets skipped.

Will you be porting this to other systems? This is a good question. Maybe someday I will work on the port process but for now this will only run on a current Windows computer. On the surface the engine is just C++ code and should be able to be built with just about any system as long as the graphics engine is created during the port process.

The Arena Game

This is where I was after a couple of days. It was playable and in this image is a test of adding multiple monsters into the engine. To get here the engine needed to have some basic functionality like the ability to create and add different type of entities to the core engine for simulation. To start this process in needed a way for the entity system to be flexible enough to handle just about anything my feeble mind could create. So this is the basic UML diagram for the entity frame work.



Sorry if I got the diamond facing the wrong way its been a while since I've written a UML diagram. But the idea here is that the IEntity has a mover object which controls the entities ability to move around the game world. The mover has a controller class that either brings keyboard input into the game engine or we could use just about any other device like a Joystick, XBox Controller, etc.. In this flow you can see I even connected my AI engine to the controller. This allowed me to reduce having to build a ton of different movers because most of my movement is for all the game entity shared all the same needs. Abstracting it this was exciting to see if I plugged a keyboard controller into a monster then I could control the monster. Also being able to plug in the AI in this matter allows be to create so many different AI system without really getting to complex.

The next couple of things for me still to work on in this paradigm is to add a network controller so that a server and client system can be developed and the engine can do network play. This is my goal but I haven't gotten to this point yet of the game, still working on the game play.

So now that the basic entity system is built is was time for a massive amount of game design. With a lot of work the engine and game started to take shape but I quickly found that this low ASCII resolution was not going to give me the game board and interface I really wanted to use. So doing some research into the Windows Console I found there are a couple of ways to increase the size so that now I can add in a lot more interface design and not be so cramped on a 24 line command prompt window.



In this there is a fully functioinal exit. No longer can you just hit eascape to flee the monster but you have to make it to the exit before the monstger has a chance to end your life. The current monster database consists of about 25 different monster you can encounter, 51 different weapons, and 27 basic armor. Originally all the data was hard coded in C++ code which was easy to maintain while I didn't have so many different items. Now I have moved all this from code to Excel and use a CSV parser to compile the data into a simple DAT file the game can quickly consume an directly instantiate object from the data.

Death to the Singleton!

So the patterns book I read really opened my eyes to this pattern which up until this was the bread and butter of my global classes. But in this iteration of my game engine I really made the effort to not have a singleton class anywhere. For instance if you remember the UML diagram from before it showed an interface called ILogger. In the past I have typically created this as a singleton pattern because I just wanted to be able to grab an instance and start logging. When you don't have a lot to log this was fine. But even in this small engine I found there were so many times my log file would grow to a few thousand lines and finding what I wanted was way to diffuclt. So throwing that idea out was the best thing I learned in my pattern book.

Now when the debug version of the engine starts up I have several logging system to track the core engine, entities, AI, and a few other systems that are to small for me to remember. Then there is the new NullLogger class. The odd thing was I had actually started to use this class in other projects before I learned about it. But if you get tired of always checking to see if an object has been instantiated then why not just make a Null version of that interface that really does nothing and can be safely plugged into any system that would need it. This is typically called the Null Object Pattern and for me has been really useful. Most of the time now when I careate an interface the next step for me is to create a null version of this interface.

Well for now this will have to do for me getting started. I'll keep working on this design journal and my journey to making one of the games I had a blast playing as a kid. Also it was a lot of fun to break out my old UML skills so hopefully this will become a norm when talking about design ideas.