How-to: Roguelike Gamedev with C++ Using BearLibTerminal Part 1: Printing '@' and moving around the screen
The '@' symbol
Its traditional in Roguelike games for the player charachter to be represented by the '@' symbol. To get a feel for BearLibTerminal, were going to build a simple Game Loop and use it to respond to keyboard input inorder to move an '@' symbol around the screen. we got a small taste of printing the screen and reading keyboard input in the 'Setting up' Section. This Time around were going to do something a bit more exciting.
Cartesian Points
To get an idea of how our terminal window is layed out for formatting, we can think of our terminal as a Cartesian Grid of X/Y Points, where 0,0 represents the upper most left corner of the window everytime we add 1 to x, we move the cursor to the right one space, likewise when we add 1 to Y, we move the cursor in the window "down" one space. I put down in quotes, because from our view, down is actually up and up is down; but dont dwell on that or let it confuse you. you'll get the hang of things pretty quick. using the terminal_set() command we defined our window as being 80 spaces wide and 40 spaces high. its worth while to save these values in two variables:
Creating Characters (PC and NPC's)
C++ being an object oriented language, the players character as well as NPCs are represented by objects. Our first step is to create this object in the form of a class. In this class we will define the attributes which describe each character as well as the methods that control each character. A good starting point is to provide the x/y coordinate of our character as well as the symbol for representing him on the map/screen, and a method for moving and rendering him(or her...).
A World To Walk on
We're going to really implement a map and dungeon generator in part 2 of the tutorial, But for now we're going to outline a very basic tile and map class so that the character we create has something to walk on.
The Game Engine and Main Loop
Now that we have our character and a world for our character to walk on, we need a way to control not only or character, but a place from which to dictate the entire flow of game logic. Player input, scene rendering, AI, and much more will all be controlled from the "Game Engine". Rogue Like games are inherently event driven programs, and the place where all these events are monitored and dispatch is from the main game loop. Our Engine class is an extremely important part of our game, so we want to implement it early, and in a way that will make all of our objects easy to interact with eachother.
Our Engine Class is where we will define our play object and our map object, as well as take input from the player to control character movement/actions in the engines main loop. It is also from where we will call each objects render function from within the main engine's render function so that objects are rendered in the correct order.
Tying It Together
With a working Map, Actor, and Engine class It's time to see what we've got so far. To do this we're going to write our games entry point: int main(). Similar to how we did in the test during part zero, we first initialize our terminal window, but this time we're going to instantiate our engine class and call the main loop to start our game:
Compile with 'g++ --std=c++17 RL-Main.cpp -o RLMain -llibBearLibTerminal.dylib' and then run it with './RLMain'
upon entering the above commands, you will be greeted with this:
Pressing the allow keys your keyboard will allow you to move the '@' character around your the box. Press Esc to close the window.
Were off to a good start now, we've created our character objects, are taking input from the keyboard, have the foundations for creating a map to walk around on, and an engine to tie everything together! Stick around for Part 2 where we will dive in to one of the hallmarks of RogueLike games: Procedural Generation of Dungeons!
-
Generating P-Code by AST Traversal
-
Ternary Search Tries: String Specific Ordered Symbol Tables
-
Digital Search Trees
-
Lossless Compression Part III: Huffman Coding
-
Lossless Compression Part II: The LZ77 Algorithm
-
Lossless Compression Part I: Working with Bits in a Byte Oriented World
-
Bottom Up AVL Tree: The OG Self-Balancing Binary Search Tree
-
A Different Take on Merge Sort: Binary Search Trees?
-
Deleting Entries From Open-Address Hash tables
-
Transform any Binary Search Tree in to a Sorted Linked List
Leave A Comment