IsoRTS is an RTS game

It is using a custom isometric game engine written in C++ using the Simple and Fast Multimedia Library. The aim of the project is to build a game heavily inspired by ‘Age of Empires’ and ‘Starcraft’. Its aim is to be a classic RTS. An underrated genre in my opinion. All the assets are drawn and animated in Aseprite. The goal of the project is to be a fun and challenging learning experience for myself. I also made a couple of vlog style videos to document the development.

See project page: https://www.gamedev.net/manage/projects/2653/

Just been very busy at the moment (for the last year in fact), I work in the ICU and had a kid. I hope after COVID I can get back to codeing in my free time.

I did manage to get some development in during some downtime!

There is a new release! https://github.com/switchboy/IsoRTS/releases/tag/Bugfixes​​

Release notes:

Bugfixes:
- Added rate of fire & attack order fix
- Villager actual spawn location is now checked on availability before spawning
- Building footprint now shows occupied on other buildings objects and units
- Buildings can no longer be build on tiles occupied by units
- Villager failing to drop off recources while the adjacent tile was a drop off point and the villager was boxed in by other units or objects
- Removed the 'feature' to build buildings on water tiles
- Only villagers display resources in taskbar

Gameplay change
- The closest food source might now be beyond the initial fog of war
- Added resources carried to actor toolbar

I looked at your code a bit, and have some code refactoring suggestions.

You have fooX, fooY pairs at many places. Likely you use them together everywhere, so bundle them in a structure, or use your “cords” structure for this.

You seem to have gold, wood, stone, and food as resource in an actor (confusingly called “actors”), and each of them seems to have mostly the same structure and data. Is making a Resource class, and bundling the data per resources a feasible idea?

With respect to “actors”, I systematically use plural form (eg actors) for containers, and singular form (eg actor) for single instances. In that way you can always see by the name of the variable whether you have one thing or many things, and foreach loops become naturally "for (Thing thing: things) { … }"

Alberth said:

I looked at your code a bit, and have some code refactoring suggestions.

You have fooX, fooY pairs at many places. Likely you use them together everywhere, so bundle them in a structure, or use your “cords” structure for this.

You seem to have gold, wood, stone, and food as resource in an actor (confusingly called “actors”), and each of them seems to have mostly the same structure and data. Is making a Resource class, and bundling the data per resources a feasible idea?

With respect to “actors”, I systematically use plural form (eg actors) for containers, and singular form (eg actor) for single instances. In that way you can always see by the name of the variable whether you have one thing or many things, and foreach loops become naturally "for (Thing thing: things) { … }"

Good idea when I have the time I will definitly make my X-Y struct usage more consistent. The problem is since I don't have a lot of time most solutions are prototypes made te work with the rest of the game. This has made te code look like it is being held together with ducktape and shoestrings. A restructering and some harmonisation will probably go a long way to make furter development easier. That being said the temptation to add new features rather doing refactoring is very strong.

I am not a native english speaker. The actor(s) class contains data for all the different units (actors). However every function is only specific to manipulate a single selected actor. Hence not using the plural everywhere.

I had some free time lately so I've refactored my pathfiding and villager AI:

Added features:

• Minimap move commands are now available
• Actors now walk in the general direction of a command even though they might not be able to reach their goal
• When gathering or building actors only move if the can in fact reach their goal
• Reworked villager AI somewhat
• Dropoff points now allocate a drop of tile (preferably the closest) to an actor in need which should eliviate congestion
• if a resource becomes unreachable for a while vilager will instead start to gather from the closest similair resource

Bugs fixed

• Missing animation when a building is finished
• Villagers stop and become immovable and stop being able to do anything when pathfinding does not find a solution
• Wrong alignment and orientation when playing building animation
• Sped up things a bit by converting more vvarables passed by functions to references

Get the release @ https://github.com/switchboy/IsoRTS/releases/tag/betterpath

Got some more programming and asset creating done!

I present you the mining camp!

Change log since last update:

• added the ability to place a mining camp
• villagers can use the mining camp to drop off stone
• villagers can use the mining camp to drop off gold
• Units of other teams no longer get selected in box selection
• Duplicate units are removed for selection list
• only draw command cursor after successful command
• Selection function going out of bounds fixed
• Changed to a rectangle selection box
• some code cleanup
• Villagers are no
• w checked for being at an adjacent tile before commencing resource gathering

You can grab a built here:
https://github.com/switchboy/IsoRTS/releases/tag/mining

Made some nice progress the last couple of months: