Hello again!!
In this post, I figured that I'd share the details of the system that PITVYPR is going to be built on/with - in case anybody was thinking of trying their hand at making a Roguelike of their own.
Some people (okay, most people) wont find these topics too interesting on the surface. However, I'd like to propose that people who are interested in going on a similar "solo game development" journey at least have a skim of this post. I think that learning what kinds of decisions go into the scaffolding and foundations of a game goes a long way towards starting off well. Of course, the spirit of making Roguelikes is to simply start. I agree with this, but also think that starting on a better footing is possible, and can save us some headaches down the road. It's important to not get too bogged down in these kinds of decisions, and you'll see immediately that some of the justifications for my choices are pretty shallow.
The language of choice is C# - my favourite language, and always my go-to for any programming projects (see? not complex at all). I played with the idea of making a website and hosting the game on there, but figured I should stick with what I know. Making the game playable in browsers doesn't really do much for the experience, considering that "runs" would, ideally, take a few hours to complete. Learning how to handle cookies for save files plus the actual cost of hosting it... its all too messy. It's also worth noting here that I had decided against the use of a Game Engine program like Unity or Gamemaker. While I do love Gamemaker (it's my favourite piece of software, I've made so many prototypes in it and all of my Game Jam games are made in it), I just didn't see it as appropriate for a text-based RL, and Unity is an engine I don't have enough experience in to be worth the time investment for making this game.
It's good at this point to qualify exactly what I'd like to have as basic features in the game. We already looked at one of these in the above paragraph: the decision to have save files, and the choice that helped me make regarding online hosting.
The required features are as follows:
Pretty simple requirements, right? In order to make a functioning Traditional Roguelike, this is really all you need. You could also do away with these features and still make a roguelike: with graphics that aren't ASCII, and no input from the keyboard. These are just requirements for my project.
Noting the required features of your project can be great for prototyping initial concepts with simpler projects that are using less libraries and moving parts than your full development project will be. For example, we can meet these two requirements with just a command-line program. If I want, I can prototype a lot of my features using just basic console projects, and porting those classes over to my game project once they are ready. There are some features that I would like to have, though, that aren't required for making a Roguelike:
Preferred Features:
As mentioned above, much of what I'd like to achieve can be done with a simple C# Console Project, which writes text into a command-line terminal. You can, surprisingly, adjust a lot of things in these terminals, and can even change their writing style to be lightning fast (though it requires some custom functions). I am also very familiar with making games in C# Consoles: I've made Chess and a handful of other small board-style games in the terminal. Yet, the use of a mouse is the one thing that the Terminal really doesn't, from my somewhat limited understanding, have any way of handling. And so the easy option, the terminal, is going to get tossed out.
One of the most popular Roguelikes, Brogue, is shown above. This game runs entirely in a console, and doesn't (to my knowledge) require much special architecture to be run.
Looking for an alternative approach was not that difficult: I just Googled "Console Simulators for Roguelikes C#" and found a Reddit post with a few suggestions. I decided to go with SadConsole for a few reasons: It had a wide set of features, high customizability, a helpful beginner's tutorial on the website, and an active Discord server. I learned from using an open-source library in my University project that active Discord communities are the saving grace of someone new to the library. Reading through API documentation is all well and good - but sometimes the best way to get an answer is to just ask instead of spending time trying to look for it yourself. This is a trap I get caught up in a lot and have been learning to overcome. As long as the game is getting finished and I am getting what I want out of the project, then I don't need to worry so much about how I am getting there.
So, we have a basic set of requirements, and have decided on the tech that is going to be used to get there. For the most part, there shouldn't be any huge uphauling of the things that are currently decided on, because they are fairly fundamental to the whole thing. If I can't make them work, then the whole thing won't work. As of the time of writing, I am a few blog posts ahead of this point in development, and so I will save you the suspense: SadConsole works perfectly for the development of PITVYPR.
If I was going to summarize what I'm trying to get at in this post in a sentence it would be:
“Consider your requirements, shallowly.”
At the end of the day, people have made DOOM run on literally everything with the possibility to transfer electrical current. So, with all the myriad modern options available to you, it wont be too difficult to find a language, a set of libraries, or even just an engine that will enable you to do the things you want to do. Remember: it just has to work first. This is something I still struggle with a lot, too. During the short making of this project I've been getting bogged down with trying to find the absolute best implementations for features, which is just not something I need to focus on much right now.
The next post is going to be skipping over the basic setting up of a SadConsole project and all that: they already do a pretty good job of writing about that themselves. I'm not really trying to write about EVERYTHING that goes into this project, and will be trying to write about the most interesting and worthwhile parts. We are going to be talking about the bright-eyed, naïve developer's favourite: The Roadmap.
All the best,
Liam (BerneyTD)