He’s one of the best artists for hardsurface models that I know, that’s as AAA as it gets. In my humble opinion the main contributing factors to Hawken looking good are still money and skilled professionals.
Kitbashing may very well have been part of their production pipeline, but I don’t see any revolutionary story here, sorry.
Man this is so true. For a long time I kept embracing all of the new programming patterns and such. First OOP which I actually liked a lot because in my procedural programming I tended to follow OOD patterns and think in terms of objects just naturally even though there was no official OOD/OOP at the time (or at least I didn’t know about it). Then all of the other stuff that followed over the decades interfaces, events, dependency injection as well as things like MVC and so forth. Just so much stuff.
Each solved a problem of one kind or another while introducing others. And the problems they solved were generally something that was introduced by the previous “next big thing” patterns and such. Add a layer / pattern. Add a new layer / pattern to resolve some issues introduced in the previous layer / pattern. On and on.
I used to like it. Thinking it’s important to know and use all of these things. And they are useful in their own way. Over the past few years though I have started simplifying and relying less and less on such things. The first to go was IoC / DI. And I just continued from there.
In my current Unity project I have stripped nearly everything out dropping all the way back to simple modular procedural programming like I was using decades ago. My objects are simply containers. They have no methods in them at all.
The bulk of the code exists entirely outside of the UnityEditor. Mainly in the form of singleton Managers. These Managers handle everything initializing and updating lists of these virtual objects. On the Unity specific side I have only two GameObjects in the project that have scripts attached to them: GameManager and Configuration.
Sure things are more tightly coupled in some ways but overall everything is so much cleaner and highly simplified it makes development faster and more enjoyable in my opinion.
Probably not the degree you’re suggesting to take it to. lol
@Martin_H
Yeah it’s python, linux, cuda to use most framework at decent speed.
Though the fundamental can be programmed by anyone, it’s not complicate, I’m not a coder I can still code the basics without the matrix optimization and compilation the different framework provide. If you know how to program for gpu you will get the boost that turn training from days to hours. But really it’s just addition of affine fonctions passed down to a function (ie f[sum(wx)+b] ) over and over and over again. Then the reverse for training. You need to implement stuff like drop out and stuff but that’s not complicated. I think there is enough real coder in this thread to turn that into something that work. I barely understand matrix operation so the optimization fly above my head.
Regarding hawken, the early footage where made without the money by a small team, that was still hi quality. Indie AAA in this context don’t mean no skills. Many people argued that AAA talents going indie scale down their visual. AAA is the final quality feel in the context of this thread. You can learn the skills to that level without being in AAA team.
The point is that they made a conscious decision to get the final quality with a small team and small budget, AND THEN they use that to get a budget so that’s half the problem discussed here ie we, supposedly, don’t try to raise a budget with a good demo. Though that’s an option for a solo dev to raise fund and transition
It’s still notable they build with kitbash and avoid the situation where their method don’t fair well, to have the illusion of AAA quality to raise money. Pick your battle is the morale here.
Thing is, I’ve never really notice it matter today with game scripting. With the power even mobile GPU’s have you can be seriously sloppy and it makes no difference unless it crashes your game. We’re not talking an 80386 with a “turbo” button here (that did nothing).
Unless there’s an inherent flaw in the system (like GC Cough) then I just do what’s easy to understand that takes the least effort. The biggest issues in a well designed system has nothing to do with game code (unless you make some seriously dumb mistakes), it’s all the stuff underneath it and the graphics architecture. Where cascade shadow casters reaching long distances can reduce performance by 20X + fold… Or a highly complex shader can ruin performance…
Again most of the issues are on the technical (engine) art side, or the engine architecture not streaming / MT’ing correctly for e.g. or at all.
When you sit down and have to work with a “framework”, then you really have to think about modularisation / architecture / best practices / performance tweaking etc.
I agree. I don’t think there are really performance problems from applying all of the modern programming practices although I suppose (like anything, right?) if taken to an extreme where you have like 50 layers of abstraction to jump through for every tiny bit of code that runs or something like that it may be quite noticeable.
Mainly, I just changed my entire view of how I approach software engineering now. When I worked on my little horizontally scrolling shmup game I had all kinds of systems set up using the “proper” modern patterns. The player ship periodically sent out a notification beacon of its position, the enemies all subscribed to receive that. Every object had an interface on it such as IInteractive which provided methods to call for applying damage, collecting actions and so forth.
Sure it all worked and in some ways was a decent bit of engineering work especially for such a simple game. If I was doing that now I would just let the EnemyManager call a public method on the PlayerManager.GetPlayerPosition and be done with it. Ultra simple. And really after thinking about such things it seemed to me like most of these patterns and so forth were created to try to produce idiot-proof methodologies.
There is nothing wrong with an EnemyManager calling a public method of the PlayerManager to get the player’s current position. In fact, I would say that is just common sense. Yet the mindset of today is immediately that is wrong! That EnemyManger shouldn’t even know about the PlayerManager. There should be no direct communication going on. Abstract that away via interfaces and messaging systems. BUT… if we just use a little common sense while developing I find the problems all of these things are trying to solve are not really even problems at all.
@Steve-Tack , I think you’ve already misunderstood a few things, probably me not explaining myself too well.
There’s a strict hierarchy of control, and it starts with the input manager.
The input manager calls the weapon script, not vice versa. The input manager also calls everything else, and it was designed that way precisely to be able to easily assign control to an AI, or switch between agents (ships or whatever)
The weapon script mostly deals information down to the weapons themselves. The weapons ONLY pass information back up to the weapon component, where is it accessed by other scripts such as the target computer.
This works exactly the same way.
Same here. The weapon script exposes methods for this.
I definitely didn’t explain myself properly here. Of course, the weapon simply calls an IDamageable script or similar, and passes a damage value. The identity of the shooter can also be passed to track who is making the kills.
How the receiver responds to receiving that damage value is up to it, not the weapon or projectile.
Not the case, as I mentioned just above.
Agreed, there has to be a separation here of the weapon computer from the weapon script, because it is a requirement for a particular weapon that can’t be generalised to everything.
First of all, in my opinion the audio, particles and point lights should be assigned to the weapon, and activated/deactivated there.
The heat system and the power drain call for another interaction, through interfaces and the weapon script, with an exterior component, similar to the way the weapon computer is set up for locking type weapons.
I don’t know what exactly the emissive material is for, so I can’t really comment on it. But the UI is another thing I’ve been thinking of how to set up. At the moment, the idea is to carry the UI sprite that is used for the HUD on the weapon itself. In the space game demo in my thread, each ship carried the hologram mesh that was used on other ship cockpit projectors when it was their selected target, it seemed to be the easiest way of assigning the correct stuff during runtime with minimum fuss.
In the system I described above, each weapon has an activation and deactivation method which is called when it becomes selected on a particular weapon station. That can include animations, sounds and whatever else you’d like to happen when it comes into use.
So far, it is mostly exactly how I had it going when I wrote it custom for the space combat game. I think it’s about as intuitive as it can be. There’s a strict hierarchy, with as much decoupling as possible, but not to a tedious extent.
An important point is that the weapons themselves only ever pass up information one level, to the Weapon script, from which it is accessed by other entities. So if you need to add a new outside interaction for some new weapon, you simply create a new interface for it and create a couple of methods in the Weapon script for whatever interaction takes place - and this interaction is never direct, it is referenced by indexes that are assigned by that Weapon script to each of the weapons so that the weapons themselves never upset the clear hierarchy. This sort of thing makes it very easy to understand where the interactions occur.
Anyway, I can see I really didn’t explain myself too well, sorry about that! I’m going to finish the first draft of it in a day or two and I’d be happy if you’d run it in a test scene in your game and let me know how you find it
The thing is, most of what the weapon does is only relevant to itself and the entity that it damages, and does not need to be passed up the hierarchy. You didn’t post an example of what exactly ‘too little’ means. @Steve-Tack gave some examples, such as power drain, heat generation, UI images and audio, but some of these can be generalised. E.g. power drain is just a value, it works the same way as a WWII combat game where you ‘drain’ 3 of your 9mm bullets every time you squeeze the trigger. So that is something I will have to add, and it is rather generic. Same for UI, most games have a visual cue to tell you which weapon you have selected. So this is generalisable as well. And you don’t have to call these methods or use them if you don’t want to.
The example you gave here, of my weapon computer, shows just how well the system works, because in fact even if I was writing custom code it would have worked in exactly the same way. So to me it shows that the way it is built allows specific code to be added with high efficiency.
And it’s not really that specific anyway. Locking weapons is a relatively generic feature of a lot of games, it’s hardly uncommon.
Do they? My system covers most of the kinds of games I can think of. It doesn’t so much force you to adhere to some random protocol, as it encourages you to simply separate stuff that can be separated, and to avoid linking stuff randomly all over the game. And it provides a clear way of adding uncommon interactions: basically add a new interface and some methods in the Weapon script.
Of course, the thing won’t be 100% generalisable, so like any good system there’s a clear way to add interactions efficiently and cleanly.
The traditional (and sometimes equally meaningless) definition of an indie film is that it was made outside of the major movie studios. An indie band hasn’t been signed to a major label. Technically the Star Wars prequels are “indie” films.
Presumably an indie game is one that isn’t published by a major game publisher. Which is a pretty iffy definition in the world of self-publishing.
A lot of the films they show at the Sundance film festival have healthy budgets and may even star recognizable actors. They do have a special category for the “indie spirit”, which does feature actual low budget movies.
I think whenever we’re talking about low budget versus high budget, we should just say that.
I does sound like we’re more or less on the same page. Kind of sounded like the opposite in several cases for whatever reason.
Maybe I’m just used to certain terminology, but to me an “input manager” implies getting input from devices that humans are operating.
As long as there’s a way to pass arbitrary data with the damage, it should work. For instance, in my weapon damage data I’ve got: damage value, damage type, fire type (beam or projectile), inventory item ID, the hit location (for “hit” particle location), and whether or not the damage was player sourced.
Yes, that is sort of how I’ve got it. Many of the specific visual and audio elements are at the lowest level with the weapon barrel itself. In the case of point lights, I’m animating the intensity of them at the source and hit location in sync with animating a pulsing effect of the beam weapons. My concern was that trying to hook into all of those sorts of interactions in a generic way could take a lot of extra plumbing. One thing I forgot to add was having the gamepad rumble with the weapons when certain ones are fired.
In my game, the currently active weapon barrels have areas that can “light up” in a certain color to visually emphasize the type of damage it does. I light those areas up by changing the emissive weight in the Alloy material/shader. Somewhere the code needs to do something like “_alloyWeaponMaterial.SetFloat(”_EmissionWeight", emissionWeight);"
If you made a generic system too generic, I guess I was picturing having every little thing like that needing to subscribe to events or override delegates or implement an interface or whatever.
Well, just to be clear, my weapon system is already 100% complete and I like it. The talk about how a generic weapon system would have fit into my game I thought might be interesting, since I’ve already dealt with a lot of nitty-gritty details. For the record, my interest in pulling in outside code is mostly limited to harder stuff like having AI ships navigate asteroid fields. So, 3D obstacle avoidance, AI behaviors, and maybe even some of that PID controller stuff is the interesting stuff at this point.
As nobody seemed to like my last one, let me just spell it out. You are here (vector), asteroid is there (vector) if you are within certain distance of object (check from array) then start rotating (move in direction of quaternion trajectory) either left or right until X distance away (if getting closer instead of away then up the turnspeed var), then continue to follow or use navmesh course.
Sure, you can build on it… You might want some ships to crash if they hit smaller asteroids etc. which is a tiny bit more complicated I suppose?
Although gotta tell me if I’m missing here because I’ve done examples like this more times than I count and it’s never hard, it’s more difficult to do a basic character interaction. Which also has to calculate the distance between two objects, stop navmesh if within distance then you have to have the camera move to face of the char whilst they use IK to move on a clamp value (for the head) whist the body slowly rotates matching the body rotation without it looking weird / un-natural (if you want to look supp’s pro, using blend state anims) and then having the UI pop in and out for dialgoue then finally of course continue.
Yeah like one or two steps missing, but it’s all kind of self explanatory.
Still not exactly complicated, then for a typical AAA openworld RPG… You’ll have a TOD var, which a char / AI profile is assigned to that tells them where they need to be at specific times and what actions they need to perform. Like walk to nearest bed on tag, then play animation / sleep. Or check if another player is in chair, is music playing? Yes… Then act like a tool for a minute then return to chair or stand there looking silly…
There’s only a few types of AI I’ve ever found remotely interesting and one example is autonomous randomisation for NPC’s, firstly it’s very rare (hardly ever see it in AAA games). I tried to randomise the outcome of what would happen dependant on mood / location / state (drunk for e.g.) / level / armour / wep types / factions / jobs / dialogue answer choices based of a random flow state BTFST. So if the player looked too tough they wouldn’t have a go, some wanted your money, some belonged to factions that were sort of neutral and it was any guess what would happen. Catch them in a bad mood after a hard day scavenging, it might be end game.
Kind of like a modern day interactive Baldur’s gate, that was interesting. Apart from that, there’s just lots of “stuff”…
P.S if you’re working on a large game, you just got to get into the habit of using a base and then instancing profiles. Which pretty much means, set up what you need then apply to new object / change the drop down menu’s to select different behaviour model / locations for that character.
Fewwww … you are in super over simplification here.
You can’t just stop navmesh, you got to tweak manually and perhaps code your own deceleration movemement when character is near the target point to have it look natural almost, because Unity navmesh is very rought.
Also Unity doesn’t have any local characters avoidance, they just collides ones with others trying to reach the same target point, again you’ll have to code some good local avoidance using raycast and movement prediction.
You can extend that work to all other areas to get some idea of the amount of work.(animations, UI, cut scenes …) , this is what will make your game looking high quality and pro instead of average and very amateur.
There is no magic or ready to go solution or framework or make my game framework button, but once again if you target higher quality this means as always, and it will always be two words : ‘hard work’
Machine learning has been about to revolutionize production for 20 years! It’s still a long way from actually being a useful tool. If you read the ‘Shakespeare’ example in the last video, none of it makes sense. Even if it were at a stage where it could generate coherent 3d content, assembling the materials needed to train it would be extremely difficult for anyone other than a very large studio.
One day, certainly. But not today.
It does have local avoidance (?). If you pass a bunch of guys the destination there may be problems, but they’ll try to avoid each other on the way there.
My point is that having a generalized system for ‘ammo’ is that this entire feature is an example of ‘too little’. Tracking ammo and preventing firing is something that is in itself a trivial case. Having a generalized system to support this is almost overkill by definition. Like, by having to even mention this as a thing it’s almost being over complicated.
Although honestly, I guess it depends on your audience. I think most programmers would shy away from using 3rd party code for anything as core to game play as their weapon systems. But judging from the positive reviews I’ve seen on terrible code, only a small fraction of the people who buy asset store products are professional grade programmers.
Nobody was talking about cutscenes etc. a lot of what you said is irrelevant to what I said, might be worth reading it properly. Yes Unity Navmesh is a bit dumb, but again not hard to rectify or build your own solution if you’re not happy with it. I’m from a time where this wasn’t handed to you on a plate and can actually make my own solutions if necessary.
It’s not hard if you know how, just like everything. Tedious? Sometimes. Nobody said there was a “magic” game making button. That’s the advantage of experience, what would take you a week would take me a few hours.
@Steve-Tack , no problem, I didn’t mean put it in your game just yet just make a test scene if possible. Anyway pm me if you’re ever interested.
Yeah the weapon passes a damage value and a hitpoint of course, since the bullets are usually hitscan and I need to know where to do effects like light up the shield in the shader, or apply force values in explosions. It also passes the identity of the shooter at the moment, and the IDamageable of the target stores the identity of the last attacker so that when it blows up it can call the game controller to update the score.
@frosted about a generalized system for ammo, a weapon almost by definition has ammo:
If it’s just a punch, the ‘ammo’ can be your strength, that gets replenished over time by your metabolism, gets drained by other activities such as running, or doesn’t get replenished until you come across a cache of food.
For a space game, the ‘ammo’ can be the weapon energy, that gets replenished over time by your power source, is drained by other activities such as engines/turbo, or doesn’t get replenished until you come across a powerpack.
For an fps game, the ammo can be 9mm bullets, that don’t get replenished over time by anything, get drained by other activities such as shooting other weapons, and don’t get replenished until you come across a box of ammo in a cabinet.
In three totally different games, the weapon/ammo thing works almost exactly the same way - and in the fps, replenishment over time is simply not used/set to zero.
There are always games that do something totally out of the ordinary and make a success of it, but 99% of the time it’s surprising how consistent the mechanics of something like a weapons system are, because it’s simply a logical set of interactions that players enjoy and are comfortable with.
And it might just be me, but it’s a huge relief to my brain to work with a ‘generic’ system, because when I’m thinking about interactions that are generic, they are identifiable as such, I’m not being distracted by peripheral code that hints at specific characteristic. In other words, my brain can shut off everything outside the system and work only within it. This is probably the most important coding aspect of modular code IMO.
I wasn’t saying that many games don’t have ammo, I’m saying that the feature itself falls into the “easy part” - ammo really falls into the ‘trivial’ category. Ammo is like the first thing a non programmer does when they try to learn to code with unity - they make a gun shoot spheres and decrements an ammo counter. I’ve literally seen this be the starting example for like 2 different noobs who had no idea what their code did… the only thing they understood was the ammo counter.
This can easily turn into an endless argument with neither of us really getting anything out of it. Every system has similarity to almost every other system, but generalized tools rarely actually deliver value.
Anyway, let’s not get into a protracted argument that benefits neither of us. If you ever try to use your weapon system in a medieval rpg, you’ll almost certainly find that its counter productive. But … your system will never be used for a medieval rpg so it doesn’t really matter, does it?
You didn’t understood the point.
By local avoidance i meaned AI able to plan some alternative path some meters before colliding with others dynamic characters already in front of the target blocking the way for the others…
For example AI agents able to group together around the target as a small or big circle.
I meaned advanced dynamic characters avoidance and grouping, that looks better and natural, instead of having all characters colliding with each other unable to organise space as a group.In some way this is becoming already advanced AI system, something not present within Unity.
The topic was meaning you’ll have to add lot of code on top of Unity API if your goal is a polished game or having advanced not common features.
Anyway we are just discussing, i would prefer the thread to become concrete , with real prototyping subjects showcased by pictures or videos.
I’m not quite sure I understand what you’re saying. Are you saying that ammo is not the area which will break a generalised system, that it’s trivial to implement and that it will be some other thing that causes problems?
The example you gave is overly simplistic, it’s like saying that a movement system is trivial because all you have to do is translate a gameobject. I don’t see what it has to do with anything.
The thing is, the architecture of the system gets more complicated when you have to interact with the ammo system in a lot of different ways, such as retrieving ammo in-game and from a shop, sharing ammo between players, using ammo in different ways (i.e. energy in a power system can be used for weapons, engines and shields), interacting with an inventory system and UI.
The question is whether the whole architecture of it can be generalised.
I don’t understand. Generalised systems deliver value, they just usually deliver more value than you need. It’s a question of how easy it is to get it to do what you need to do.
If I make something that I think is easy enough to work with for a medieval rpg - and so far I have no reason to think it won’t happen - I’ll put it on the store as a generalised system, and I’ll find out soon enough what all the rpg makers think of it. My guess is there won’t be any problem whatsoever, because just because something is medieval doesn’t mean the architecture of the weapon system works differently in any essential way.
just make a test scene if possible. Anyway pm me if you’re ever interested.