Remove ads

Guessy Makes Videogames

Further update: I am approaching the point of playable prototyping!

Since my last update...
  • Aimed jumping for the player character. By holding down the jump key, the player can aim their jump (quite literally, you have a little target destination you move around) and on release, you jump straight to it. Some very precise jumps are possible with this. Jumps are extremely powerful here, partly because you need them just to get good angles on the giant bosses, partly as a 'safety net' in the event the procedural arena (when we have procedural arenas) spits out something absurd.
  • Moving platform support for the player. This one was a tricksy bastard to implement, and still has some issues (you will in fact phase through objects whilst standing on a platform), but the gist of it is that, given an arbitrarily moving platform, the player will move with it if they stand on it, and won't have any weird phantom forces slide them off of it. They don't actually rotate with it currently which I will get around to at some point but the functionality is there.
    • Sadly, despite being set to allow it, jumping and standing on the Bosses themselves is still unreliable; you typically just fall straight off as soon as they move. Bosses move quick and have odd shapes, so they're a bit much for the system to handle properly (technical specifics: if the platforms move too far in a single frame the player will not be able to detect them again when it checks what they're standing on, and they go to the 'falling' state instead). I think I'll build in a special case for landing on bosses, wherein you stick in place but can't move; you'll fall off naturally after a few seconds, or can jump away early; it's mainly intended for melee characters to jump in, hit a target, jump out, with the aid of the lockon system.
  • The boss can attack you now! The player can't fight back because their control scheme is still half finished, and everyone is immortal because I haven't implemented death yet, but the bosses now have two attack animations for their limbs; a stomp and a sweep. This required setting up a number of subsystems:
    • There's a custom attack handler now, which lets me modulate how much the boss telegraphs and how fast its attacks are based on difficulty. For debug purposes the 'strike triggers' (the collision volumes the attacks use to fit hitboxes to affect) are currently visible in red. I've also separated the attacks into different assets from the limbs themselves; I want bosses to have a subset of possible attacks rather than all their possible attacks, which again varies with difficulty; harder bosses have more attacks to watch out for, and they'll come more quickly too.
    • Obviously, hitboxes and hit detection were required for this to work; that's in too. It's not actually as simple as you might think it is; an attack is typically 'seeking' things to hit over multiple frames, and you don't want to hit the same target every frame the hitboxes are in contact. You also typically have multiple hitboxes connected to the same 'health' component, and again you don't want multiple strikes against the same health because the target has multiple hitboxes (for instance, the player only has the one health bar, but 8 hitboxes that feed strikes to it; two for each arm, two for each leg, their torso and their head). Finally, you typically don't want melee attacks to be able to hit the person performing them, which also needs to be built into the system.
    • A very basic Utility AI that doesn't actually make choices yet; it just picks randomly from the available set of actions. The AI picks an action, moves the Boss towards the player until the player is in the action's 'valid target zone', and the action is performed. This required some amusing reworking when the Boss would promptly start trying to charge you to attack with it's back legs. There is now a distinction between parts that can give 'Planned' attacks and parts that only give 'Opportunistic' attacks; Planned attacks allow the boss to move to target, Opportunistic attacks can only be chosen if the player happens to be in their valid target zone at the time; think of how many bosses in Dark Souls have attacks they only use if they player is in a certain location (ie underneath or behind them); they never chase the player down to specifically do those actions, but will pick them if the player happens to be in their target zone when it comes to their next decision. In our case, the boss will only stomp/swipe at you with its back legs if you are behind it.
There's still a lot of work to be done; the boss animation needs some tightening up, it could do with more parts and themes (at current, it's always the same boss because there's like 3 parts total to pick from), currently the boss attacks always track perfectly for the entire animation because I haven't set up keys for turning that on/off yet and so on.

I think the major task though is getting to a playable alpha state, in which you and the boss fight and there is a proper gameplay loop should one of you die. So with boss attacks in play, it's time to finish up the player's control scheme to let them fight back. Ideally, I'm hoping to have this milestone reached some time in January. Wish me luck!
 
Last edited:
A script state machine sounds like something Unity should have, for enemies AI and such.

Also, unless the enemy (or player) happens to be astronomically lucky, if you implement invulnerability after each hit your multiple hitbox problem goes away. It is kinda cheap, but it may work.
 
bird_poison said:
A script state machine sounds like something Unity should have, for enemies AI and such.
Click to expand...
Click to shrink...

It does, actually; Mechanim is a state machine primarily intended for animation, but it can be used for AI as well. It's main problem from my perspective though is that you cannot construct the trees at runtime, nor can you nest them in any way, unless you start diving into the Playables API. Former's a bugger for procedural content for obvious reasons and the latter isn't the simplest thing in the world. Since it's primarily meant for animation, it also handles transitions over multiple frames, so you can wind up in a situation where a Mechanim-controlled AI is temporarily trying to do two things at once during the transition if you don't manually go in and fiddle every transition to be instantaneous.

