Hey everyone, normally an update devblog would be something exciting, but this one is bittersweet.

Let me get this out straight away: I’ve decided to put Project TBS on indefinite hold. As a Game Dev who wishes to make it into the industry, I felt that I don’t have the artistic skillset to make my vision of Project TBS come to life. Because of this, I was getting really burnt out overall and no progress was being made.

I’ve decided to scale back and work my way up on my artistic skillset, that’s why Project TBS at the moment is going to be put on hold since it’s a game that the necessary art is something that I simply don’t have right now. I know this might be rather disappointing, but I prefer working on my way up on the skillset so I can be a better developer overall.

As for my plans for the future, I’m working on different prototypes with small canvas size (8×8) on the pixel art front so I can make something with my art and that will develop me as a better overall Game Developer. You can expect to hear news from me in the coming weeks about what my next project will be. Meanwhile, have this 8×8 Link that I’ve made on my first day on learning Pixel Art:

Hope you all have a great day!

Hey everyone! Long time no see 🙂 I had a crazy weekend/week with Ludum Dare 49, but first and foremost I would like to give you all a small update on Project TBS (Turn-Based Strategy), let’s get to it:

I’ve finally decided on a scope for the first playable version of the game and I’ll be working on it non-stop until it happens! That’s great news since it made me much more motivated to keep working on Project TBS.

I don’t have much to show for updates right now since I was really focused on Ludum Dare 49, but I do have to show some stuffs.

I’ve started on Asesprite and working on the game art! I’m no artist by any means but this is the perfect opportunity for me to work on that! For my first art for the game, I made a placeholder sprites that our units are going to be based on! Check it out:

Check out how I also made a red version of the placeholder sprite for team red! All of the game’s future units art will be based on these placeholder sprite and will be iterated on! I can’t wait to start conceptually designing the units!

As for how it looks in-game:

Notice that I also added a indicator for the mouse! It snaps to the tile x and y coordinates wherever your mouse is hoving over!

As for our past entry goals, none of them have been met yet thanks to the small amount of time I was able to spent on this project. With this, our goals for the next entry will be:

• Add Turns to the game. Not allowing units to move more than once per turn.
• Don’t let Player 1 control Player 2 pieces and vice-versa.
• Add a basic prototype GUI for when you select a unit. Allowing you to select “Move/Attack/Magic/Wait” options, with “Move” being greyed out if the movement action has already been taken.
• Adjust the Camera Rotation mechanics to take into account the unit’s sprite

Check out that we also added a new goal for the next entry. If everything goes correctly we will have a LOT of stuff to showcase for the next devblog entry. With that said, expect another 2 weeks for the next entry since I’ll be taking next week off to deal with in real life stuff.

And that’s all for our small update entry! Next up: Ludum Dare 49 Post-Mortem

Ludum Dare 49: Post-Mortem

If you haven’t checked out my LD49 entry, please check out by clicking here!

So, let’s talk about it. LD49 happened on Friday 10/01 through Monday 10/04 and it was pretty hectic! It was my first ever Ludum Dare entry and I couldn’t be more happier! The team I entered was a team that formed through the Ludum Dare discord a month before LD49 started and we were all pretty excited, defining scopes, setting Git repositories, etc…

Well, things went kinda bad pretty quick… Our 2 artists were missing for the major duration of our work and I had to scrap whatever they had done and bring it manually piece by piece to the Unity Editor, I can say that I missed some significant development time thanks to this.

Our compositor however made some really cool music and sound effects for our game and was communicative with us.

Me and the other programmer (and team leader) were non-stop programming! Sunday especially was crazy, I woke up 5AM and programmed non-stop until 11PM. That’s 16+ hours non-stop programming. I learned a LOT with the team leader since he actually is a software developer and knows tons of good practices when coding stuff. I learned so much with this and will take these lessons into my gamedev life.

Our scope of the game was way more than what we actually had, our end product was because of our art deficiency and working with what we got. We also lost time to some technical aspects that were not meant to be so hard to code in. Especially the smoke particles system. The smoke particle system was heavily spaghetti-like code and everytime we changed something, for some reason our smoke particle system would stop working. We would’ve liked to polish the code for it and prevent this from happening but we simply didn’t had time to do and had to work with it’s spaghetti code behaviour.

