The thing that might not like it is the GCC compiler for AVR. If it doesn't then tells us how it expresses this view?

Sorry, you are correct of course. GCC doesn't like it, but it throws about 57 errors that all point in all sorts of directions leading me to believe that what I had done was REALLY not sensible, hence me glossing over that bit!

Thank you - I was hoping I wouldn't have to go that route as it means changing a lot of code elsewhere. Since there's only ever going to be 1 inventory (the player's) I might just cheat and make it a separate variable from the 'mob' stuff. It's not as tidy but it'll probably save me work. I'm really scraping the bottom of the flash memory barrel now so I'm trying to be as efficient as I can :(

Take a look at unions. The common pieces can be members of the structure, with unique items in the union. The drawback is the union's size will be the size of the largest union member. Something like this:

As seen the syntax is much easier to work with - not relying of clunky language extensions and

struct tactic : mob_type

is where the derivation actually happens.

Oh and nothing says you have to use any other feature of C++. Just put the code in a .cpp rather than .c and it will be passed to the C++ not the C compiler. Be warned that C++ is much more picky about assignments between differing types so it may call you out on such things (which is actually another "good thing" in fact)

Thank you, I like the neatness of this solution. I figured it would be fairly straightforward in C++ but was avoiding using it because I don't even like using C, except that I'm almost starting to enjoy the simplicity of it working on this project and I didn't want to fall into a rabbit hole of learning another language poorly before I've even developed a single useful thing. I keep wishing there was a single language I could use for everything - little desktop apps, websites and electronics gizmos. But it's probably C or C++ (well, actually it's javascript, but I don't want to start getting offensive) and I've wasted the last 5 years or so getting half decent with something else :D

a single language I could use for everything - little desktop apps, websites and electronics gizmos

Personally I think C++ and Python together cover pretty much everything you might want to do. Remember that when it comes to the "electronics gizmos" you can just write in the C subset of C++ if that's what floats your boat. But there's some of the simpler features of C++ that make it look attractive even in a limited resource environment (also there's a lot of FUD about C++ being "resource hungry" that simply is not true anyway). Talking of some of the nice things that C++ might bring (apart from what I showed in #7). Just consider for a moment what's going on in something like Arduino's Serial.println(). That shows the use of methods in classes and also function overloading (it can take char, int, float, string, etc and print any of them). But you don't have to use this stuff if you don't want.

when it comes to the "electronics gizmos" you can just write in the C subset of C++ if that's what floats your boat. But there's some of the simpler features of C++ that make it look attractive even in a limited resource environment.

I think I'm coming around to this - my main programming education started with Java at university, and whilst I never got on with the language itself, its object oriented nature stuck with me and settled nicely into Python later. I've always been wary of C++ because I'd been given the impression that its 'OOness' was just an ugly bolt-on to C and it's a bit 'unfashionable' what with all the new shiny languages that keep coming out. But if you take the time to think about it - there must be a reason it's still around and well used.

This little project I'm working on is supposed to be more about learning the hardware side of things/designing PCBs and things like that, but I ended up getting really over ambitious with the software. My intention is to write some different games for it in time, so I will definitely look at porting some of the more obvious bits of it to C++. There seems little point in trying so hard to force C to do things that C++ was designed to do in the first place!

Indeed - I've got a box full of BBC Micro:bits sat on my desk that can all run Python (and JavaScript!). I'm stuck at a point of knowing just enough to be dangerous when it comes to electronics. I've had the idea for a miniature gaming device in my head for ages - I know there's loads of these sorts of things around, but I wanted to make my own. I also had a few bare ATTiny85 chips laying around and I liked the idea of pushing one as far as I could. I think I've done quite well so far. Now I'm getting frustrated because I've done so much with it, but can't really take it any further - I want to implement random map generation, a magic system, DIALOGUE! but I've hit the end of what I can reasonably do with 8K Flash and 512B RAM (although I wonder how feasible it would be to load stuff off an SD card or similar, not enough pins!).

I looked into moving to an ARM based chip, with the hope I could use micro python on it eventually, but that opens up a whole new set of problems with soldering tiny parts and not having the right programming hardware. I can buy a development board for one, but then I've gone backwards because I don't have a neat little PCB that I designed.

I also bought some ATTiny1614s which have a lot more SRAM and double the flash - I even did a pretty good job of soldering it onto a little breakout board so I can breadboard with it. But I didn't realise at the time that the 1-series tinies aren't really tinies, they're xmega and I don't know how to program them with my set up, so that's a whole other rabbit hole to chase down!

Actually, my very first attempt was Python running on a raspberry pi zero which I was intending to solder back-to-back to a custom board - https://twitter.com/Pi0CKET, but that didn't end (start) well!

I'm getting there, and I'm really grateful for the help I've received here. I quite often try to run before I can walk with things like this and some early successes might have made things look easier than they really were!

that the 1-series tinies aren't really tinies, they're xmega and I don't know how to program them with my set up

If you want something "familiar" with a lot of resources consider mega1284. Sure it's got 40 pins (so perhaps 30+ more than you really want) but the point is that it has more RAM than any other Mega AVR at 16K (and 128K flash is pretty healthy too). If you can get the solution into fewer resources you can then scale back through 644, 324 to 164.