I personally just don't like using it much; good tool for controlling small state machines, but tends to fall apart and get harder to maintain the more stuff you add, and its really bad at being modular.

bird_poison said:
Also, unless the enemy (or player) happens to be astronomically lucky, if you implement invulnerability after each hit your multiple hitbox problem goes away. It is kinda cheap, but it may work.
Click to expand...
Click to shrink...

Oh I already have that solved anyway, I was just pointing it out as something to bear in mind when developing these systems.

In my case, a given attack animation has a 'damage window' of sorts; whilst the window is open, it looks for hitboxes, to in turn find the Health components they're connected to to apply damage. I simply record when Healths have already been 'struck' during the damage window and ignore them if they crop up again. After the damage window closes, I clear the record and we're good for the next attack.

This actually has its own amusing set of potential quirks and glitches; LoZ: Ocarina of Time's Infinite Sword Glitch for example uses something like this damage window system (though they use the 'timed invulnerability' thing you mentioned); when your sword/weapon glows during an attack animation, it means its window is open. The glitch part comes in when something happens to interrupt the animation, like being hit in the middle of the damage window, or interacting with something with perfect timing. Since opening/closing the window are events on the attack animation's timeline, and the animation never finished, the event to close the window afterwards is never sent and the window is left open, meaning you can hurt enemies by walking straight into them.

In my case, I added extra 'close window' events to fire whenever the attack animation is exited (for any reason), just as insurance.

And the enemy attacks actually do hit a lot of hitboxes at once, most of the time; a side effect of the boss being huge and the player (and their hitboxes) being small. It's actually a bit of a problem; I set up the head hitbox to double incoming damage... only you pretty much always get hit in the head anyway (especially by the stomp attack :V), so I wound up removing the damage modifier.
 
> Thread has the 'old thread' warning on it
> Q_Q i am sorry

'Still alive' update (again); I didn't do a whole lot over the hols and I have another new project I am actually being paid for, so progress has slipped a bit.