All in all, I think we managed to have a interesting end product and many people enjoyed it! However, for my next game jam I really want to work alone so I can have more input on the game design decisions, I really want to work on a FPS-Horror kind of game for my next jam. That’s why I’ll try to learn some sound designs for my next Jam.

That’s about it, thanks for reading up here and I’ll see you all in my next Devblog entry 🙂

Another week goes by! Wow time sure does flies fast! Can’t believe that Ludum Dare 49 is almost here. This also means that don’t expect a devblog update for next week since my focus this week will 100% be for the upcoming Ludum Dare GameJam.

Last entry we set up some objectives to accomplish and I can happily say that all of them (well, almost all of them) have been succesfully achieved!

Take a look on how’s the project looking:

So, let’s go step by step and take a look on everything that has evolved.

First and foremost, you can see a new map has been used, instead of the placeholder one from the last entry. This map layout will be one of the few maps that’ll be available in a future version 1 of this project. I’m aiming for the version 1 having 3 different map layouts.

Second, we can see that we have sucessfully implemented a pathfinding system, along with a a indicator showing how far that unit can move. For the pathfinding, I want to thanks quill18creates for his amazing tutorial on how pathfinding works. Basically we used the Dijkstra’s algorithm to calculate the path a unit would take to reach it’s target position. We could’ve used an A* algorithm for the same purpose but it’s a little bit more complex to implement and, for the first iteration of our project, Dijkstra’s algorithm would do the job just fine for just a little bit of loss in the project’s performance.

One of the points that we made for our last entry is that we would have a walking animation whenever you moved a unit. However, after going back-and-forth on this, I’ve decided to scrap that. I feel like snapping to the tile selected would just feel better for the player. If I feel like extra polishing later on I could add a walk animation but for now I like how it feels right now.

A issue that you may have with the map above is the grey tiles obstructing your view. That’s why we added options to rotate our camera! Check it out:

Later on, I feel like I could add a outline whenever a unit is behind a tile obstructing it’s view, just to remind the player that you have a unit hidden behind that tile. However, for our prototype, it’s not in the pipeline at the moment.

So, basically we achieved (almost) everything AND more for our last entry target goals. We do have a 2 player units set up BUT Turns are not implemented yet.

Also the unit can take more than 1 movement action per turn since turns are not implemented. Basically we want that each unit can take a movement action AND a attack/magic/wait action in the same turn. For this, our goals in the next updated entry will be:

• Add Turns to the game. Not allowing units to move more than once per turn.
• Don’t let Player 1 control Player 2 pieces and vice-versa.
• Add a basic prototype GUI for when you select a unit. Allowing you to select “Move/Attack/Magic/Wait” options, with “Move” being greyed out if the movement action has already been taken.

This will be a interesting challenge because I’ll need to add a Game Controller script to handle the Turn events and also “redo” the Unit Controller to allow it for different types of actions, instead of just moving around.

I do want to point out that the next updated entry on this will probably not be next week. That’s because Ludum Dare 49 is coming up and my attention this week will fully be for the upcoming game jam. That’s why we’ll have a delay on the next updated entry. However I do appreciate all of you who have been reading through these entries. I’ll add more info on the Ludum Dare project on this website later on, so hopefully you’ll want to check it out 🙂 Thank you for reading all of this.

Hey guys! Remember when I said that this would be a weekly Devblog? Well… that didn’t age well. But there’s a good reason why there wasn’t a entry in this devblog last week!

If any of you have been following my Twitter, you would know that I’ve decided to move away from GameMaker Studio 2 and move into Unity right about after writing Entry #1 in this Devblog.

This is for some reasons that I’ll be addressing, but the major one is that Isometric (or the kind of game that I envision) games benefit WAY more from a engine that supports 3D environments. I’m not saying that doing 3D stuff in GameMaker Studio 2 isn’t possible, but GMS2 wasn’t made with that in mind. It’s kind of like trying to fix a hole with tape, sure it’s going to work for your need, but the scalability is not there and it can easily fall apart.

Another reason is that Unity is more of a professional engine that uses of C# programming and is considered way more interesting when sending CVs to companies that requires gamedev experiences.

Last but not least is that I’ll participate in Ludum Dare 49! I’ve found myself a team and the team decided that they would work in Unity for this jam. So changing this project’s engine to Unity would already get me used to the engine for Ludum Dare and also work in the projects favour. Win/Win situation.

