Remember last post when I said “I’m back mostly because looking back at your progress for the past weeks is just a very good thing to do?! And now I am just going back to the roots™ of this devlog – I will do whatever I feel like and then I will come here and write about what I’ve done, problems I’ve faced, what I’ve learned and, of course, add some Michael Scott gifs.”? – and then I proceeded to not writing anything for 153 days?

I have very important news: remember I was doing a 2D game engine called realiti2D? Yeah, good times, I decided to stop doing realiti2D and start doing another engine, which I decided to call visions2D.

But for what reason someone might decide to stop doing something just to start doing it all over again? You might ask.

Well, there were some things I didn’t really like about realiti2D.

First, I didn’t really like the entrypoint. You have to create a class that extended the “Application” class, and then implement a function pre-defined in the engine, and that would be where your Application would start.

It just feels a bit confusing and unnecessary for me, I changed to a “you do the main function” approach. visions2D will have auxiliary classes to create games and tools, but at the end of the day, you can do whatever you want if you know well the engine architecture.

With that, within visions2D I can create a standalone renderer so I can test things and create tools.

And that was the second big reason, as I learned more about rendering, I noticed that realiti2D’s renderer was pretty bad, and I felt like restarting it would be the better thing to do. But I promised myself that’s the last time I restart an engine, if I face any major issues, which I’m sure I will, I will refactor!

With visions2D I want to not only create a good environment to make games, but to also make tools, and for that I need a well written renderer that can work as a standalone. I also need really good UI code, but that is a future me problem.

visions2D

How does the current process on visions2D look like? You may ask.

And recently I have made a simple flappy bird clone on it!

I will do a short youtube video on it so stay tuned.

Random Prototype of the Month

I like working on some occasional prototypes, so recently I picked a course on how to make a simple match-3 game, and you can see the result of it above! There’s not much to it really, it’s a match-3, everyone knows how a match-3 is supposed to work!

My intentions would be to expand it in the future and make something more interesting to it, but for now I just laid down some basic foundations.

What’s next?

I intend to make frequents blog posts! I know I always say that, and it might take 1 week to do another post, or it might take 3 months, but I want to be frequently writing about the process of making this game engine, and also making some occasional game prototypes.

With some time I might think about doing vlogs instead of blog posts like this, but I’m still trying to figure out how to YouTube.

Speaking of how to YouTube.

This is the fourth video I’ve ever made! and It’s about making a roguelike in 72 hours for Ludum Dare 48! Spoiler Alert: It didn’t go too well.

I want to make an YouTube video every 2 weeks. I feel like that’s how much time I need to actually plan what I’m going to do, actually do something for the video, and then record/edit it. If I get the hang of it and it turns out that it’s easy to do that, I might think of doing one video per week, I might do these game engine vlogs, maybe a “monthly coffee time” where I talk about recent game industry news?!

I don’t know, I still have to get the hang of this YouTube thing and figure out to get good lighting, how to get the camera to focus on my face and how to get the microphone to properly capture my voice…

Remember on my last post when I said: “First things first, I’m not going to stop with development logs”? – Good times. But fret not, my child. After 216 days I am back! As a smart man once said, I am only alive if I write and if there is a thought, there is a writing. Now, I don’t know who is that “smart man” – These are just sentences that are in my head but I’m pretty sure I’m not the one who came up with them, I must have read that somewhere, anyway.

I’m back mostly because looking back at your progress for the past weeks is just a very good thing to do?! And now I am just going back to the roots™ of this devlog – I will do whatever I feel like and then I will come here and write about what I’ve done, problems I’ve faced, what I’ve learned and, of course, add some Michael Scott gifs.

Ha. Now. What I’ve been up to recently? Well, the biggest thing I’ve been working on is making a really simple 2D Game Engine using SDL2 and OpenGL called Realiti2D. I wanted to address my weaknesses as a programmer/engineer, which, in my point of view, are: (1) Lack of understanding of low level technologies like: How does a renderer work? How does a collision system works? How does a UI system or a good Input System look like?

And going through the development of an engine, even if simple, is very challenging. A lot of things does not have right or wrong answers, just different approaches, things that perform better in some circumstances and things like that. Which, to be fair, is really close to real life problems engineers are going to solve.

And then, (2) There is a certain process to problem solving which I believe I have a good grasp on, but I believe I could learn some patience, you know, research more options, think about other solutions, understand the impact that this problem has in the project and the impact that my solution will have for future features.

In this last month I added two new features to Realiti2D: (a) A Collision System; and (b) a Load Level feature from a .json file.

The Collision System

The collision system was an interesting one. It was not the first time doing one, and I opted to do axis-align bounding-boxes (AABB) which is the most simplified way of handling collisions. The biggest questions that arise when doing collisions are: (i) When are all the collisions being checked?; and (ii) How an individual entity handles a collision when it happens?

For the first question, I went with what the book “Game Engine Architecture” by Jason Gregory says, which is to have a Collision World that will, at the end of the application update, check for collisions on all registered Colliders.

And for the second question, I created a callback on the box collider component, like this: std::function<void(BoxCollider*)> CollisionCallback;

And the following macro helps with binding a function to the callback: #define BIND_COLLISION(…) std::bind(VA_ARGS, this, std::placeholders::_1);

And then you have the freedom to create a component that will access the box collider and bind a function to the callback.

m_Collider = Owner->GetComponentOfType<Realiti2D::BoxCollider>();
m_Collider->CollisionCallback = BIND_COLLISION(&PlaneInput::ExecuteThis);

void ExecuteThis(Realiti2D::BoxCollider* Other) {
DEBUG_INFO("Tappy plane collided with {0}", Other->Owner->Name);
}

I do think this is a weird workflow, but come to think of it, it is very similar to how Unity does things, you inherit the functions from a collider and have to define their behavior on your own components.

A lot of work still has to be done here, Circle Colliders and Raycasts are next on my list.

Load Level feature