Most of what I've been doing since last update is behind the scenes and AI work; the boss AI will now correctly orientate itself to perform certain attacks, and can abort what it was currently planning to do in favour of a more opportune activity. All boss activities have some form of 'target volume' - typically a cone - that it needs the player/target to be inside before it can perform it, and it will chase you down for the purpose of getting you inside that volume (a mistake in how the boss needs to turn to do that is what caused the BOSS CAROUSEL glitch I gif'd above). It is also now capable of abandoning the activity it was trying to manoeuvre for in favour of a different one should circumstances change; to give an example, the Boss will normally be chasing you to attack with its front legs, but if it you get behind it it will abandon that to attack you with its back legs instead, and it will seek alternative activities if you get too far away (...it doesn't have any right now, but basically the support is there for swapping to ranged attacks when the player is too far).

The other thing is a structural re-wiring of the player pawn due to a mix of unforeseen problems, spaghetti code and difficulties in expanding it that required parts of the system be torn up and redesigned.

The lesson I've learned is that there are actually three state machines involved in a third-person character: The Pawn, The Controller and The Animation; Pawn State controls how the pawn moves / what it is currently doing, Controller state controls the current control scheme which needs to change to remain appropriate to what the Pawn is doing and Animation, which needs to work with Unity's animation system to visually communicate what the Pawn is doing back to the player. Keeping these three machines in synch to the point they are effectively 'one' state machine - despite the Controller being a completely separate object - is the structural challenge here.

Previously I hadn't really cottoned on to this design aspect, and the code had been spaghetti; now this is properly designed for and kept in synch. Each Pawn State (which is a component) controls its animation state (tying Animation State to Pawn State completely), and there is a synch graph that keeps the appropriate Controller state mapped to the appropriate Pawn state; so you use standard controls when running around (the 'Ground' state for the Pawn), but we change controls when we enter the 'Aim Jump' state (ie to display the jump target UI and so on).
This took a bit of shenanigans and headaches to all sort out, work out, implement and tidy up, but it's in there now and adding new Pawn states - in this instance, one for being attached to the Boss - is much simpler.

The previous handling for moving platforms was buggy, and I'm having another crack at trying to resolve it, though it is not a simple task by any means; its kind of necessary just for allowing the player on the bosses as much as anything else.

As stated previously, the current goal is still to get player attacks in place and functional so we have a basic playable alpha. Currently, I'm working on letting the player jump onto a boss (so they can perform a melee attack and jump back). We'll also need some sort of lockon system, which I've talked about before, but will discuss once I'm actually implementing it (I have a number of ideas/options and the plan is essentially 'try them all, see what works best').

So yeah, visually there's no real changes beyond the Boss having a semi-competent AI that won't stand blankly around waiting for you to kindly walk into it's current Activity's valid target volume. But now there should actually be progress again.
 
Last edited:
Progress still continues!

Moving platform handling... turned out to be hilariously less complex than previously assumed and was solved about three days after the previous post. The lockon system took like a single day. C'est la coding.

Whilst the reorganisation of the player state machine(s) was useful, it wound up also being slightly crippling, as trying to enforce synch required such things like 'aiming the jump requires an additional ground logic state' and so on and aaaa it was a mess. Things have been simplified; there are mechanisms to keep the various state machines (mainly the pawn/controller ones) in synch should the pawn state suddenly change, but they can diverge if necessary (ie the controller can slip off into the 'aim jump' state without forcing the pawn to state change as well).

Animation code for the player has also been greatly simplified; long story short I've had to toss out the entire system that relied on Unity's Playables API... because it's an experimental API, hilariously bug prone and constantly kept shifting with every update (tldr I jumped to Unity 5.5 and all the player animations started completely glitching out). So we're back to a single monolith mechanim statemachine with overrides... which is actually a whole lot easier to debug and maintain. I have like, ten animations at the moment lol. 'I want to go to this animation right now', for attacks etc, isn't even that hard to set up with Animator.Crossfade, and I get the advantage of layers.

Quaternion springs turned out to be broken (again), so I had to bash my head on a rock for a week until they were unbroken (again). Involved fun bugs like 'if I run around the boss fast enough, the springs screw up and roll it over beneath the ground. Betting pool on how long they take to break again now open. They seem to be stable now... seem to be. Will make more goat sacrifices to the kraken later.

Spent a while setting up a system by which you can jump onto the bosses, but wound up scrapping it in the end. Long story short, the bosses are at that awkward sweetspot between 'too large to just walk up and beat them with a stick' and 'too small to go full Shadow of the Colossus'; the limbs in particular move so quickly the player is typically thrown right off anyway. And having a special hanging state whilst attached to bosses resulted in 'fun' bugs like trying and failing to move the player to the relative position and sending them jerking around through space at lightspeed, or falling through the floor, or just... it was pretty terrible okay. The whole thing only worked if the bosses would obligingly stand still. All was not completely useless at least; I have aimed jumps that work with the lockon system now, so whilst you won't land on the bosses, you can still make jump attacks at them and expect them to land where you want them to (the trajectory will actually adjust in mid-air). Boss geometry still collides, but no-longer counts in the 'am I standing on the ground?' checks; you just slide off instead.

A system for the player to 'equip' weapons and have the weapons change their animations is in place. By default they have a 'fist' "weapon", but can also equip a sword that changes their idle pose. Currently working on a system to wire up inputs to performing certain actions, specified by the weapons themselves. Once I have that nailed down (and, y'know, some actual attack animations thrown together), actually damaging the bosses shouldn't be too far off. Won't say 'end of the month' (not after this was supposed to be tied up before the end of January), but hey. Progress!

In other news, because I'm now at the 'faffing with player animations' stage, I'm going back and reworking the player model. Please let us bear witness to the joys of rigging:

(never try using blender's envelope weights as a shortcut, they never bloody work)
 
Sounds fun.

Do you have planned things like ranged attacks, for the bosses or the players?
 
bird_poison said:
Sounds fun.

Do you have planned things like ranged attacks, for the bosses or the players?
Click to expand...
Click to shrink...

Yes, but that's lower priority than getting melee working. A previous iteration on this actually did have ranged attacks but I couldn't get boss animation working for it.

Most of the 'which should I implement first?' questions boil down to 'it is a core mechanic?', 'how hard is it to implement?' and 'what other things do I need to implement first for this feature?'. Since this is as much a tech demo as it is a prototype, if it can't be implemented / the implementation requires changes to the design, I need to know earlier rather than later. The biggest challenge was actually Boss Melee, which is already implemented*, so the gameplay infrastructure for melee attacks (ie hitboxes, impact detection and so on) is already built.

In the case of player attacks, I need to set up the animation system to allow calling specific actions that their equipment may override (ie 'my input says play "equipment_action_0", which my sword says is "swipe_0", and I'm in a state where I'm free to play actions right now, so swipes away!' and so on). Honestly there's no real technical difference between a 'melee' animation and a 'ranged attack' animation (it's literally 'you play an animation, and events along its timeline spawn projectiles / open hitboxes / etc'; the animation system itself does not have to care what the animations do), but as noted the gameplay side of melee attacks is implemented, and I needed to solve the design problem of 'how to apply short-ranged melee attacks to gigantic boss monster', so melee took priority.

I adhere to the Soulsborne school of combat mechanics design, namely 'telegraph what is happening so the player has chance to respond'. In other words, almost all ranged attacks are going to involve slow-ish projectiles or beams you can see coming and escape rather than hitscans; hitscans are just too instantaneous for a player to react to. Think more 'bullet hell lite' than 'third person cover shooter'.

...That said, ranged weapons in Souls games are pretty awful to work with, so for the player side I absolutely want to make them easier to use, including firing whilst on the move and lockon not being useless (you can currently diverge your aim point off of where you're locked on, and you can lock onto any part of the boss rather than just its centre mass; it's also how you aim melee jump attacks after all).

* funnily enough, the very first procedural boss animation I built to test the system was a simple 'swipe' action. Partly because it was simpler than a procedural walkcycle, but also because it was that integral a feature and that difficult to implement, that if I couldn't get it working there was no point continuing. Admittedly it was just a swipe animation that didn't actually hurt you, because it was more about getting the boss to actually animate fluidly than anything else. I hadn't even implemented the player at that point in time :V
 
Last edited:
The mix of enormous wind-up time and inability to move is definitely why I usually only use ranged in Dark Souls to start engagements or to be really, really cheesy. Though another thing is that most of the really fun interplay seems to arise when you're in melee. There's often just more game there, IMO.

Anyway, all this stuff is pretty fascinating. I've recently done most of the Unity tutorials and I'm about midway through the Networking tutorial, so seeing the sausage being made by someone else is neat, and hopefully helpful.
 
Usandru said:
The mix of enormous wind-up time and inability to move is definitely why I usually only use ranged in Dark Souls to start engagements or to be really, really cheesy. Though another thing is that most of the really fun interplay seems to arise when you're in melee. There's often just more game there, IMO.

Anyway, all this stuff is pretty fascinating. I've recently done most of the Unity tutorials and I'm about midway through the Networking tutorial, so seeing the sausage being made by someone else is neat, and hopefully helpful.
Click to expand...
Click to shrink...

Yeah, Souls is absolutely melee focused, with ranged as a tacked on extra. Here I'd like for them to be of roughly equal standing. I'll probably have to make them either require a lot of precision or just not be as effective as melee, because of the risk/reward factor (it's safer to stay at range and plink compared to literally jumping into the boss's face and trying to stab it). Ranged will particularly be good for picking off small 'annoyance' Parts like turrets shooting at you, whilst if you want to hack a limb off and stop the Boss running around, it's time to get your axes on mate. There's also Spells, which also features ranged attacks that cost mana per shot, and you only have a fixed amount of that for the entire fight (which is also needed for things like 'healing yourself'). Testing and ironing that bit out is going to be fun.

At least I'm planning to have things lightly roguelike, so if there's a slightly OP weapon it's not too bad, it just flavours that particular run. That's a looong way off though lol.

I will be honest, networking terrifies the heck out of me, so I mostly stick to single-player projects :'D (heck of a lot easier to test too; current paid project is a local multiplayer game that doesn't require networking, but still requires I set up an minimalistic AI bot just to have something to play against and test things).

Still, best of luck! I'm glad these dev logs are of use to people. I'm mostly going by 'stuff I would have liked to know earlier' for topics to focus on. Are you new to game dev in general or just Unity specifically?

Best advise I can give is to get version control software (I just use bitbucket and SourceTree) and use it. In particular, whilst it allows you to revert changes that didn't play out, you'll often find you have a set of utility scripts, editors and shaders and so on that you're frequently wanting to use in every project. Make that into its own repo and clone it into every project, so you can keep them all in synch and not have to keep copy-pasting code or writing something you'd implemented before in a different project from scratch all over again. Saves so much time. My own utility set is pretty broad; stuff for handling saving/loading data, stuff for geometric tests and queries, additional math and debug functions, various data structures like quadtrees and so on.
 
Last edited:
Guessmyname said:
I will be honest, networking terrifies the heck out of me, so I mostly stick to single-player projects :'D (heck of a lot easier to test too; current paid project is a local multiplayer game that doesn't require networking, but still requires I set up an minimalistic AI bot just to have something to play against and test things).
Click to expand...
Click to shrink...

