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 🙂