This was actually a lot of busy work and reading. The system takes in a .json file, but I’m actually using .r2d as the extension. I’m using rapidjson (https://github.com/Tencent/rapidjson), by Tencent, to process the json files. Here is how one entity looks on the json file:

{
   "name":"Plane",
   "components":[
      {
         "type":"Transform",
         "properties":{
            "position":[
               -465.0,
               0.0
            ],
            "rotation":0.0,
            "scale":[
               1.0,
               1.0
            ]
         }
      },
      {
         "type":"Sprite",
         "path":"assets/tappyplane/PNG/Planes/planeBlue1.png",
         "drawOrder":5
      },
      {
         "type":"AnimatedSprite",
         "properties":{
            "animationFPS":24,
            "textures":[
               "assets/tappyplane/PNG/Planes/planeBlue1.png",
               "assets/tappyplane/PNG/Planes/planeBlue2.png",
               "assets/tappyplane/PNG/Planes/planeBlue3.png"
            ]
         }
      },
      {
         "type":"BoxCollider",
         "properties":{
            "min":[
               -32.0,
               -32.0
            ],
            "max":[
               32.0,
               32.0
            ]
         }
      }
   ]
}

And then on the application level all you have to do is have a simple function call, such as Realiti2D::LevelLoader::LoadLevel(this, "assets/SampleLevel.r2d"); – The function that loads the level gets the application reference (illustrated by “this”) so it can add entities to the game.

It is still possible to create entities/components in C++ code, as well as get a reference to an entity created by a file and add other components to it. But my intention is the future is to have a scene editor that will generate those json files correctly.

As for the logic, it’s actually simple, it just reads the json using rapidjson, processes the version, global properties, and then iterates over every entity, and on each entity iterates over its components, and this raises an interesting question: “How to efficiently map a component entry in json to the creation of a new class?”

The approach I’m taking currently is:

if (ComponentType == "Transform") { ComponentFactory::AddTransformComponent(e, Component); }

Which is basically mapping a string to a function on a factory class. The big question when doing something like this is: “If I create a new component, what do I have to do for it to be recognized by the Level Loader?” – In my implementation, I have to create a function on the Component Factory and add an if-else case on the Level Loader, which is sort of annoying and error-prone. I might look into better solutions on a later date.

Also, Realiti2D source code can be found at: https://github.com/guilhermepo2/realiti2D

In my last update, I briefly mentioned that I would come back here to discuss the future direction of this blog.

I have been writing about my game development journey for more than 3 years now. And my goal started as: “I want to make a game”, but eventually it turned into “I want to work in the games industry” as I graduated from Computer Science, moved to the US and started a Master’s in Game Design.

It was a long journey, it was fun at times and very stressing at others. And going straight to the point, this week was my first week as a Software Engineer at Visual Concepts, the company behind NBA 2K.

This week is being a lot of set up, getting a workstation, dev kit, and what not, but hopefully next week I will be ready to jump into action and contribute to NBA 2K21!

Now What?!

First things first, I’m not going to stop with development logs, I will not stop using my personal time to create game prototypes, try different things, learn new things, etc – I’m too passionate about being creative and programming to ever stop doing that.

But now that I work in the industry, the direction will surely change. A lot of my efforts were into making games and expanding my knowledge in C/C++, because those are required things to land that job.

But what is the new direction, you might ask? And to that I say: I don’t know either! I will surely hold off for a little while, I’m in a temporary place where I don’t really have a good place to work, so at the end of the workday I just want to sit on bed or on a couch, but when I move to a new apartment (around 1 month from now?) I will have an office space where I can work comfortably.

And there are lots of things that I want to do and that I can do, such as:

• Continue with Peanut Butter Engine and creating games in C/C++;
• I’m looking into creating a 3D Renderer;
• And with a 3D Renderer, who knows a simple 3D Engine;
• I also have thoughts of transforming my raycasting implementation (last post) into an engine itself.

But that’s not all, there are new things I have been wanting to explore for a long time now, such as:

• Learning and doing something in Godot;
• Doing something small in GameMaker;
• Learn Tools Development in Unity;
• Do small things in Unity just for the sake of it;
• Do experimental projects in Unity;
• Learn Tools Development in .NET/C# and use that to create tools for Peanut Butter, or other engines

And there is also other hobbies that I’ve tried in the past and that come back to my mind frequently, these are:

• Learning to draw to a point where I can create character concepts;
• Creating music for video games;
• Start a YouTube channel talking about more intermediate topics on programming – where the idea is not only having tutorials, but also having videos that more similar to a “livestream” and maybe with comedic tones.

I have to say that the idea of having a YouTube channel is growing on me lately, there is too much beginner content there, not a lot of intermediate/advanced, and I have some ideas that I think can teach and be entertaining at the same time.

As you can see, I have plenty of ideas, and possibly I will tackle a lot of them through the times, but which ones I will be doing first and how I will use my time, that is for future me to decide!

Alright, that’s all for this random update!

Oh hi it’s me here again with the occasional monthly game development log post! What happened last month? not much, not much. Just kept looking for jobs, working in an Unreal game with people from my Master’s degree and I don’t know where all my free time went.

I haven’t been really active lately on my personal game development studies, I’ve been trying some things and getting geeky in C++.

Peanut Butter PONG

Last blog post I mentioned Peanut Butter Engine, hey, it’s my own engine!

After advancing a little bit with it, adding particle effects and working a little bit more on the structure, I started to make the first game using Peanut Butter Engine! Which is… Peanut Butter PONG! You can see a gif right above.

I still have a long way to go through, here is what’s on my wishlist for Peanut Butter Engine (and PONG)

• Clickable UI Buttons (which call a function and executes something)
• Scenes/Levels/Transitions (Working on integrating Lua in the engine for that)
• Pause Functionality
• In Game UI (Such as Panels)

And after all those things, I have a little backlog of games I want to do with Peanut Butter Engine

• Asteroids
• Space Invaders
• Pac Man
• A Platformer

And after doing all these, my engine will probably have a good architecture, after that I want to worry about exporting games to windows, and the dream would be building games for web.

Raycaster in C

I also worked in this Raycaster in C, I won’t extending myself too much talking about it, just appreciate the end product on this tweet right above!

As you might know, all of those things are open source on my GitHub!

https://github.com/guilhermepo2/PeanutButter

https://github.com/guilhermepo2/PeanutButterPONG

https://github.com/guilhermepo2/RaycastingRenderer

I will cut my update short this month, and I want to make another post here in a week or two and possibly discuss the future of this devlog!

Life has been crazy recently, I graduated a few weeks ago, released a game, had to move to a temporary place, job hunting has been crazy and the “omg I need a job” anxiety is kicking in really hard, but anyway, this is not the place to talk about those things, this is the place to talk about game development!

Your Human is Sick!

During my Master’s in Game Design, I was part of the Serious Games Capstone, and I had to opportunity to develop a game that I pitched, created all the documentation, acted as director and programmer. And that now is on Steam!

Link on Steam: https://store.steampowered.com/app/1290510/Your_Human_is_Sick/

The game has its problems and I’m working on bug fixes and possible updates, but as of right now I’m really happy to have this game on Steam!

Now let’s talk about personal projects and what I’ve been up to!

LDJam 48

Participating in a Ludum Dare is something that I always wanted to do since… 2018? Or something like that, and this time, this year, this April, I decided that was it, I was going to make it!

And I made it, I finished a small turn-based game for Ludum Dare 48, called escars. You can play it on itch.io: https://gueepo.itch.io/escars

Sadly enough, I forgot to play other Ludum Dare games, which is sad, because the ~10 games I played were really interesting and entertaining, so because I didn’t play enough games, my game did not get an official rating, maybe next time!

Peanut Butter Engine

I’ve been talking about improving my C++ skills here for a long time, and that journey took me to sites like HackerRank, where I could practice algorithms and C++, and then it took me to Unreal Engine, which was a nice journey.

But getting deeper into that hole, I noticed that the next step, the next thing that would make me improve in C++ and further improve me on game development was… making my own engine.

I didn’t want to get into 3D, so I decided on making a 2D game engine to create tile-based games, and decided to call it Peanut Butter Engine! and I also wanted to make it open-source and a project that I will be working through the time!

Link to the Peanut Butter repository: https://github.com/guilhermepo2/PeanutButter

I am using a lot of references to make this engine, and they are all cited on the README.md on the repository, so feel free to take a look! Future plans and directions are also included there.

What comes next?

The biggest thing for me when answering this question, is to also answer the question: “What if I don’t get a job?” – If that happens it will mean I won’t have an income in the future and there is a lot of consequences on that. Anyway, here’s what’s currently on my mind:

• I’ve been dabbling on different ideas and prototypes to come up with games that can be commercialized and could potentially generate some revenue so I can sustain myself, maybe I will have something by next month?!
• I’ve been studying Multiplayer in Unreal Engine, and I would like to maybe come up with a prototype of a deathmatch third-person shooter, or anything simple but that can be a multiplayer game.
• As for Peanut Butter, I feel like I have a good framework set-up, I’m currently going through the book “Game Programming in C++” so I can learn a little bit more, after that I still have to do some work on the Sprites/Animations modules, because I currently don’t like how it works. And then I have to fix some dependencies using premake and start making games with it! The first one I want to make is Pong, and then maybe the remake of an old platformer of mine, happily(never)after.

That’s it for April and (a little bit of) May, I will see you next month and hopefully, I won’t be too late for next month! Now back to my Island in Animal Crossing!

Cheers!

I skipped the February update, oh well. Not that I had done a lot, no, all I had for that month was a shooting prototype in Unreal I made in a few hours.

Having time to do side projects in game development has been a Herculean task lately, I’m in between school, which pretty much demands me the same as a full time work, and it is about game development, so also working on it on my side project has a potential to burn me out. On top of that, I still have homework/assignments! On top of that, job hunting has taken a lot of my time lately, and on top of all that, I’m binge-watching The Office.

With all that together, I haven’t been able to have any good progress or anything interesting that I developed in my free time. And the problem here is that I’m taking it too seriously, and I do that a lot, my mindset is always “How can I do an interesting game that can take 2~3 months?”, “What mechanics are interesting for a new game?”, “How to make an interesting progression system so a game can entertain people for hours and hours?”.

And I think the key is to not take it seriously. So my approach now will be prototyping mechanics, simple ideas, prototyping anything, not spending a lot of time and not committing to anything because the purpose of a prototype is to throw it away anyways.

So, anyway, here are some ideas that I tried bouncing off lately.

I was trying to come up with a combat mechanic that plays similar to Astral Chain, which is, I know, very hard, I just started doing it and started playing with launching the character on the attack and transitioning to/from attack animations.

This is a really really simple top-down shooter, I was just messing with the dot product and trying different things and I came up with the idea of a shooter that you can only hit your enemies from behind. Imagine an 8 person match (you and 7 bots, or multiplayer, who knows!) with that idea – It could be a quick and fun small game, 2 minutes of fun!

So that’s what I had for this month! I wrote down a list of small ideas/mechanics/things to prototype, and who knows what is going to be here next month!

A lot of things happened in January! Most of them good, so I got that going for me at least! But I’m already very late to write this post. I swear I didn’t give up on this and I will get back into doing projects and working on stuff!!

Around January 5th I got back to the US to finish my Master’s in Game Design, and for some time I had to make an effort and focus on updating my portfolio and resume, so I can get to a good point where I can apply to jobs, I did all that, so now I have to just keep them updated and keep searching for jobs! But while making this effort, I didn’t have the best of times to work on side projects, and after I made all these efforts, I just took it easy for week, so I had a lazy week (A week where I only work on everything that is required from my Capstone and Master’s Degree). Anyway…

Defensees

Defensees is finally out! Play it on itch.io! – That’s the tower-defense with roguelike elements that I talked about last month. I had a lot of concerns with this game idea but ultimately I wanted to make something out of it and release a game. It is very basic, it contains a simple turn-based system and simple wave spawning and progression system.

The major concerns are still there, no mastery, no secondary goals, no whatsoever, it’s just you slaying some dungeon monsters trying to not die and trying to not get the door destroyed. But I didn’t want to postpone this game too much and I’m actually proud of this little project.

There are plenty of directions this game can take and there are many versions of it in my head where it is a more complex game with more roguelike elements, but unfortunately, right now, Unity and C# is not something that I want to work on and I don’t think it’s something that would push me as a Gameplay Programmer.

So… now what?

“Now what?” is a very good question right now – It’s very simple actually – I have to make things that will make me improve or showcase my skills in gameplay programming and C++, and I already talked about that in a previous post, and it would be even better if in this project I could add some interesting systems, practice some 3D math, things like that!

Here’s the options that go through my head right now:

1. Making a Gameplay Demo in Unreal Engine.
   1. This is similar to what I was previously doing, but now it would be something more serious and I would put more consistent effort and work on it longer.
   2. For this, I would buy an animation asset in Unreal Marketplace and work on making combat gameplay (Action RPG, inspired on Dark Souls or Astral Chain, there’s these two possibilities) or making something more inspired by a shooter game (Resident Evil 2 or Tomb Raider).
2. Making a full game in Unreal Engine.
   1. That’s a longer route, I would have to come up with a gameplay mechanic and a gameplay loop and make it not be too long somehow.
   2. I also would need to search extensively for 3D assets to use, probably what I found and what I can buy will dictate what I will be able to do.
   3. If I find good enough assets, maybe I can do a 3D version of Defensees!
3. Make a roguelike in pure C++.
   1. Yeah, I just love Roguelikes.
   2. They are interesting games full of systems, and I would have to code some interesting systems and create my very own small engine, which would be very interesting.

Anyway, next month I will be talking about which direction I went (there’s a high chance it’s going to be one of the first two AND a roguelike in pure C++, I just love roguelikes and I always wanted to kind of create my own engine… so…. it fits well.)

Anyway, thanks for reading until here!

After a lot of time in the US, I’m back at home in Brazil during my Winter Break! It’s just two quick weeks here and then I will have to face 24 hours of airports all over again to get back and finish my masters the following year.

Last months I’ve been more on easy gear, I will use this time to have some more-than-needed rest and then get back at my pace, lots have to be done in the following months!

Creativity is weird

I said here last month that I wouldn’t be working on Aglarond anymore, I also said I maybe would still work on game projects that would be even smaller scope. The thought that I had an interesting and fun turn-based combat system coded (well, it is interesting and fun at least for me) but wouldn’t make anything with it kinda made me upset. But to be honest, I was ok with it.

But suddenly, my brain threw me an idea. Well, not really suddenly, related ideas applied to other genres are something that I discussed a lot with fellow teammates on the studio I attend for my Master’s.

The idea is really simple:

• It all happens in a room. So no room generation and no level design, well, there is a minimal aspect of level design, but this is something I’m fully capable of.
• Defend something. In this case, I think I will go with the door, or the throne, it doesn’t really matter.
• Monster spawn from specific places in the dungeon. In the gif, the iron door is where the monsters would be spawn, but ideally, maps should have 2 or 3 spawn points.
• Monsters spawn in waves. The first wave has 4 monsters, the second wave has 6 monsters, and so on and so forth. Waves get increasingly difficult and in between waves is when you recover some health and give your brain a little break.
• Monsters want to destroy what you must protect. Have to have some conflict, right? I can experiment with different flavors of monsters, some can attack you, some can change goals, etc…

And also, I bought some pixel art roguelike assets for the game, and I might buy some sound effects, I just don’t want to spend time anymore doing things that won’t push me as a Gameplay Programmer, and also, these assets are way better than anything I would ever be able to do anyways.

There are some problems I can see with this game and I will point them now, but before pointing them I just wanna state that I don’t care, I will make this game and release it, and if I can improve some of these points, good, if not, then, well, at least I still think it can be a quick fun game!

• It doesn’t have mastery. This is the biggest one, Roguelikes are a lot about mastery, and although this is not a roguelike, it draws pretty obvious inspiration from the genre. How the 100th hour playing this game differs from the first hour? What are you learning about the systems? What are you learning about strategies? There’s not much to learn so not much room to achieve mastery.
• There are no secondary goals. Right now it is all about killing monsters before the monsters kill the door, or the throne, or you, there’s not much to strategize, I’m afraid the game will be just a “slaughter the monsters until you are mathematically not able to survive”

There are some ways to try to remediate those issues, which are:

1. Adding spawn locations for health pickups in the middle of a wave. This can create situations where players have to decide whether to engage in combat or get a health pickup in order to survive longer.
2. Adding random power-ups at the end of a wave and/or in the middle of a wave. I can easily have power-ups that make player health regen faster, double the damage for a while, make their speed bigger for a while, give immunity for a while, make the player take less damage. This can create both mastery of the system and secondary goals, as well as changing the playstyle according to what power-up the player has at the moment.
3. Having more than one level. I’m probably going to do this anyway, but I can have different levels for the game, with different amount of doors, different layouts, and whatnot, these can make players strategize and play in a different way, also make the environment less boring.
4. Adding doors that can be locked/unlocked. If the door is unlocked, enemies spawn from them, if it is locked, no enemies spawn from it. This can make me explore more enemy variety because I can add an enemy that sole purpose is to open any closed doors. This also adds strategizing for the player in the form of “Should I guard the door or should I go lock that door?”, “Should I protect this spot or go kill the enemy that will try to open the door?”

… At this point I just noticed I turned my monthly update post in a short Game Design Document for this game, well, that’s fine. I just wanted to describe what it is, some concerns I have and some possible mitigations for those risks. All in all, I think this was informative and some good bits on the game design process.

Quick Unreal update

Besides that, I’m working on an Unreal Gameplay demo to practice my gameplay programming skills, create portfolio pieces and flex my C++ muscles. I’m trying to create gameplay for the Paragon hero asset Sparrow.

It has its problems, such as: (1) there’s no animation for walking sideways with the bow down, (2) the camera doesn’t follow the character when moving to the left or right when the bow is down, (3) shooting have no impact (and no code for hitting anything at all)

I wanted it to be a demo of a game where shooting is meaningful, it would be a stealth game where you only use your bow when absolutely necessary, so using it should feel thoughtful and powerful. But anyway, this is something that I still will work a lot on and improve a lot!

Anyway, that’s it for my monthly update, thanks for reading!

This month is probably full of uninteresting things, unsatisfactory progress, me being burned out, going on game development tangents and giving up more projects. Let’s do it boyz!

On the more upbeat side of things, the first game I worked on my capstone, Bopping Blobs, is finally out on the Google Play Store! It was a quick six-week project to get people all warmed up on game development, the game is all about giving you a short and easy entertainment for no more than 2 minutes!

Go grab it on Google Play Store! (Link Here)

So, now for the actual update of the month.

I was feeling burned out in general with Capstone (around 8hrs/day) and classes and all the things I still would have to do, so I didn’t really feel like being strict on myself to work on side projects. I know that I need to be working on more projects in order to achieve my goal of working in AAA, but being honest, the game I’m doing in capstone and performing well in school is a bigger priority. And knowledge and released games on Unity is not really what AAA cares about the most.

So this brings us to the freshly made decision of: I will not work on Aglarond anymore. I’ve been studying roguelikes a lot recently, because I wanted to do my own, and I got a few conclusions:

• A roguelike is all about experimentation and exploration;
• The fun in a roguelike emerges from all the interactions of all systems and from the feeling of mastering each one of them;
• Ultimately, a roguelike is a game about telling stories, it is all about what the player will tell their friends, they will talk about that time where they pressed a switch and set the entire room on fire, they will talk about that time where they went 20 floors deep and were killed by poisonous gas because they accidentally used the poison potion on the previous floor.

Doing a “roguelike” is easy, making a very good roguelike is hard, and way out of scope for the time frame I want and the resources I have.

Also, I wrote some devlog posts: Turn-Based System for Aglarond and A Postmortem for all the Roguelikes I ever tried to make!

But will I be working on them?

That’s so… Unreal

I’ve been messing with Unreal Engine 4 recently, following tutorials, reading about things and seeing how to do things, I have a very simple moving character and some collectible items, I’ve been enjoying using Unreal and I might keep working on this prototype. The goal for it is to be a simple Action RPG (i.e. Dark Souls) style gameplay demo.

But I cannot make an entire game in Unreal! I simply don’t have the time and resources for that either, that’s why I will be working on gameplay demos, which is what will help towards my goal of being a Gameplay Programmer in the game industry.

I want to be working on entire games as side projects, but I’ve managed to fail 3 or 4 projects this year already, and I have to improve and be good at two things: 1) programming gameplay and 2) C++ – And Unity does not help with the C++ side of the equation.