I like math, and most programming I've done so far has been algorithms which I also like, so I think I'll mostly enjoy it, but while the tutorial is very simple and implements very easily, I can already tell that it's a complex, complex thing.

But most of my gaming these days is with a group of my friends, so I figure if I'm going to build things, I might as well try to make an MP game for us to start with.

Still, best of luck! I'm glad these dev logs are of use to people. I'm mostly going by 'stuff I would have liked to know earlier' for topics to focus on. Are you new to game dev in general or just Unity specifically?
Click to expand...
Click to shrink...

Both, really. I haven't done anything serious before, and the unity tutorials are some of the biggest programming projects I've done, but at the same time, I have a lot of the prerequisites for getting good fast. The only problem is that my knowledge of modelling and animation - or, really, all the non-coding and non-design stuff - goes to around "there are programs for it and it is very hard".

I expect my prototypes will involves a loooot of rectangles and primitive shapes.

Best advise I can give is to get version control software (I just use bitbucket and SourceTree) and use it. In particular, whilst it allows you to revert changes that didn't play out, you'll often find you have a set of utility scripts, editors and shaders and so on that you're frequently wanting to use in every project. Make that into its own repo and clone it into every project, so you can keep them all in synch and not have to keep copy-pasting code or writing something you'd implemented before in a different project from scratch all over again. Saves so much time. My own utility set is pretty broad; stuff for handling saving/loading data, stuff for geometric tests and queries, additional math and debug functions, various data structures like quadtrees and so on.
Click to expand...
Click to shrink...

Ooh, good idea. I'll look into making that once I have something that looks vaguely like a first prototype, I think. I should probably also spend an hour learning how Visual Studio works.
 
Usandru said:
I like math, and most programming I've done so far has been algorithms which I also like, so I think I'll mostly enjoy it, but while the tutorial is very simple and implements very easily, I can already tell that it's a complex, complex thing.

But most of my gaming these days is with a group of my friends, so I figure if I'm going to build things, I might as well try to make an MP game for us to start with.
Click to expand...
Click to shrink...

If that's the case I would actually advise a local MP game (ie one console, one screen, 2-4 controllers). There are some shenanigans currently involved in setting up local multiplayer with Unity's current Input system, but it's simpler to solve than network multiplayer and the fun, fun realm of ping, lag compensation and packet loss.

For gaming code, if you don't know much about vector math now is the time to learn. Nearly everything in game code involves vectors in some way; they're how position is stored in space, how you define directions and so on and so forth. My personal bible on this topic is 3D Math Primer for Graphics and Game Development by Dunn & Parberry; it's a very useful reference.

Usandru said:
Both, really. I haven't done anything serious before, and the unity tutorials are some of the biggest programming projects I've done, but at the same time, I have a lot of the prerequisites for getting good fast. The only problem is that my knowledge of modelling and animation - or, really, all the non-coding and non-design stuff - goes to around "there are programs for it and it is very hard".

I expect my prototypes will involves a loooot of rectangles and primitive shapes.
Click to expand...
Click to shrink...

Heh. Well, fun tip: I actually started out modelling before I started out coding, so I've dipped my toes in several different modelling programs. 3dsMax and Maya considered the 'standards', but I personally use Blender. I have a licensed copy of 3ds Max and haven't tried Maya, but Blender is a whole lot quicker to work with; you can do things with a lot less hassle. You can rig and uv a model without having to dance around with modifier stacks that will break all your work if you sneeze (fuck you very much 3dsMax) and Unity can import .blend files directly because the file format isn't proprietary :rolleyes: (technically it tells blender to export the file as .fbx and imports that but still it can't do that with a .max file). Oh and it's free. You can even texture paint directly on models from inside it, it's surprisingly well featured. Has some idiosyncrasies and obtuse moments, but no more than 3ds Max has and I'd still say it's much easier to learn (and free). And, seriously, you can work so much quicker in Blender than in 'Max, without having to faff with the import/export carousel. You can model, rig, texture and animate everything in Blender if you so desire.

2D art side, I'll admit Photoshop is very very hard to beat, but Krita is slowly edging closer and is, again, free. With its new 2D animation tools it's almost certainly better than Photoshop for that kind of work. Admittedly I haven't used it as much these days because most of the time I'm painting models directly in Blender or just pumping out prototype art quickly without bothering with textures. It comes up more in my art commissions :V

(GIMP though is bloody awful. It's interface is a bloody disaster and compared to Krita just isn't remotely worth your time)

Usandru said:
Ooh, good idea. I'll look into making that once I have something that looks vaguely like a first prototype, I think. I should probably also spend an hour learning how Visual Studio works.
Click to expand...
Click to shrink...

