Isn't shootergame a bit old school?

[zoombapup]

Ok hear me out here.

I'm looking at the code for shooter game and man its pretty unwieldy in terms of structure. I mean it uses C++ code to setup to render a UI? The player and weapon interfaces are kind of nasty too.

I'm just wondering how other people feel about the structure of the code?

My own plan currently is to think about maybe shifting some of the code into reusable components and use events to sync the various parts. I'm a big fan of component based interfaces because otherwise you get exactly this kind of monolithic mess of inheritance issues that shootergame screams at me

Or maybe I'm being harsh here? Does shootergame seem elegant to anyone else? If so, can you elucidate why?

One other aspect that really is chafing me right now, is when I patched in third person support into shootergame. It was an easy enough process, but it showed that having some actual in-editor editable state machine would be a real plus for UE4. That way things like weapon state handling and game flow handling could be handled a bit more visually. So for instance first/third person would be a state machine state each, with on/off or enable/disable component interfaces for the various bits (which mesh is showing under which circumstance etc).

I dunno, I guess I'm just hyper critical of this kind of thing these days.

Anyway, wanted to gripe a bit, sorry for that! Happy Christmas all!

[Rama]

" I mean it uses C++ code to setup to render a UI?"

I am not sure about the rest of what you mentioned, but the ShooterGame UI is being transitioned to UMG right now!

At least that's the last I heard

So you have that to look forward to!



Rama

[zoombapup]

You know Rama, I was SURE I saw somewhere on one of the twitch streams a screenshot or something of Shootergame with a 3D in-game UI for weapon selection or something. I was beginning to wonder if it was just my imagination, because I've heard nothing about it. But it sounds like I might not have been dreaming after all

Wonder when that particular Gem will come out?

Honestly though, the codebase for shootergame is impossible to follow for inexperienced programmers because it feels like the functionality is all over. Personally I think thats in part because it uses the old school inheritance method of making things (so for instance every weapon inherits from a AShooterWeapon, which is fine until you need a really specialized weapon, in which case how do you split the unique functionality out? Its the main reason I got out of doing inheritance-based architectures many years back (when we were working on worms, we had HUNDREDS of unique weapons to create, so the inheritance model really chafed).

[iniside]

I'm not sure if build in state machine is an answer. I mean creating one is not a big deal, and generalized solution wouldn't fit anyone needs. So IMO it's better to copy paste some code around and have small specialized solutions, than design overcomplicated general system which serve no purpose beyond existing (;

And I agree, ShooterGame fallow some patterns from previous UT game, where it relayed overly on inheritance.
Inheritance alone is really overrated for game development, where you often need objects, which share some functionality, but are different in some minor aspects, and those minor aspects are really important.
It's best to use both. You just should keep you inheritance tree as short as possible, without cluttering to many functionality into root.

[zoombapup]

I disagree with you there Iniside, I've used a state machine internally for loads of code and having a generalised editable solution for the state machine setup was massively more productive because you could do decent debugging for when states transition etc. Its pretty much the reason why things like behavior trees work out alright for AI, not because of some underlying magic, but because they make sense and are debuggable by humans in a trivial manner.

For instance, a state machine would work well for the UI state. It would work for the weapon internal state (firing, reload etc), it would work well for the player state (first/third person etc). My point is that having THOSE parts as an easily editable, easily debuggable component would be very useful, to me at least.

Not sure why you think a generalized state machine component wouldn't be a good solution actually. Given I've used one successfully in the past with another codebase, have you got any specific objections? Bearing in mind that previous Unreal Engine codebases relied pretty heavily on a built in state machine type in the scripting language (I only read about it in passing, didn't actually use it).