Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles

Project Cyborg

A topic by oreismatheus created Dec 28, 2017 Views: 650 Replies: 3
Viewing posts 1 to 4
(1 edit)

Project Cyborg

Hello! I'm Matheus, started working on that game called Project Cyborg and felt like using this place to post updates and roadmaps, mostly to let people know a bit more about my intentions and to keep myself motivated. The idea behind the game is to be something kind of like FFTA (Final Fantasy Tactics Advance): pixel art, turn-based strategy RPG with isometric view. Some of what I've got so far:


In PC (ohh gotta love this acronym), the players won't control their whole team, but only their captain cyborg. How about the others? They will be controlled by their AI, which are made by their owners. How does that work? To illustrate, here's some of the "gambits", under the hood:


Whenever a cyborg's turn starts, it will loop through the list *rank* times (1 to 3) and ask itself questions (causes - blues) and execute commands (red - effects). The tiers will work like:

  • Tier 1 cards are the simplest, since a rank 1 robot can only loop through the list once, they're very "complete"  and will pack all of its actions for the turn (such as Chase -- get close to and attack --, Use Item, Flee -- move to the safest spot from -- or Kite -- attack and flee from --). 
  • Tier 2 cards introduce the cards that pass causers to children cards (Is Enemy HP lower than %, Is Enemy Reachable, Is Distance To Lower Than)  & more specific actions (such as Attack, Move To). This gives the AI a bit more specific actions, and the possibility to make AIs a bit smarter.
  • Tier 3 cards introduce the getters, that return lists of results, that will give even more specificity to actions. The idea behind the getters is to let people get some data and pass to cause or effects, but at a cost: people will have to pay attention at the getter type because the game won't spoon-feed them (say you get a list of enemies and try to do a Move To to the result, that was expecting a position, that would lead to a bug that would cancel the cyborg's turn). I'm also considering adding paths and the possibility to block a path for some rounds so your cyborg doesn't spend a turn doing something that it has already done too recently.

The cards and how tiers work will change a lot, that I'm sure of, especially when I start balancing stuff out. How a simple tier 3 AI could look like:


So the goal in this game is to make progress by getting better gear and AI cards and fighting other cyborg enthusiasts. The idea is to make 7 stages, based on the most technologically advanced countries in the world right now, being England the first stage (and 7th country), and the last stage being USA -- the list may change a bit in the future when I get to do further research.

Cyborgs

The cyborg management is the main feature of the game. There will be 3 ranks and 3 types of bodies which grant them different bonuses in their stats, which are:

  • Strength
  • Resistance
  • Accuracy
  • RAM
  • Athletics
  • Move

They also will be able to carry a weapon and an accessory, which can be a throwable item, an equipment (a shield or even a special ring), aid and possibly traps. Players would need to build different types of AIs for each kind of cyborg they want, for example: say you equip cyborg with a support AI that will always have as priority look for weak allies to use an item; if you equip them with a grenade, they'd destroy their own allies (I can laugh at this just by imagining, lol).

So, that's that, I hope to not turn this into an absurdly big project, which is not the intention. I want to build a very linear game telling the story of a tech-savvy that is crazy about robots and gets to know about the PC, which is a cyborg fighting competition. I also have no intention to make the sprites, they're all placeholders and I've even found the perfect pro pixel artist to work on this game's graphics already.

You can follow me on Twitter if you wish: @oreismatheus and ask me anything there, there are some older gifs of the game that are even a bit more advanced than what I showed here (which is the current state of it, since I'm rewriting the code).

Goals for the next weekend (Jan 6th)
  • Proper movement, mov. animation & rotation
  • Basic attack system
  • Simple menu
  • if possible: action queue

Since the battles will be done in arenas, I think that image illustrates how I want it look like a bit better:

I plan to make the first stages like industrial sheds and then, as you advance, you'd be battling in greater places, even with crowd.

(+1)

Good morning! Since I started this devlog, I’ve been working a lot on the game. Well, first of all, I'd like to mention a bug that was driving me nuts for the whole week. There was something wrong with my A* implementation which was making actors see some spots that were unreachable as reachable, such as:

That was happening because I removed a key part of that code while trying to optimize it, which was:

That happened because, when a path is not found, the algorithm returns a path with 0 points. When I read that like a week after writing it, I was like: “well, that check’s completely unnecessary”. The problem is that it only became an issue a day or two later, so I had no idea what was causing it, or if it was my A* map implementation that was buggy. From now on I’ll start leaving a lot of comments in my code so I don’t stand in my own way by doing stupid stuff. Also, my new motto:

“Early optimization is the root of all evil.”

I also started working on some console messages since I don’t want to spend time working on GUI. The time one spends doing GUI is absurd, and it usually gets me unmotivated to work on the projects. Reason? Well, it sucks to work on something for a whole day and the result is that there’s more text populating the canvas.

I made a simple movement system which is far from ideal but makes things feel a bit more alive, I don’t feel like spending time working on that kind of stuff now, the core of the game will be a priority (read A.I., stats, equipments and such). The stats were implemented but only Athletics work so far: the higher the athletics, the farther an unit can move; it will also affect how quick an unit’s turn will come and how high they can jump.

That’s what I’ve got so far: units that can move around, passing through units of the same group (just like in games like FFT), and the distance is based on their Athletics stat. I decided to call the ranks as CPU cores (single, dual and quad) and their bodies cases. Seems adequate. So yeah, even not achieving much, I’m glad I spent a lot of time on the game in the past couple of days and I hope to bring some cool updates next saturday!

Howdy, I'm back!

Whew, I've worked like crazy in this project for the past 7 days, and I'm pretty glad with what I've achieved. Even though it's not -- still -- that visually pleasing, its battle system is starting to turn into something. Well, at the beginning of the week, I decided to get a .txt within the solution of my project to write down my short-term goals and my milestones:

This is not only fun to keep track of your tiny accomplishments but it also helps me a lot. As I stay in front of the PC for hours and hours, my brain start to malfunction and I keep forgetting stuff, so knowing exactly what I'm going to do next helps me a lot by saving my time. How? Well, more often than I'd like to, I forget what I'm working on (due to distractions from the TV, music or just because I'm mentally tired) and I have to test the game once again to see where I had stopped. This practice increased my productivity and helped me keep my sanity, and is probably something I'll always do from now on.