Lol I barely know how VStudio works either (I initially used Monodevelop because it's what Unity shipped with at the time, until it started getting too buggy on windows and they packed VStudio along with as well). Find out how to hook it up for debugging and breakpoints and you're pretty much good. It has a snazzy thing for letting you rename variables if you accidentally a typo (which will also change every reference to said variable in the project; handy!), and Ctrl-K, Ctrl-T will tell you every call to a given function. That's about it.

Oh, and there's some shenanigans involved also when it comes to Unity and serializing data (if it's a Generic type it won't serialize, if it's a multi-dim array it won't serialize and unless it's derived from MonoBehaviour or ScriptableObject, you can't use polymorphism and will have to work around). That's fun. With generics you can cheat and have a serializable concrete class (ie if you want, say, a QuadTree<Transform> to be exposed in the inspector and saved by Unity, you can just go TransformQuadTree : QuadTree<Transform>, mark it serializable and it will work). Interfaces are a bit of an arse; GetComponent<InterfaceType> will correctly return all Components implementing a given interface, but other than that the unity serializer can't handle them at all because it has idea what the concrete types involved are. I typically wind up using abstract classes instead.
 
Last edited:
Guessmyname said:
If that's the case I would actually advise a local MP game (ie one console, one screen, 2-4 controllers). There are some shenanigans currently involved in setting up local multiplayer with Unity's current Input system, but it's simpler to solve than network multiplayer and the fun, fun realm of ping, lag compensation and packet loss.
Click to expand...
Click to shrink...

Sadly, the friends I play with live a little far away, so~

Worst case I figure I switch to turn-based and just have the server collect all the turn orders and execute them at the same time.

For gaming code, if you don't know much about vector math now is the time to learn. Nearly everything in game code involves vectors in some way; they're how position is stored in space, how you define directions and so on and so forth. My personal bible on this topic is 3D Math Primer for Graphics and Game Development by Dunn & Parberry; it's a very useful reference.
Click to expand...
Click to shrink...

The next vector stuff I'm going to be working on is probably going to be going back to linear algebra again, and also vector calculus in k-dimensions. :p

I've been working my way through basic discrete mathematics and mathematical analysis for the last... bit more than six months now.

Though, that aside, I should probably brush up on dot products and the like. It's been a while since I really calculated anything.

Heh. Well, fun tip: I actually started out modelling before I started out coding, so I've dipped my toes in several different modelling programs. 3dsMax and Maya considered the 'standards', but I personally use Blender. I have a licensed copy of 3ds Max and haven't tried Maya, but Blender is a whole lot quicker to work with; you can do things with a lot less hassle. You can rig and uv a model without having to dance around with modifier stacks that will break all your work if you sneeze (fuck you very much 3dsMax) and Unity can import .blend files directly because the file format isn't proprietary :rolleyes: (technically it tells blender to export the file as .fbx and imports that but still it can't do that with a .max file). Oh and it's free. You can even texture paint directly on models from inside it, it's surprisingly well featured. Has some idiosyncrasies and obtuse moments, but no more than 3ds Max has and I'd still say it's much easier to learn (and free). And, seriously, you can work so much quicker in Blender than in 'Max, without having to faff with the import/export carousel. You can model, rig, texture and animate everything in Blender if you so desire.

2D art side, I'll admit Photoshop is very very hard to beat, but Krita is slowly edging closer and is, again, free. With its new 2D animation tools it's almost certainly better than Photoshop for that kind of work. Admittedly I haven't used it as much these days because most of the time I'm painting models directly in Blender or just pumping out prototype art quickly without bothering with textures. It comes up more in my art commissions :V

(GIMP though is bloody awful. It's interface is a bloody disaster and compared to Krita just isn't remotely worth your time)
Click to expand...
Click to shrink...

Oho. I guess I might take a look at Krita. I've been reasonably happy with GIMP for the few things I've ever used it for (mostly cropping images and adding transparency really...) but if there's something better out, hey, maybe it's time to upgrade.

