Creating a Scalable Console System with STL – Part 1by Facundo Matias Carreiro

Introduction

Assumptions

To successfully read this article I suppose that you have a good knowledge of the C++ programming language, virtual and pure virtual inheritance, and the STL library. Knowing a bit about function pointers, unions and structs would also be great in order to fully understand the article. The code will be written in the C++ language with an Object-Oriented Architecture. I will not explain the different parts of the STL library but I will provide links to reference pages of the ones I will use (i.e. std::vector, std::list, std::string) so don't panic if you've never heard of them. Please read all the reference links that are between parenthesis if you don't fully understand a specific topic and always feel free to send me an e-mail to fcarreiro@fibertel.com.ar if you have any doubt or wish to communicate something. Thank you.

Who is this article for?

This article will explain how to create an abstract console interface that can be used in lots of contexts such as a "Quake Style" console or just a simple text-based console.

What we WILL do:

We will focus on the inner operations and design of the console system so it will fit for many future purposes.

We will create a console where you can input and output variables and execute commands.

We will provide examples of where and how to use the system.

What we will NOT do:

We will NOT explain how to render a fancy-looking console.

We will NOT create a game with a console

So, if you are looking for an article on how to create a complex and extensible console system then this is for you; if you want to know how to make it look good then wait for the second part of the article ;)

If you are still here then come on and follow to the next section where we will discuss the different parts that we need for the console system to work perfectly...

Parts of the console

Parts of the console

We will divide the console into four main parts: the input, the parsing-related functions, the text-buffers, and the rendering output. This diagram also follows the data flow circuit. Each part will have associated variables and classes to interact with the rest of the system, have a little patience and you'll see them in action…

INPUT

Key Input: The keys the user presses have to be passed to the console system so it can process them and add the characters to the command line buffer.

PARSING-RELATED

Item List: This is the list of available commands and their associated functions, we also include here the list of variables and its type.

Command Parser: After entering a command line we need something to analyze it and do what has to be done. This is the job of the Command Parser.

TEXT-BUFFERS

Command Line Buffer: It is the actual command line being written by the user, after hitting "enter" it passes to the command line parser and most probably triggers a command.

Output History Buffer: The text that the console outputs after executing a command or parsing a line is stored in an History Buffer of n lines.

Command History Buffer: When you press enter to execute a command it is stored in the Command History Buffer so if you want you can see or re-execute previous commands easily.

OUTPUT

Rending Output: There has to be some way to render the console data to the screen, should it be text or graphics.

Data Flow Chart

The data goes IN the class by using a function that receives the keys then, if needed, it calls the command parser who executes the command, changes the variable and saves the output in the buffers. The rendering function can be overloaded by the derived class and it has access to the text buffers so it can present the data in the screen. In the next section we will explain how to design the class in order to follow this design.