Well, as seen in the log, I started the week by working on the attack system, which's weird because I've done so much after that that it feels like I have done it months ago. The visual feedback is still poor, and I'm yet to balance the (strength + weapon damage - target's endurance) equation. Not quite there yet but I honestly would rather focus on other parts of the system now. Afterwards, I got to start working on the AI system, which is a list of cards with conditions and effects, which gets an unit to do something based on the conditions set by these cards; it was working beautifully until I implemented the action queue (yeah, back in January 1st), then a shitload of issues started showing up.

Due to a current limitation of Godot -- the engine I'm making this game with -- debugging is a pain in the arse since it lacks full stack traces in its editor. Yeah, that's what you've read: when you get, for example, a NullReferenceException in your code, it won't even tell you in which script it happened. I was OK with that since that, but it started to become too problematic. I had to refactor a lot of code to try and find where the problem was located. That's no joke, my code is literally full of these messages, LOL:


Part of the refactoring was done within the battle Manager class, I started getting rid of this mess (just had to expand one of these methods and BAM, my brain stopped working):


With classes, one for each state and they work beautifully well, tbf:


So, from Jan 2nd to 5th, my life was hell, I was coding for more than 12h a day and struggling to get things to work properly, but I slowly started to figure things out. Before that, I had already started to work on the AI cards and so far, I have made 4 of them, which are:

- [Effect] Move Randomly (not really useful, just for testing); Gets a random location and moves to that, then moves back previous position;

- [Effect] Chase: moves towards an enemy (if needed), and attacks it if possible;

- [Effect] Kite: attacks an enemy if possible, then moves away from it;

- [Cause] Can target (checks if the unit can target, from its position, another unit -- which can be the nearest, furthest, weakest or captain);

This first cause card made the AIs start to become more aware of their surroundings (read less stupid), as they'd just, before adding this one, chase enemies or kite them:


Well, I spent a lot of time refactoring and fixing broken stuff so I haven't got that many new things to show, but I'm happy it's coming along. I also got the walking animation and to finish, re-added the damn action queue so, this is what I've got so far:


And yeah, I'm running out of room in my console canvas. So that's it, thanks for reading, I hope to bring cool new additions next week, see ya! :D

Hello, world!

Well, that was another great week for my project and, even though I'm still stuck in the combat system, I'm slowly finishing the foundation for the battle & animations systems. Milestones of the week:


Since my focus this week was to give a better visual feedback of what was going on, I decided to start by letting the actors rotate/look at. With this, I could then add the hit rates algorithm (which's basically Accuracy - target's Athletics), with a bonus when attacking from the target's sides and an even higher if from their back.


And then a simple health bar and a decent damage popup (along with these hit animations):


At this point, I decided to do a huge refactor of my code since the classes were poorly organized; it looks like this:


I spent countless hours removing unneeded classes, moving others to where they belong and renaming what had to be renamed. It broke my project completely so I had to go back to the old version and keep this mess. So, at the moment, I'm just praying they fix it some day, while I have to keep looking at it and spending time trying to find stuff. XD

For example, I have a folder named Cyborg, where every Cyborg-related classes should be located, but I can't move the Cyborg.cs class there because it breaks everything, same for the Manager folder and its class, and there's also LOTS of classes that I won't use but I keep there to avoid any surprise. T_T

Later on, I decided to come up with a Game (Manager) class that'd load the databases (weapons, AIs and such), and replace "databases" done with scenes and nodes:


Which were ugly and messy, and made every item an object, with a proper loading/unloading when applicable.

So yeah, that's basically what I've achieved this week, getting this as result:

The AI plays till the end by itself and, even though they all have the same AI cards, the equipped weapon kind of shapes their strategy differently. So this is it, thanks for reading and see you next week, hopefully! :D