Lol I barely know how VStudio works either (I initially used Monodevelop because it's what Unity shipped with at the time, until it started getting too buggy on windows and they packed VStudio along with as well). Find out how to hook it up for debugging and breakpoints and you're pretty much good. It has a snazzy thing for letting you rename variables if you accidentally a typo (which will also change every reference to said variable in the project; handy!), and Ctrl-K, Ctrl-T will tell you every call to a given function. That's about it.

Oh, and there's some shenanigans involved also when it comes to Unity and serializing data (if it's a Generic type it won't serialize, if it's a multi-dim array it won't serialize and unless it's derived from MonoBehaviour or ScriptableObject, you can't use polymorphism and will have to work around). That's fun. With generics you can cheat and have a serializable concrete class (ie if you want, say, a QuadTree<Transform> to be exposed in the inspector and saved by Unity, you can just go TransformQuadTree : QuadTree<Transform>, mark it serializable and it will work). Interfaces are a bit of an arse; GetComponent<InterfaceType> will correctly return all Components implementing a given interface, but other than that the unity serializer can't handle them at all because it has idea what the concrete types involved are. I typically wind up using abstract classes instead.
Click to expand...
Click to shrink...

Heh. Well, I've had it suggested to me to get a C# certification so I can put something in the vein of "I can actually program for sure guys" on my CV since a BA in linguistics does not exactly imply this usually. :p

I figure if I go for that, I might as well learn how VStudio works at the same time. It looks like a pretty great IDE after all.
 
Usandru said:
Sadly, the friends I play with live a little far away, so~

Worst case I figure I switch to turn-based and just have the server collect all the turn orders and execute them at the same time.
Click to expand...
Click to shrink...

Welp, then yeah I'd say turn-based, at least for your first MP project. I know enough about realtime networking to know I do not know enough about realtime networking and the topic is terrifying.

Usandru said:
The next vector stuff I'm going to be working on is probably going to be going back to linear algebra again, and also vector calculus in k-dimensions. :p

I've been working my way through basic discrete mathematics and mathematical analysis for the last... bit more than six months now.

Though, that aside, I should probably brush up on dot products and the like. It's been a while since I really calculated anything.
Click to expand...
Click to shrink...

Haha, okay yes I bow and acknowledge your math-fu is stronger than mine. And yeah, it's mostly just knowing how to solve x problem with vector math (ie the vector from A to B is B - A and so on) and getting a feel for when to apply what. By the sounds of it you shouldn't have trouble.

All I can advise is to try and use vectors for directions and quaternions for orientations wherever possible, instead of using angles/euler angles. Angles don't interpolate too well (how far apart is 330 degrees and 30 degrees? 300 if you're not paying attention!), you have to constantly dig through the API to check if a given function returns in degrees or radians, there's always that annoying ambiguity about what direction angle 0 is facing in exactly and finally there's gimbal lock. Euler Angles look intuitive but really they're a complete arse to work with.

Quaternions are kind of evil but you've got to learn to love hate use them if you want to do rotation interpolation.

Usandru said:
Oho. I guess I might take a look at Krita. I've been reasonably happy with GIMP for the few things I've ever used it for (mostly cropping images and adding transparency really...) but if there's something better out, hey, maybe it's time to upgrade.
Click to expand...
Click to shrink...

(EDIT: nobody saw that)

Textures in game dev tend to get a little technically involved at times, and at others you just need to quickly paint something or make a texture tile. I'll admit I tried GIMP after being spoilt by Photoshop for at least two years, but I found it incredibly obtuse and not user friendly (there's also a weird 'structural bug' the devs aren't interested in fixing where any pixel with alpha 0 turns black, which can seriously screw up more technical textures; common practise is to have specular or emission or something in a normal map's alpha channel, so if your spec/em is 0...)

Krita meanwhile I was able to pick up intuitively, and they're making active effort to make it useful for game development.

Usandru said:
Heh. Well, I've had it suggested to me to get a C# certification so I can put something in the vein of "I can actually program for sure guys" on my CV since a BA in linguistics does not exactly imply this usually. :p

I figure if I go for that, I might as well learn how VStudio works at the same time. It looks like a pretty great IDE after all.
Click to expand...
Click to shrink...

Fair play! I... have a Games Art degree lol, so I should probably look into that myself... I kind of figured 'hey I made a procedural boss generator go try it out' would be enough proof of competence.
 
Last edited:
Guessmyname said:
Haha, okay yes I bow and acknowledge your math-fu is stronger than mine. And yeah, it's mostly just knowing how to solve x problem with vector math (ie the vector from A to B is B - A and so on) and getting a feel for when to apply what. By the sounds of it you shouldn't have trouble.

All I can advise is to try and use vectors for directions and quaternions for orientations wherever possible, instead of using angles/euler angles. Angles don't interpolate too well (how far apart is 330 degrees and 30 degrees? 300 if you're not paying attention!), you have to constantly dig through the API to check if a given function returns in degrees or radians, there's always that annoying ambiguity about what direction angle 0 is facing in exactly and finally there's gimbal lock. Euler Angles look intuitive but really they're a complete arse to work with.

Quaternions are kind of evil but you've got to learn to love hate use them if you want to do rotation interpolation.
Click to expand...
Click to shrink...

In all fairness, I'm not necessarily good at any of that stuff yet. :p

And I just took a glance at the wiki-page for quaternions.

...the complex numbers just jumped a bit up in priority for me.

(EDIT: nobody saw that)

Textures in game dev tend to get a little technically involved at times, and at others you just need to quickly paint something or make a texture tile. I'll admit I tried GIMP after being spoilt by Photoshop for at least two years, but I found it incredibly obtuse and not user friendly (there's also a weird 'structural bug' the devs aren't interested in fixing where any pixel with alpha 0 turns black, which can seriously screw up more technical textures; common practise is to have specular or emission or something in a normal map's alpha channel, so if your spec/em is 0...)