Maybe I can try to come up with things with even smaller scope (like 1-month games) and see how that goes. If I do that, I want to work on experimental or interesting game ideas, not on established formulas that everyone already knows.

But for now, I will just enjoy not having to force myself to work on a side project that I’m unsure if I can finish and release it.

Thanks for reading my update!

I feel like this month I had a lot to do and did some interesting stuff on my capstone for my Master’s Degree, I wanted to have them in this post but due to virtual paperwork, I’m not ready for that yet!

Aglarond

Getting straight into meaty content, I didn’t work on Aglarond for about 2 weeks, the project didn’t have any progress between September 26th and October 7th. And also I am rewriting the Dungeon Generation System, which I estimate one week of work time, with all that, Aglarond should probably be delayed for 3 weeks! With all that being said, Aglarond is still a 2~3 month scoped game and I want something that small because I knew delays probably would happen, because of school and whatnot, but still the game should be released before the end of the year, that is the ultimate goal.

Right below you can see how the dungeon was before rewriting it, I have the turn-based system in place, the dungeon generation and the field of view, these are the 3 pillars of a roguelike! So I’m into something already.

I wrote a blog post about Tiles and Field View for Aglarond (click to see).

The problem with the previous Dungeon System is that it used a maze algorithm for the connections between rooms, I honestly don’t know why I thought that would be a good idea, it led to uninteresting and excessively long maze-like paths in the dungeon, which were just boring.

