I like your approach to ANSI (ASCII?) art. There's a strong focus on simple, recognizable clusters and it avoids a lot of the granular confusion that many roguelikes can suffer from.
Thanks! I think technically it would be extended ASCII, with a few custom characters (the quarter filled circle and filled diagonal triangles being some examples)
This is probably the question every programmer rolls their eyes at but how moddable would this game be? I like WW2 games but it would be exciting to see this applied to something fictional like Maschinen Krieger.
Most of the unit data is contained in XML files, so if you wanted to mod in your own units you could. Core gameplay mechanics are hardcoded, however, although with future things like unit skills and other special abilities I'll try to make them as flexible as possible. In the end, though, it's an open source game, so one could always fork it and make a sister game with a different theme!
Thanks for the info. I'm looking forward to playing AC2. The first game was really well thought out and I think innovates more than most mainstream commercial wargames.
I liked the build so far. But like me, you've perhaps also read Tim Stone's Flare Path article which recently covered this and got disenchanted... I'm glad you're not rigid, and is going back to a single tank centric game. Though I'd imagine the first reason you left that is because of AI coding problems or something else? Will you be considering allied tanks could be commanded or would have rudimentary formation AI? Anyway, I'm curious where you'd take your return to this format :)
I think initially the difficulty of displaying unit stacks in a single hex led me to try the squadron approach. It's difficult to cram a number of ASCII depictions into a hex without things getting very jumbled. Now, however, I see that much of the appeal of the game is in the impact and detail of individual vehicles and squads. So what I'm going to try is a stacking system where the player can scroll to view individual vehicles and squads that are in the same map hex. I think the best solution for friendly units is to give them orders and then have the AI take over, that way the player still feels like they are in the position of the tank commander. If I can focus on that single core element, I hope that the rest of the game mechanics will fall into place!
Also the original ArmCom/Patton's Best also puts abstraction of unit placements and terrain into place, leaving the player's imagination to fill in the gaps. With ArmCom 2's actual terrain map, it would be a tad more difficult to approximate AI tactics when it comes to terrain - or at least more work to code. Or maybe perhaps I'm just overthinking things. Then again staying with a hex format makes it easier as compared to grid-less games. I love the ArmCom you made, its my go to game whenever my internet is down, and if I'd find an easy way to port it to my phone, I'd play it a lot.
So far it's only been a visualization problem, not an AI problem. The core trouble is that each depiction has to take up one character cell, and the hexes I'm using get filled up very quickly. ArmCom 1 used a much smaller default font and a larger grid of characters in the window, so there was more room to display units. But I like the current style a great deal (I learned to program on a C64 as a kid). Working with hexes is great - but it requires some special math, this page was crucial in helping me code: www.redblobgames.com/grids/hexagons/
I like your approach to ANSI (ASCII?) art. There's a strong focus on simple, recognizable clusters and it avoids a lot of the granular confusion that many roguelikes can suffer from.
Thanks! I think technically it would be extended ASCII, with a few custom characters (the quarter filled circle and filled diagonal triangles being some examples)
There's a good video of a TKS tankette in action here if you'd like to see how small they really are: ua-cam.com/video/2lC1G9_PeWg/v-deo.html
This is probably the question every programmer rolls their eyes at but how moddable would this game be? I like WW2 games but it would be exciting to see this applied to something fictional like Maschinen Krieger.
Most of the unit data is contained in XML files, so if you wanted to mod in your own units you could. Core gameplay mechanics are hardcoded, however, although with future things like unit skills and other special abilities I'll try to make them as flexible as possible.
In the end, though, it's an open source game, so one could always fork it and make a sister game with a different theme!
Thanks for the info. I'm looking forward to playing AC2. The first game was really well thought out and I think innovates more than most mainstream commercial wargames.
I liked the build so far. But like me, you've perhaps also read Tim Stone's Flare Path article which recently covered this and got disenchanted... I'm glad you're not rigid, and is going back to a single tank centric game. Though I'd imagine the first reason you left that is because of AI coding problems or something else?
Will you be considering allied tanks could be commanded or would have rudimentary formation AI?
Anyway, I'm curious where you'd take your return to this format :)
I think initially the difficulty of displaying unit stacks in a single hex led me to try the squadron approach. It's difficult to cram a number of ASCII depictions into a hex without things getting very jumbled. Now, however, I see that much of the appeal of the game is in the impact and detail of individual vehicles and squads. So what I'm going to try is a stacking system where the player can scroll to view individual vehicles and squads that are in the same map hex.
I think the best solution for friendly units is to give them orders and then have the AI take over, that way the player still feels like they are in the position of the tank commander. If I can focus on that single core element, I hope that the rest of the game mechanics will fall into place!
Also the original ArmCom/Patton's Best also puts abstraction of unit placements and terrain into place, leaving the player's imagination to fill in the gaps. With ArmCom 2's actual terrain map, it would be a tad more difficult to approximate AI tactics when it comes to terrain - or at least more work to code. Or maybe perhaps I'm just overthinking things.
Then again staying with a hex format makes it easier as compared to grid-less games.
I love the ArmCom you made, its my go to game whenever my internet is down, and if I'd find an easy way to port it to my phone, I'd play it a lot.
So far it's only been a visualization problem, not an AI problem. The core trouble is that each depiction has to take up one character cell, and the hexes I'm using get filled up very quickly. ArmCom 1 used a much smaller default font and a larger grid of characters in the window, so there was more room to display units. But I like the current style a great deal (I learned to program on a C64 as a kid).
Working with hexes is great - but it requires some special math, this page was crucial in helping me code: www.redblobgames.com/grids/hexagons/