Effective Ascii Development

INTRODUCTION:

Looking at programming projects past and present it seems that one good advantage to ASCII and Text development is that you do not have to be binded by a bunch of rules, guidelines and standards when creating your programs. One must be careful however because this freedom can also make programs (applications or games) hard to use, hard to understand and therefore unusable to many people at least not without a huge user's manual that no one will ever want to read. Like most programmers, I'm sure you'd love your creations to be used and played a lot and the only way to achieve this is to create an intelligently designed program. All this within the concept of Text and ASCII development only. No graphics, no Windows gadgets, A blank window and the 255 characters available in the ASCII character set.

This is what we will be covering here. We will be looking at what exactly is an intelligently designed programming project as well as attempt to cover most of the bases of what you can do to make sure your programming endeavours are indeed the success they deserve to be. So if you'd like to create a project, detailed and complete, and would like to know how to help your chances that your project will become useful and hopefully a classic (if it's a game you're making) fasten your safety belt and let's begin this journey shall we?

WHAT I ASSUME:

This is not a story line tutor. We assume here that you already have your story line if you need one, that you defined your characters and their role in the game should you need them, we've also assumed that you defined special locations and places where users can do certain types of things and accomplish certain tasks. We are at the next phase in this document. The phase where you start taking everything you have and making them work into functional/logical groups of related or non-related groups. The phase when it's not time to start planning and organizing things in order to bring them closer to the development stage in a organized fashion to help you filter out the bad things and keep the good ones. With all these papers and notes, this document will take you into the next phase of the game development process, the analysis and conceptualization.

THINGS TO TAKE INTO CONSIDERATION:

When you design your application, you have to take certain things into consideration to "effectively" create a game or a program that users will want to use. To do that, there are a few questions you need to ask yourself and whenever you can, ask your typical user base as well since they are the ones that will be using your application or playing your game. These questions are:

  • What kind of program am I really making? Believe it or not, many people make a common mistake at this question. To give you a good example. Take the Pascal language. Borland created a pascal programming environment that was based on speed of use and high compilation process. On the other hand you have Brad Templeton's Personal Pascal who's main goal was to provide an environment that also taught Pascal and Assisted in the development of pascal projects. Both resulted in a compiled executable file, both offered a very different means of getting from a source module to a compiled application using the same Pascal programming language. For this reason, this question warrants time and reflection to make sure we know what we want to create.
  • What does the user expect to see? This is, of course, based on the type of program or game you are making. Since computers have been around for a while now, you can safely assume that people might want to see certain things based on the type of application or game you are making. For example, let's say you are making a text editor. Regardless of the user interface you want to give your application users will ultimate want to see some means of copying, cutting and pasting their text to rearrange them at will, they would also hope to find a menu option or a button that would allow then to open and save files. You just have to sit down and write down these things that people would expect to see in your program. That's a great way to start your programming project the right way. Also, don't be afraid to ask around. There's forums all over the place filled with potential users of your program asking them what they want to see is a good means of knowing what to include in your program and raising the user's interest in what you are creating.
  • How would the user expect things to work? This questions is sometimes easier to answer for a given type of programming project. Today it's safe to assume that text editing program should have mouse support and pull down menus. But if you are creating a game, the type of game can have a huge impact on the way that they options should be presented to the user. This is usually answered based on the context of the programming project and the general style you'll be giving your application or game. In some types of game a simple option to save the game directly available to the user is great. In other games you might want to user to make it far enough in the game so that they need to discover where the game saving option is. As in, put the game saving option in a given room or area of your game. Both these methods can work effectively but in some games, the last method (to let them find the place where they can save their games) can definitely add to the game play.
  • What kind of colors would be good to use? Ah yes, colors, what do they do? What's the best way to use them? This is always a big question because for a lot of reasons potential users of your application will include color schemes into their evaluation of your game or application. Is everything easy to read and understand or do some parts of your project seem to strain the eye? I would say this is a good way to start evaluating your color combinations. Asking directly is definitely another. Users will tell you what they like or don't like about the colors you chose for your program and this way you can quickly make corrections to your colors as needed (the earlier in the development process the better because you can make those changes quicker). Just remember one thing, consistency is the key to a successful color combinations. If your menu is white on a blue background it will be a great idea to keep all menus in a game white on a blue background.
  • Would the programming project benefit from some kind of standardization? In 80% of the cases, maybe more, this question would typically apply to applications more than it would to games because games are usually 100% creativity. The type of standardization I'm talking about here are more on the user interface part and well let's face it, today, with IBM's S.A.A. (Standard Application Architecture) with it's C.U.A. (Common User Access) standard that was created in 1985, most business or other types of applications would usually benefit a lot from such a standard if not for anything, for a very shortened learning curve. I don't remember the game, but I've seen a game that really took 100% advantage of the S.A.A. standard and that game was quite fun to play. So I have to mention that indeed, in some cases, games could benefit from a standard. Therefore you can definitely take the time to think about what such a standard would add, or take away, from your games as well as your applications.

In other words, if you take the time to sit down and think about things for a while, it's not that hard to plan a well planned program and it doesn't add all that much to the work you'd have to do whether you do standardize or not and which way you decided to offer your options and deal with the interactivity factor of your application or game.

PUTTING THINGS IN PERSPECTIVE:

With all this theory in mind, I think now is the perfect time to take a look at how these questions were answered in a particular game I've been playing to see why things were designed the way they were designed. We'll try to see what answers they could have come up with to create the games they did the way they did it. The reason why I'll use a game here instead of an application is simply because I like that game, I still play it today, and to me it's a great example of program design, and appropriate interface design for the type of game it is. The game is called Starfleet 2 - Krellan Commander and you can read my review on the game in our ASCII-World Contents section.

GAME DESCRIPTION:

As you might have guessed from the title of the game (yes the game title is as important as the rest of the design) This is a space battle and conquest game. You are at the command of your ship and you take on different types of missions to gain experience and up your ranks. This is what's known as a command based strategy game in that you select commands and things happen based on the commands you executed. The key words for this game are, strategic space simulation, all ASCII graphics, Command Based. This is basically what the game is about. With this kind of game you can expect certain things and not expect others at all. here is a few screenshots to give you a visual idea of what that game is all about. just click on them to get the larger view see the details. I strongly encourage you to take the time to look at these screenshots and try to see what is in them and how the screens are designed, the rest of this document is based on these screenshots.

sf2options.png

This is where you will typically set the general options of the game such as if there will be sound, color or monochrome, keyboard set and other such options. You select the options with the arrow keys and when you are satisfied, you press enter to save the options.

sf2signonoptions.png

As you can guess, this is where everything can happen. You can load a previously saved game, start a new mission, retouch the settings of the game and review your service record among other things.

sf2mainscreen.png

This is where you end up when the game officially begins. As you can see here there are many things on that screen but notice that they are very intelligently designed and layed out. This some feat of wits considering it's all text and ASCII graphics only and yet so clear to see what's going on where.

sf2navigationalmap.png

This image is the Navigational Map, the War Map is red and features Tactical information. It's in blue and serves the purpose of travel as you might have expected from the name of the screen. you navigate with the cursor keys to your destination and add it to your targeter. you can then turn on your engines (in the main screen) and get on your way to the selected destination.

sf2starsystemmap.png

The Star System Map layout is a view of a solar system in the middle of the grid on the left is the star represented by the Asterisk (*) you move a selector around to get information on surrounding planets and other spacial objects including star forts and ships.

sf2spaceforces.png

As it's name implies this screen serves the purpose of allowing the user to quickly localize where each ship of his fleet is and what they are currently doing (docked, invasion and other single word references to quickly give the needed information).

sf2propulsion.png

The main reason why I'm showing this screen is because it is a well drawn screen especially for an ASCII text screen. It lays out a basic schematic of the propulsion engines quite clearly and you can see where each component of the propulsion system is connected to the other components.

As you can see from all these screen shots, this is definitely a complete game that offers many options as well as many types of missions and all the tools you need to accomplish them as well. These screenshots represent a sample of what's available in this game, there's more screen all equally as functional and as well designed as these. I also showed this many screen shots to emphasize the work that must have went into the creation of this game. These are the screens themselves, the story lines and mission details (just as important as the screens and the game themselves) are quite good too and definitely capture your interest from start to end especially if you're a trekkie of any level.

BREAKING IT DOWN:

As mentioned in the description above, there's a whole lot of screens and many different operational modes in this game. so I'm not going to detail every single one of them. The way we will be breaking down the game will be quite different. We'll be looking at the game, what it was meant to offer, what it does offer and detail all this as per the questions we could be asking ourselves. We'll be basically designing the game as if it wasn't made yet and see why certain screes look the way the do based on the functionality we'd like to see in a given part of the game.

THE GAMING CONCEPT:

This is usually the first step to creating a game in my opinion, if you don't have a concept, there is no game or application. In Starfleet 2 the concept could best be described as a futurist space strategic simulation game. What's the first thing that hit your mind when you read that? Futuristic Space Simulation right? Now, without looking at the game itself, what does that reflect to you? How would you explain what a futuristic space simulation entails? I would define it as a game that happens in the future (typically, this represents advanced technology) it happens in space (chances are there's ships involved) and it's a simulation (chances are there's a certain degree of realism and factual information involved to make it a convincing simulation). With this in mind, let's see what kind of answer we can give our now famous 5 questions of the beginning. Remember that the answers given here are strictly in the context that we are create a Futuristic Strategic Space Simulation game. The answers would most definitaly vary for other types of games and other types of applications.

  • What kind of program am I really making? Remember the discrepancies between Borland Turbo Pascal and Personal Pascal I mentioned above? The same could apply here as well. For example, we could decide that the main purpose of the game is to destroy a swarm enemy's fleet and ultimately his planet to really rid yourself of him and his kind. You could decide that this game would only offer exploration and scientific missions. In the case of Starfleet 2 - Krellan Commander you are not the good guy, but the enemy (the Krellans) and your objective is to invade planets that have an atmosphere you can breath. In the process, if you encounter the good guys, you can and should destroy them especially if they are planning to intercept and stop you. As your exploring and invading you will encounter allies and enemies as well as all kinds of space related items like stars, planets, black holes and others. All this will need to fit in the gaming concept.
  • What does the user expect to see? Let's see now, being a space game, space things are more than likely what the user will see. They might also expect to find unknown planets that could be inhabited or not. They would typically probably like it if they could get a sense of familiarity as in knowing if they've been somewhere or not. I believe they are the bad guys, they might expect to torture the enemy being they are probably more cruel then us evolved humans. They'll want to take over worlds just because they have the power and the technology to do so and their home world is vastly over populated. There's more to it. But in essence, this is a good description of what could be seen from the user's perspective. It certain seems to have been the intension of the author of the Starfleet 2 game as well.
  • How would the user expect things to work? Here the first thing you'd probably need to remember is that this is a "Futuristic" strategic space simulation. As such, the first thing they would probably expect is a futuristic user interface, an new way of doing things they've never seen before because it hasn't been invented yet. So when you give the user his options, you'll need to keep that in mind. If you took a look at the screenshots above you can see that although all in ASCII the interface presents some pretty innovative ideas and functionalities. This is one of the main reason I selected this game, it really lives up to it's gaming concept. All the screens, and all the required user input is all based on the fact that this game happens in the future but it is dealing with today's human player. This is a perfect combination to give you the impression that you are in the future but almost instinctively know what to do next.
  • What kind of colors would be good to use? Again keeping in mind the gaming concept, it seems that for this game, the trends won for the color combinations used in Starfleet 2. For example, looking at the majority of futuristic movies the likes of Alien, the Startrek Movies, Star Wars, and other space related movies, everything you'd see on a computer screen seems to be shown on a black background color with red text for red alert situations, blue for standard operations and the likes. Starfleet 2 is no exceptions, everything is on a black background however a bit of intelligence was used where the current item being used is in highlighted colors and the rest of the interfaces are in darkened colors. This is a visually easy way to tell the user where he is on the screen and therefore help him know where to go next. This combined with some great ASCII futuristic ASCII computer consoles gives the game a very futuristic look and feel that the user would definitely expect from a Futurist Strategic Space Simulation game.
  • Would the programming project benefit from some kind of standardization? As I mentioned there are indeed standards, and many programs, even games, can benefit from those because these standards have been created for a distinct purpose. However, for the reasons I explained above (with the game being futuristic and therefore almost needing to present a never before seen operational system) Starfleet 2 would not benefit at all from any such standards. In fact, given a game of this type a standard user interface would probably kill the game because users could not associate a futuristic game with a "contemporary" user interface. It's just human nature to expect these kinds of things when engaging in a futuristic game. So for those of you wanting to really revolutionize the futuristic game industry. This is the perfect kind of game to really let yourself loose and go wild on how you create your user interface. Be as creative as you want, be sure to ask for feedback too, that's always important because the players are the ones that will be using your game, not you. No matter how creative you get, remember to be consistent however. Create a radically new concept but keep it the same concept throughout or you will loose your users, at least some of them.

FROM CONCEPT TO CONCEPTUALIZATION:

At this point we have a good idea on what the game should be. Maybe by now you've created some mental images of what you'd see in the game and you're thinking maybe that you can sit down and start coding. This is where I have to stop you a bit and talk to you about conceptualization. What is this word? Well conceptualization is the art of putting into paper what you are seeing in your mind basically. Good artists have this ability to paint on canvas the exact picture they have in their mind. When creating a game, you need this phase especially if you know you'll have many screens involved in the game play. Starfleet 2 has a huge variety of screen layouts that have been designed to give a realistic feel to the game as well as superior control over the realization of the missions at hand. Conceptualization is more than just drawing screens and taking a few notes. Chances are each screen you design will probably impact or interact with other parts of the programs including other screens. The relationship between the screens is just as important as the screens themselves. When you think about it, taking the time to know the relationships between the individual screens will cut down the coding time involved because if you forget a relationship, chances are you'll have a lot of alterations to make to create the missing relationship, not to mention the impact it will have in other screens and gaming engines.

So then, as I mentioned at this point you have mental images in your head and well it's time to conceptualize these screens and their relationships. Where do we start? This is what this document is for. In the case of Starfleet 2 and many games regardless of whether they are Text or Graphical games, you can probably think about a certain set of screens that they all should have. By that I mean that all games could typically have a basic list of screens. Those are:

  • A Title Screen: Indeed this is usually the first screen to appear when the executable file is started. It presents typical information about the program such as a game logo (if any), the name of the game, the version, copyright information and the likes.
  • A Main Menu Screen: This is, as the name implies the central place where other options, including playing the game itself are usually offered. Presentation here is just as important as presentation in the rest of the game. Styles and standards should be respected here as well as being consistent with the rest of the game.
  • A Main Game Screen: Just like it says, this is the main screen. This screen usually offers a general view of what's happening at the moment in the game and gives access to the other screens of the applications.
  • Alternate Gaming Screen: These are other screens, accessible from the main screen that can present new types of information or require user input before the screens can be exited. Each screen here are usually organized by tasks, it's a widely spread technique that has been popular for a good long while. In starfleet, an example could be the navigation screen which severs no purpose other than to travel from point A to point B. There are others too.
  • User Interaction Screens: These are like the Alternate Game Screens as they are usually accessible from the main menu or the main game screen. These screens are screen that "require" input from the user, in one form or another, to perform a given task.
  • A Multiple Endings Screen: I say multiple here because typically there is at least two endings to any game. There is the ending where the player successfully completes the game and the screen where the player dies from unforeseen circumstances.
  • A Credits Screen: Scrolling or not, this screen is probably the most important of all screens in a game. Don't forget the hard work you, or your team put into the creation of your game, and don't be shy to brag about it either. it will get you known and people looking at new games you release will remember how your past games were.

Of course, in the case of Starfleet 2 there's plenty more screens than these, and they are all there for specific reasons. One is to of course allow interaction with the user and giving the necessary feedback on their actions, the other is to help in the hole look and feel of the game itself. Some might argue that some screens could have been combined into one, maybe they are right but think of the complexity of some these screen if they were combined into one. This is all part of the conceptualization phase too. You need to stop for a second and define where to stop, when you can consider it enough contents on a given screen. And, of course, you need to ask yourself if it's better, for the player (not you) to split a given screen into more than one. Again I say here, ask around, post questions on forums, create polls on your website but do what you have to to get the feedback you need to make your game a good one.

THE ACTUAL DESIGN OF THE SCREEN:

At this point you have enough info, I believe, to start the official conceptualization of your many screens and user interfaces. Personally I like to take some quadrilateral paper and start designing from there, I can draw lines and give me some good pointers for when I'll actually code the given screen. The important thing before you start is to make sure you have all the screens and user interfaces you'll need ESPECIALLY if this game is going to be a group effort. Distribute the screens amongst the different people that will be designing them and ultimately programming them. Once that list is complete and everyone have their respective set of screens to design, the method used for the actual design is really up to you (unless it's a commercial game and the company wants a certain set of design methods followed. Otherwise, you can draw them on paper like I do, or start creating code that will draw the screen. There are screen designing tools as well that offer you a blank screen on which you draw lines and characters to form and shape your screen design into place. In other words, there's more than one way to do it and there is definitely advantages to all the existing screen designing methods.

One thing I always carry (well not so much now since I just about memorized it) is an ASCII character code chart. You never know when memory will fail you and having one of those handy gives you a quick reference of what you can use while designing your screens. Depending on your programming language and environment, some offer an ASCII chart as a popup tool that you can glance at, others also offer it in the help sections. Another thing I usually do while I design the screens (on paper or in code) is list the different elements of the screen. Taking Starfleet 2 for example, the main screen display offers more than one component like the Long Range Sensor, the Navigation Information, the Tactical Display, Damage Report and others. Typically each of these elements will represent a different part of the game play so I find it important to list those if not for anything else, just to give me a basic list of things to do when I start the coding process.

You do need to put all the efforts you need in your screen designs. If there's some part of a screen is not clear to you, the creator of the game, chances are they won't be any clearer to your players and probably require some more designing. Likewise if there's a screen you don't like, your players probably won't like it either so you should take the time to create the perfect screen for you based on the feedback you received from your forum posts and your polls. If you give this design phase enough time, you will create intelligent screens that you and your players can love to use. Even if just in ASCII character codes, you can definitely give your screens the mood they need to become convincing to the player's eye. Take another look at the screenshots above and you'll see that each of these (and the others I have not shown here) are very well designed and offer realistic feedback to the player in a very efficient means. You can do the same.

PUTTING IT ALL TOGETHER:

At this point you have your relationships between your screen layouts, you have the screen layouts themselves. What's missing to make a game? Well if I told you that you could start coding at least you'd be a bit better prepared for it by now. But, and there is a but, there IS more to consider at this stage. With the screens described above, you will have created the interactivity between the game and the user. What happens with the interactivity between an enemy ship and a planet, or a ship and a warm hole, or a planet and it's moon? These interactions all have to occur for the game to reflect any type of intelligence and realistic consequences to events caused by other parts of the game as well as effects caused by the player.

This phase is the phase responsible for connecting the pieces of the puzzle together by providing the missing links between each pieces such as when pressing a specific key or key combination will make a certain screen appear. How things work within each screen (such as navigation between the different fields or elements on a screen, determining the order in which information is acquired, data validation to make sure the data entered is as expected and other such functionalities. This phase also determines the intelligence level of your opponents, the types of interactions you may encounter when you come across this or that type of enemy, analysis to determine if your ship or your fleet is strong enough to take on this kind of opponent and vice versa. Calculations to determine when and where an enemy ship or an allied force will rendezvous with you. All these details that add realism and depth to the game.

Let's not forget the reward factor. Players love to be rewarded when they did something right. There's many ways you can reward players of course. You can up their score a couple notches when the cross a big step in the game, you can install a Ranking system like in Starfleet 2 where you start as a the bottom and graduate towards captain with your many victories. Basically you could also just throw in some encouraging words too saying to the player that he's definitely on the right track. All this depends on the game concept and the context of what's currently happening when the time comes to reward your player.

THE FINAL WORD:

If I've been clear, at this point you should have everything you need, organized and ready to go, to sit down in front of your selected programming environment and start programming. Remember that this document does assume you already listed your enemies, your locations, and all the other basic parts of your game components and took it from there. If you don't have that done, well I would recommend you take the time to do so, like what this document is trying to do, you won't regret already knowing who's doing what where before you start coding. Each little part of a game from a character to a location to a trap even can influence the design process greatly all depending on what they are supposed to be doing so, if you don't have everything listed with a good idea of what's happening where, you might find yourself redesigning more than you originally planned. Taking the time to do these things in advance just makes the rest of the game creation cycle flow smoothly. It can even give you a better sense of control over the development cycle as you now have a very close to complete list of things to do so you can take things one step at a time.

When creating a screen or an entity I like to do everything that I can do for the screen or entity. For example, if I am designing an Alternate Game Screen I already know it will have to be connected some way to the Main Gaming Screen and I'll tend to do that connection already. Likewise, if I create an entity for a ship and I know that ship will have a certain amount of power and a given weapon on my main ship will lower that power by 50 each time It gets hit, I'll tend to code that right away too. In the limits of possibilities I basically like to take one thing, create it, validate it, finish it and move to the next thing on my list. It saves notes here and there telling me (don't forget to add this or that later), well, saves alot of these notes, in programming there's always room for at least some notes like these.

As always, I try to be as clear as I can. However, not everyone will agree on that, so if there's a certain part that's not clear to you, feel free to send me an email (see my signature below) and tell me about it so we can make sure it all gets cleared up and you can grasp the concepts. Of course it's not always obvious to try to do all this before you start to code, but for any game or application that you'd consider a "bigger project", you'll see that it is definitely worth the effort in the end especially in a group effort.

Stephane Richards

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-Share Alike 2.5 License.