I’m switching to the approach used by Brogue, which is basically (i) create a room with positions that can be doors (I call them door candidates) (ii) add a room to it (iii) repeat ii until the dungeon is complete. A room can be a square room, a circular room, and they can have a hallway. You can see a screenshot of it below, currently, it just create rooms and connect them based on the door candidates for it, but it is way better already.

The next step for Aglarond is making the rooms created more interesting, which means adding variety to how they are and adding hallways. After that, I have the three core features of a roguelike in place: Combat System, Dungeon Generation and the Field of View. After that I should start working on a simple item system and have it in place so you can find scrolls and potions in the dungeon, that would make the game more interesting.

AND AN IMPORTANT ANNOUNCEMENT: I was going through Brogue’s source code and have been playing it a lot lately, that’s when I realized how complex the systems and all the interactions can be in a roguelike. I wanted to have all the complexity on Aglarond but I also didn’t want to blow scope, everything I have planned is not even 20% of what a complex roguelike has, and I would like to have all that. Roguelike development is very iterative in its nature and every tutorial or talk focuses on having the basic core gameplay and then adding whatever form of complexity you want on that.

That’s when I decided that I want to try making Aglarond some sort of life long project, that’s what a lot of roguelikes are after all, so the basic core gameplay would be released and I would keep working on updates as time goes by. Everyone that buys the game will have access to all future updates!