Krita meanwhile I was able to pick up intuitively, and they're making active effort to make it useful for game development.
Click to expand...
Click to shrink...

Huh. Interesting. I fully intend to ignore doing textures until absolutely necessary (and hopefully if I reach the point where I find it necessary, I'm ready and willing to pay for someone else to deal with it...) but I'll definitely keep that in mind.

Fair play! I... have a Games Art degree lol, so I should probably look into that myself... I kind of figured 'hey I made a procedural boss generator go try it out' would be enough proof of competence.
Click to expand...
Click to shrink...

As long as you're working in games I'd guess it is, but I'm probably going to end up doing something with machine cognition and do games dev just as a hobby, and I'm not sure those employers would be quite as convinced by Unity prototypes compared to official-looking papers and the like.

Of course I also have a Master's degree to finish first, so I'm not particularly concerned either way. :p
 
Usandru said:
And I just took a glance at the wiki-page for quaternions.

...the complex numbers just jumped a bit up in priority for me.
Click to expand...
Click to shrink...

If it's any consolation, you don't actually have to work with or interact with the complex numbers in any way. It's best not to mess with the x,y,z,w components directly, just construct them with Quaternion.LookDirection to make an orientation that points down a given vector, with a second vector pointing the 'up' direction. Then remember the byzantine rules for quaternion multiplication and cry. If you want to understand quaternions and how to work with them, reference frames would be a better topic to study.

Quaternion.RotateTowards is absolutely your best friend function when dealing with the bastards. If you want to scale a Quaternion (ie by deltaTime, for instance), you can use RotateTowards with Quaternion.identity (quaternion equivalent of the zero vector) and then apply it. It won't overshoot though. If you want to double a quaternion, you'll have to use Quaternion.SlerpUnclamped with a t-value of 2, for instance.

Mathematically, you're supposed to be able to "scale" a quaternion by raising it to powers (ie 3x a quaternion is actually the quaternion's cube; applying the rotation '3 times') but Unity's API in all its wisdom does not have a Quaternion.Pow function and if you do one manually with the x,y,z,w components, your console will spam with errors because floating point error meant the result was no longer a unit quaternion. Which makes weird shit happen. There's no Quaternion.Normalize function either; the API functions must have their own checks for that. RotateTowards and Slerp both effectively behave like Pow if you use them with Quaternion.Identity though, as you're literally moving closer/farther from 0.

This is all shit I had to figure out / step on the landmines for to get a spring system going for rotations. As I said, they're pretty evil.
 
Guessmyname said:
You can model, rig, texture and animate everything in Blender if you so desire.
Click to expand...
Click to shrink...
And sculpt, for those who like to soften everything after adjusting a single vertice in edit mode.

But wondering about the melee/range thing, what's the incentive to get the chin broken when shooting and strafing is a thing? Either the boss needs to be good at closing in, or the ammo needs to be costly to make the melee game that. Maybe aiming should take time, thus being as risky as parrying? Maybe the boss should have different "materials", to signal pieces resistant or vulnerable to shots? Maybe the boss can respond in kind at being shot too much?
 
bird_poison said:
But wondering about the melee/range thing, what's the incentive to get the chin broken when shooting and strafing is a thing? Either the boss needs to be good at closing in, or the ammo needs to be costly to make the melee game that. Maybe aiming should take time, thus being as risky as parrying? Maybe the boss should have different "materials", to signal pieces resistant or vulnerable to shots? Maybe the boss can respond in kind at being shot too much?
Click to expand...
Click to shrink...

Oh, the boss can absolutely start fighting ranged duels (once the boss parts etc for it are in). I'd say the main advantage of melee over ranged is that melee does much more burst damage, whilst ranged requires multiple accurate shots on target to achieve the same effect. Big/Major parts like limbs would only be removable via melee most probably. It's breaking the smaller parts like turrets or mana stores that ranged would excel at and melee wouldn't (due to the probable difficulty of landing a strike on a small target, even with the jump guidance). Ranged is likely going to be a mix of 'harass with light attacks' and 'precision aiming with heavy attacks'.

Different materials is a planned feature, yes. Armour in particular is likely to block Ranged attacks completely (though heavy, blunt melee weapons can smash it).

It'll be experimental to figure out the balance. Getting the actual mechanics in place is more of a priority right now.

I absolutely want there to be some form of 'finisher' move which has to be charged up and leaves the player vulnerable, but wrecks face. The idea being if you just try to one-shot the boss with it, it smacks you, but if you whittle it down and cripple/stun it enough you can pull it off. A kind of 'psuedo parry' system that doesn't require a whole parry/riposte system set up.
 
You must login or register to reply here.
Remove ads
Back
Top