But, with that change, there was a lot to unpack. I needed to learn how to use the Unity engine. That took me some time, I’ve ended up doing some 3D stuff like FPS just to get used to it and also ended up following a tutorial for a prototype of a Isometrics game in Unity (see the prototype of Jonathan Parham’s tutorial below)

This was all fine and dandy, but I still had to decide the scope of my game and honestly, this tutorial, while did get me used to Isometric games in Unity, it wasn’t in the scope that I was aiming for.

See, the kind of game that I envision is one of short custom sandbox matches, where you play against either an AI opponent or another human opponent. There would have a number of maps that you could choose from (just like Warcraft/Starcraft matches) and also factions that each one has their hero unit. The game would load and then, in the first stage of the match, you would place your units in your side of the map, while your opponent placed his in their side. Your hero unit is a single unit that has a Ultimate ability that would be made available after turn 6 (or before, if they get to a orb situated in the map).

Jonathan’s tutorial is a REALLY good tutorial, but as you can see, it’s made entirely into Final Fantasy Tactics Campaign style games, with Level/Experience/Stats and all kind of stuff. And I wouldn’t need all of that for my scope.

That’s why I decided to start writing my own project. With the help of quill18creates Tile & Pathfinding system youtube tutorial series, and seeing how someone else made an similar game. I’ve been able to start writing my own system, that takes into account some RTS mechanics coupled with Advance Wars systems. At this point I’m considering dropping the title “Tactics Project” entirely since this is more of a Turn-Based RTS game and using “Tactics Project” can be rather misleading, so starting next diary entry, I’ll be using Turn-based RTS name for this project.

As for how far I’ve gotten into the game:

Well, basically I’ve really started working on the game yesterday. All of this time it was just learning the principles of RTS Turn-based games and defining the scope of this project. I don’t have much to show you but I guess you can see some of these early prototype stuff going on at the moment:

As you can see, not much is going on. We have a camera system that we can move around the map, the camera centers on a unit once you click on it (represented by a unit indicator a.k.a the blue circle) and you can move the unit around once you click on a tile after selecting it. However, there are a lot of stuff missing in this:

• The unit doesn’t have at the moment a pathfinding system, it just teleports to any tile you click.
• The unit doesn’t have a animation to moving to the selected tile.
• There is no indicator nor a limit to how far this unit can move. Ideally it should have a set number of tiles it can move to from it’s position.

So, for next week, my focus will primarily be:

• Setting up an pathfinding system for the unit.
• Have a animation to it moving to the tile selected instead of just teleporting.
• Make a indicator system as how far this unit can move.

I hopefully think I can get this working but it will be a challenge. Anyway, thanks for reading this devblog entry and sometimes I’ll post some interesting tidbits in my Twitter if you wish to follow that. I’ll see you all next week with hopefully everything that I’m setting out here being accomplished 🙂

Here it is! My new project! I decided that I would take this blog here in my website as a devblog diary for the development behind this new project which is by far more ambitious than Bubblesy.

This new project is supposed to be a game in the vein of Final Fantasy Tactics. Nothing too fancy, just a love letter to this kind of game since I always loved them. I’m still deciding if I should just make a sandbox style game and have people have fun in how they are going to play it or if it should have a campaign and be more direct.

Anyway, I had to learn a lot to even start making this project! Isometric games are not easy to develop at all. There are so much math behind the screen going on with the tiles, grids and everything that if it weren’t for GameMaker Rob series in Tactics Tutorial in GMS2, I probably would have a really hard time starting doing this project.

So, these development updates are going to be a weekly thing going on from now on, and to start our first development updates, I would like to showcase my progress in the map editor of the game and the core mechanics behind tiles, grid and heights that I was able to already make it happen in game (big thanks to GameMaker Rob)

For my next task, I have to work on some sprites for the characters that I’ll use. Bad news is that I’m not a artist by any means and I haven’t been able to find a Isometric character pack asset at all in Itch.io. The good news however is that I found an template of a character in the veins of what I want to do, credits to KeySataniel for the template.

So, for my next week and so, I’ll probably start working on iterating this spritesheet and see what I can do for a Fighter class, for example. This is going to be tough, but if I want the game to have any art at all, I need to make this happen. We’ll see on this goes.

If everything goes to shit I guess I can just hire someone to do it, right? RIGHT? (sweats frantically)