Card Game!

The reason Aglarond didn’t see much work done for some time was because I was making a Card Game prototype! I made it based on this online course and first I made exactly as the course said and did, and then I rewrote the entire code to my syntax, my standards, etc…

There are still many things that I have to approach and fix, a lot of the systems in the game are strongly tied together, and I can see a thousand ways how that could be a problem in the future, I want to fix a lot of animation, elements positioning and refactoring code, making the systems more loose, I don’t exactly when I will do that, but that’s what I want.

There are many reasons why I suddenly made this Card Game prototype, first, I always wanted to try doing it, second, I love Hearthstone (the prototype is basically a Hearthstone clone), third, I pitched a card game for the studio I’m working on for my capstone in my Masters Degree, so I wanted to have a prototype to show I could actually do it and convince artists and designers to want to make the game, the idea was well-received, but when we talk about really making a card game in a studio, there are some considerations that needs to be done, such as, “How can I guarantee this will be within scope?”, “How will I address AI?”, “What are the cards going to be and how can we adapt the card art style for the artists we have?”, and, most important of all: “How this is not just a bad Hearthstone clone”

These are things I still have to answer, but hey, a little of polish and fixes and it can be at least a portfolio piece! Or I can end up making a card game in the future, who knows.

That’s it for this month’s update! I will try to keep focused only on Aglarond, but there are plenty of other side projects coming up that I might tackle, especially considering I need to improve my C++ skills, Gameplay Demos on Unreal might be appearing here next month!