This is potentially my most ambitious video yet, so hear me out. If you've ever been confused about Control nodes, hopefully this will even things out a little. I'm going to explain Control nodes in as much excruciating detail as I possibly can.
Basically, Control nodes are super useful for all things that are to do with GUI, so things like menus, HUDs, etc.
So, let's start with the base node, just named "Control", and let's talk about how it's different from the much more straight-forward Node2D.
Node2Ds have a category called "Transform" which holds all of the data for where the node is positioned, how it's rotated and how it's scaled. Pretty simple stuff.
Controls however have a category called "Rect" which deals with all of this, and it's a little bit more convoluted. They do have a position property, a rotation and a scale property, but they also have size properties, pivot offset and clip content.
That's because whereas a Node2D is effectively a marker for drawing 2D graphics, a Control node is an organizational thing for UI elements, so it's actually a box. A Node2D behaves like a point with some Transform values, whereas a Control node is a little rectangle with stuff in it.
It's also worth mentioning that you can't position Control nodes at fractional positions, they'll automatically snap to the nearest pixel. I don't know why this is, but that's the way it is, so I guess deal with it.
Now for the really scary stuff and the thing that prompted me to even make this video, Anchors and Margins.
Basically, this whole system ensures that no matter the screen size, GUI elements will always be in the correct positions. Anchors do this by "anchoring" a Control node to its parent object. If the Control node is the tree root node, then its parent should be a Viewport.
So basically, under "Anchor" there are four properties - "Left", "Top", "Right", and "Bottom". These each refer to edges of the Control node's Rect, relative to the parent. They all take in values from 0 to 1, which represent what percentage along the parent rect size to put each edge.
This is relative to the top-left corner, so if you wanted your control node to alway stay in the top left, you could put "Left" to 0 and "Top" to 0. This means that the Left and Top edges are both 0% along the screen at all times. If you wanted to make the bottom-right corner extend exactly to the center of the screen, you could make "Right" and "Bottom" both 0.5, which would place the Right and Bottom edges precisely 50% along the screen at all times.
So this is super useful to make UI elements proportional to the screen, other UI elements, etc. So what does Margin do?
Well, Margin is basically offset. If you want to offset your shape by a factor of 100 in the x axis, all you have to do is set the "Left" and "Right" values to 100 and it'll move those edges away from the left-hand side of the screen by that amount. However, a warning: these values are absolute, so that means if you shrink the screen below the offset value your elements will probably disappear off the side. I would hesitate to over-use Margins, since it can undermine the whole purpose of using Anchors in the first place.
You can also use margin to actually change the size of the Control node that you're using. So if you set the Left margin to -100 and the Right margin to 100, it'll move the Left edge 100 pixels closer to the left-hand side and it'll move the Right edge 100 pixels away from the left-hand side. This is probably useful for something.
So that's arguably the scariest bit explained, now onto another fairly scary bit- Grow Directions.
So basically, as the name would suggest this is to do with the direction your Control node is expected to grow. If you set both the Horizontal property to "Begin" - as it is by default - you might notice that when you attempt to adjust the Right Margin, it stops changing in size once the size gets to whatever its minimum size is.
However, if you adjust the Left margin and try to shrink the shape horizontally as much as you can, you'll notice that rather than just deny any new growth it'll start to just move instead.
This is because the Control node is effectively ready to start "growing" from the left-hand side if you set Horizontal to "Begin". Think in terms of a Label that's holding a line of text. If you start typing, it should expand away from the left-hand side.
I'll be honest here I'm not sure I entirely understand this bit but it doesn't seem essential so I guess my advice to you is just leave this to "Begin" because otherwise demons and evil spirits will haunt you until either you die or you stop worrying about Grow Directions.
Now for something which is awesome but not as terrifying as the previous stuff, the Focus section!
This is to do with stuff like if you press the tab key, or you want to use the keyboard or a gamepad to navigate menus, stuff like that. If you don't want to deal with this then Godot does actually automatically figure out some of this stuff, but it's not perfect and it frequently gets a bit buggy and confusing.
This category is designed to allow you to manually set which button or node to focus if Godot's messing up or you want to move to somewhere that Godot can't really predict. It's super easy, basically if you select a Button you'll get some "Neighbour" properties named "Neighbour Left", "Neighbour Top", etc.
You can set these properties to point to a node that you want to focus on when the player presses the associated direction on either a gamepad, arrow keys, etc. The Next and Preivous ones work in a similar way, if you haven't explicitly defined any Neighbours but you just want a one-dimensional list of buttons to cycle through for example when the player presses the Tab key, then you can set Next to whatever you want to come next if the player has got that button focused but wants to focus another node.
It's super simple, but a super intuitive way to setup keyboard controls for menu systems.
As for the mouse bit, this describes how the given Control node handles the mouse cursor interacting with it. Imagine that you have two buttons on top of each other, so that one is completely blocking the other. Normally, these would both have the mouse filter set to "Stop" which means that if it receives a mouse event, it'll "block" any item below it from actually receiving that event.
However, if you set the button on top's mouse filter to "Ignore", it'll completely ignore the mouse and you'll be able to click on the button below. This might be useful if you want to hide a button from being interacted with temporarily and for whatever reason setting visibility isn't suitable at that time.
Also, you can set the "Default Cursor" that appears when the user is hovering over the button. It's super easy to use but basically you get a big list of potential options which the cursor will turn into when the button is moused over.
Now for the Size Flags, which I've only ever used with respect to BoxContainers or GridContainers so I guess I'll carry on that traditionand only even teach it with respect to Containers.
From what I can tell, it's a little bit buggy and unpredictable but the important things to note are that Fill makes it take up as much room as possible, but sometimes you need to enable Expand too and I don't know why. Sometimes when you enable Expand once, then disable it, then disable Fill, then re-enable Fill it'll also Expand the node to fill up as much space as it can, for some reason.
You can also use Shrink Center which will sometimes center the nodes in the BoxContainer or GridContainer and keep them at their minimum size, but only if they're really feeling like it. If they're having an off day, then they won't.
This explanation sucked but just press them randomly until you get what you want, they're not that important to understand I guess. If you have a better understanding of these, then please let me know.
As for Styles, again, if you have a good understanding or usecase of these then be my guest but custom styles seem remarkably pointless and difficult to use compared to making panels, buttons etc manually in a sprite editor.
So I guess I've explained the essential components of Control nodes, now I'll get into some more specific instances of Control Nodes, starting from the top, which would be the Popup nodes. Thanks for watching and stay tuned for that in Part 2 of this series that apparently I'm doing now. Goodbye!
Sunday, 12 August 2018
Godot Is PERFECT For The Ludum Dare
So it's Ludum Dare 42 in about six hours at the time of writing and I've decided that I'd write a little script about why I think that the Godot Engine is perfectly designed for game jams like the Ludum Dare.
Mostly, this is because Godot is just perfect for very small iteration cycles. If you have a solid idea in mind, you can spend probably no more than a few hours to actually get a very basic product up and running.
This means that if you really wanted to, you could run through several different ideas over the course of a day to determine which of them you like the most. Not that I'd strictly recommend doing this, since y'know- time constraints are time constraints, but in case your first idea doesn't pan out so well it's nearly trivial to try out another one.
Also, the engine is super light which means that an average game made in the Godot Engine will only use up about 20 to 30 megabytes. This makes it much easier and convenient for people to actually play your game, although I will admit that the web export system is a little bit hit-or-miss. Usually it'll work great, but sometimes you can run into problems that might warrant encouraging the user to run the downloadable version instead.
Also, here's a personal favourite of mine- particle effects. In short, it's *really easy* to make something look a certain base level of good if you just overload it with particle effects. It's similar to reverb in songs- you might not get very far if you don't know what you're doing, but if you're really clueless or just in a hurry then it'll work out great for you.
Godot is great for particle effects, they run super nicely (even if you're trying to render about 10x more than you should) and the actual particles editor is honestly amazing. If you need proof, then you should know that in my game WARP-TEK which is currently being shown on screen, pretty much all the graphics are based in Godot particle effects in some way or another.
In combination with that, light effects. Creating and adding lights are very trivial and again- they look awesome even if you don't really know what you're doing. These can get a little bit expensive if you have too many so just be careful of that, but as long as you're not creating like 25 of them on the same exact location, you should be good to go.
Also, Godot is excellent for keeping things organized- especially with small projects. In a game jam situation, you're probably not going to want to have spend a lot of time trying to work out what this weird variable does, or where you called this function from. With a combination of signals, multiple distributed script files and the occasional recursive egrep, it's pretty hard to go wrong and get too confused.
Now this last point isn't really in the same category as the others, since I would say that it primarily deals with why game jams are perfect for Godot, rather than the other way around. Godot is a fairly small engine in terms of community and publicity. Unity and Unreal are both backed by astronomical marketing budgets, whereas Godot pretty much only has word of mouth and a Patreon page.
If you really like the Godot Engine and want it to see some extra consideration from other developers, then I'd recommend using it for this upcoming Ludum Dare. Hell, even if you've never used it before- a game jam is a perfect time to try out a new engine in a low-stakes environment. It's good for your skillset and it's good for the engine if more people use it.
Thanks for watching, best of luck in Ludum Dare 42, and stay tuned for more videos about some things which video games are sometimes a part of. Goodbye!
Mostly, this is because Godot is just perfect for very small iteration cycles. If you have a solid idea in mind, you can spend probably no more than a few hours to actually get a very basic product up and running.
This means that if you really wanted to, you could run through several different ideas over the course of a day to determine which of them you like the most. Not that I'd strictly recommend doing this, since y'know- time constraints are time constraints, but in case your first idea doesn't pan out so well it's nearly trivial to try out another one.
Also, the engine is super light which means that an average game made in the Godot Engine will only use up about 20 to 30 megabytes. This makes it much easier and convenient for people to actually play your game, although I will admit that the web export system is a little bit hit-or-miss. Usually it'll work great, but sometimes you can run into problems that might warrant encouraging the user to run the downloadable version instead.
Also, here's a personal favourite of mine- particle effects. In short, it's *really easy* to make something look a certain base level of good if you just overload it with particle effects. It's similar to reverb in songs- you might not get very far if you don't know what you're doing, but if you're really clueless or just in a hurry then it'll work out great for you.
Godot is great for particle effects, they run super nicely (even if you're trying to render about 10x more than you should) and the actual particles editor is honestly amazing. If you need proof, then you should know that in my game WARP-TEK which is currently being shown on screen, pretty much all the graphics are based in Godot particle effects in some way or another.
In combination with that, light effects. Creating and adding lights are very trivial and again- they look awesome even if you don't really know what you're doing. These can get a little bit expensive if you have too many so just be careful of that, but as long as you're not creating like 25 of them on the same exact location, you should be good to go.
Also, Godot is excellent for keeping things organized- especially with small projects. In a game jam situation, you're probably not going to want to have spend a lot of time trying to work out what this weird variable does, or where you called this function from. With a combination of signals, multiple distributed script files and the occasional recursive egrep, it's pretty hard to go wrong and get too confused.
Now this last point isn't really in the same category as the others, since I would say that it primarily deals with why game jams are perfect for Godot, rather than the other way around. Godot is a fairly small engine in terms of community and publicity. Unity and Unreal are both backed by astronomical marketing budgets, whereas Godot pretty much only has word of mouth and a Patreon page.
If you really like the Godot Engine and want it to see some extra consideration from other developers, then I'd recommend using it for this upcoming Ludum Dare. Hell, even if you've never used it before- a game jam is a perfect time to try out a new engine in a low-stakes environment. It's good for your skillset and it's good for the engine if more people use it.
Thanks for watching, best of luck in Ludum Dare 42, and stay tuned for more videos about some things which video games are sometimes a part of. Goodbye!
Wednesday, 1 August 2018
The Dark Side of Rapid Prototyping
As many of my viewers might be aware, my engine of choice (Godot) is very suited to rapid prototyping.
It's very quick and easy to program most types of game logic and usually, actually prototyping something will take anywhere from 1-4 days of full-time work. This is awesome compared to heavier programs like Unity which are a bit more technical and in-detail even when that's not what you're looking for, but that's a topic for a different video.
However, it's also very easy to prototype WAY too much. I know this because a little while ago I temporarily burned myself out prototyping like mad for a month, and then had to take a month off of YouTube and gamedev.
This was partly because I had a bunch of exams, but forcing myself to continue with that stuff even when I hated thinking about it would have put too much strain on my ability to properly revise and prepare for exams.
For context, I made about ten prototypes of games in about 20 days. Needless to say this was just too much and to not make any real progress or not make anything that I can actually say I'm proud of in that time was pretty instrumental to burning me out. I didn't make really any cool graphics or programming tricks or ANYTHING that was actually cool, it was basically just a new layout of buttons and keybinds every time.
That's kind of the problem. I frequently say to people who are looking to avoid burnout that they should maybe not leave graphics right to the end unless graphics are really intensive to create, at which point they probably shouldn't be making the graphics so intensive to begin with. If you don't have something you can look at and feel good for having made, it's going to take a toll on your brain after a while.
That's why with my current game, WARP-TEK, I basically made all the sprites right as I was implementing the entities and even though I had to basically bleach them and apply some cool colour aesthetic, I was still working through the visual aspect at the same time. This keeps me motivated and excited to keep working on this game. Maybe I'm just a particularly visual person, and some people don't value these things as much as I do but I can say from the bottom of my heart that nothing helps me to avoid burnout like creating tangible assets that I'm proud of alongside programming.
Also, it helps with your early marketing if you've got some flashy graphics or a catchy tune to go along with your game from early on, since most consumers also won't care about "woah look at this crazy level generation algorithm".
But either way, what's the point of this video?
If you're making a prototype, you're trying to determine whether the game is worth pursuing. Remember that you're not just trying to make a really rubbish, stripped-down version of a game, you're trying to think about whether or not it's worth even continuing.
Sometimes it's a good idea to create assets alongside prototyping if it helps you to determine the value of the game idea. That's basically the advice.
I didn't create any assets I really liked when I was stuck in prototype hell, but when I came back I made a prototype with a few assets I kind of liked the look of and it motivated me to make the prototype into a full game, which is now known as WARP-TEK. It's better to make sprites too early and have to re-make them than to put off making sprites until your project dies anyway.
Thanks for watching this poorly scripted mess, but if you actually gleaned some useful information from this then I'm simultaneously glad and impressed. Stay tuned for more tightly-scripted videos, in the future, trust me, I promise. Goodbye!
It's very quick and easy to program most types of game logic and usually, actually prototyping something will take anywhere from 1-4 days of full-time work. This is awesome compared to heavier programs like Unity which are a bit more technical and in-detail even when that's not what you're looking for, but that's a topic for a different video.
However, it's also very easy to prototype WAY too much. I know this because a little while ago I temporarily burned myself out prototyping like mad for a month, and then had to take a month off of YouTube and gamedev.
This was partly because I had a bunch of exams, but forcing myself to continue with that stuff even when I hated thinking about it would have put too much strain on my ability to properly revise and prepare for exams.
For context, I made about ten prototypes of games in about 20 days. Needless to say this was just too much and to not make any real progress or not make anything that I can actually say I'm proud of in that time was pretty instrumental to burning me out. I didn't make really any cool graphics or programming tricks or ANYTHING that was actually cool, it was basically just a new layout of buttons and keybinds every time.
That's kind of the problem. I frequently say to people who are looking to avoid burnout that they should maybe not leave graphics right to the end unless graphics are really intensive to create, at which point they probably shouldn't be making the graphics so intensive to begin with. If you don't have something you can look at and feel good for having made, it's going to take a toll on your brain after a while.
That's why with my current game, WARP-TEK, I basically made all the sprites right as I was implementing the entities and even though I had to basically bleach them and apply some cool colour aesthetic, I was still working through the visual aspect at the same time. This keeps me motivated and excited to keep working on this game. Maybe I'm just a particularly visual person, and some people don't value these things as much as I do but I can say from the bottom of my heart that nothing helps me to avoid burnout like creating tangible assets that I'm proud of alongside programming.
Also, it helps with your early marketing if you've got some flashy graphics or a catchy tune to go along with your game from early on, since most consumers also won't care about "woah look at this crazy level generation algorithm".
But either way, what's the point of this video?
If you're making a prototype, you're trying to determine whether the game is worth pursuing. Remember that you're not just trying to make a really rubbish, stripped-down version of a game, you're trying to think about whether or not it's worth even continuing.
Sometimes it's a good idea to create assets alongside prototyping if it helps you to determine the value of the game idea. That's basically the advice.
I didn't create any assets I really liked when I was stuck in prototype hell, but when I came back I made a prototype with a few assets I kind of liked the look of and it motivated me to make the prototype into a full game, which is now known as WARP-TEK. It's better to make sprites too early and have to re-make them than to put off making sprites until your project dies anyway.
Thanks for watching this poorly scripted mess, but if you actually gleaned some useful information from this then I'm simultaneously glad and impressed. Stay tuned for more tightly-scripted videos, in the future, trust me, I promise. Goodbye!
Tuesday, 31 July 2018
What is and isn't an "Asset Flip"?
Judging by the discussion I've seen on the Internet as of late, I've seen a lot of conflicting definitions of what "asset flips" actually are, and what they are not. Such a seemingly simple and straight-forward concept actually has a lot of nuance and subjectivity built into it.
So first, let's work out where the term "asset flip" comes from. It was coined by Jim Sterling in his Jimquisition video appropriately named, "The Asset Flip". The term is based on the sleazy business practice of "flipping" wares for profit, most commonly houses and cars.
Specifically, flipping, say, a house would involve buying it at a low price from someone who wants to get rid of it, then selling it off again at a higher price almost immediately with little-to-no refurbishment. This kind of practice is actually illegal in some places since it often incorporates some form of fraud, at least from my pretty weak understanding of the situation.
The point is that the concept of "flipping" has existed for kind of a while, and only recently has it been brought into the games industry. When Jim Sterling first used it, Digital Homicide was a prime example, who bought a lot of pre-built assets and "flipped" them with little-to-no changes or thoughtful design to go with it.
However, as with all things there's some grey area. What exactly constitutes "thoughtful design", and what makes a change big or small enough to cross the boundary between "asset flip" and "genuine video game"?
Some people have even gone so far as to declare that Player Unknown's Battlegrounds is an asset flip, since it uses a lot of assets from the Unreal Engine asset store.
I'm not here to set the record straight or anything since I don't really think I'm even slightly influential enough to do that, but I will offer my interpretation of an asset flip. I believe that a game becomes an asset flip when there's reasonable cause to believe that the developer did not put genuine work or effort into the project and rather is attempting to sit on the merits of assets that somebody else made.
This means that I don't consider PUBG an asset flip. While PUBG does use a lot of pre-built assets, I think that the developer has clearly put in effort to make the assets they did use coherent, well-assembled and overall it comes together in a cohesive gameplay experience that a hell of a lot of people enjoy.
Digital Homicide's infamous title The Slaughtering Grounds is something that I would consider an asset flip, since the gameplay experience is far from cohesive, feels cheap and I get the impression that the assets are the only thing the game has going for it and Digital Homicide know it. They're attempting to score a few bucks from people who take a quick look at the competently built assets and decide that they'd buy it.
However, that's not the end of the story for the term "asset flip". There's an effort in some strange part of Twitter to actually re-brand "asset flip" as a neutral or even positive term to describe basically any game that uses pre-built assets. In so far as that goes, I think that's the wrong way to approach things. The fact that "flipping" already exists as its own derogatory term in the real world makes it a thousand times harder to re-brand asset flipping in consumer's eyes.
Also, defining "asset flips" as any game that uses a pre-built asset is kind of crazy and not only de-values the term, it actually shuts out smaller indies who might not be able to afford or otherwise accomodate a full-time artist and opt instead to purchase assets that they like from the Internet. If consumers think that using any pre-built asset is bad(which they pretty much do at this point), then I can't see that ending up as good for really anyone.
So in closing, I've got one more thing to say. I opt to not even say "asset flip" very often since there's a lot of controversy and confusion about what the term even means. I think a more useful and accurate term in most discussions(such as the whole Steam clutter problem thing) is to just say "bad game". Not all bad games are asset flips- in fact a lot of them aren't. Asset flips suck, but they're a subset of the larger issue which is low-effort and dishonest titles getting onto Steam and making things harder for everybody.
Anyway, thanks for watching and stay tuned for more videos that will probably make people mad at me in the comments section because this is a properly controversial topic.
So first, let's work out where the term "asset flip" comes from. It was coined by Jim Sterling in his Jimquisition video appropriately named, "The Asset Flip". The term is based on the sleazy business practice of "flipping" wares for profit, most commonly houses and cars.
Specifically, flipping, say, a house would involve buying it at a low price from someone who wants to get rid of it, then selling it off again at a higher price almost immediately with little-to-no refurbishment. This kind of practice is actually illegal in some places since it often incorporates some form of fraud, at least from my pretty weak understanding of the situation.
The point is that the concept of "flipping" has existed for kind of a while, and only recently has it been brought into the games industry. When Jim Sterling first used it, Digital Homicide was a prime example, who bought a lot of pre-built assets and "flipped" them with little-to-no changes or thoughtful design to go with it.
However, as with all things there's some grey area. What exactly constitutes "thoughtful design", and what makes a change big or small enough to cross the boundary between "asset flip" and "genuine video game"?
Some people have even gone so far as to declare that Player Unknown's Battlegrounds is an asset flip, since it uses a lot of assets from the Unreal Engine asset store.
I'm not here to set the record straight or anything since I don't really think I'm even slightly influential enough to do that, but I will offer my interpretation of an asset flip. I believe that a game becomes an asset flip when there's reasonable cause to believe that the developer did not put genuine work or effort into the project and rather is attempting to sit on the merits of assets that somebody else made.
This means that I don't consider PUBG an asset flip. While PUBG does use a lot of pre-built assets, I think that the developer has clearly put in effort to make the assets they did use coherent, well-assembled and overall it comes together in a cohesive gameplay experience that a hell of a lot of people enjoy.
Digital Homicide's infamous title The Slaughtering Grounds is something that I would consider an asset flip, since the gameplay experience is far from cohesive, feels cheap and I get the impression that the assets are the only thing the game has going for it and Digital Homicide know it. They're attempting to score a few bucks from people who take a quick look at the competently built assets and decide that they'd buy it.
However, that's not the end of the story for the term "asset flip". There's an effort in some strange part of Twitter to actually re-brand "asset flip" as a neutral or even positive term to describe basically any game that uses pre-built assets. In so far as that goes, I think that's the wrong way to approach things. The fact that "flipping" already exists as its own derogatory term in the real world makes it a thousand times harder to re-brand asset flipping in consumer's eyes.
Also, defining "asset flips" as any game that uses a pre-built asset is kind of crazy and not only de-values the term, it actually shuts out smaller indies who might not be able to afford or otherwise accomodate a full-time artist and opt instead to purchase assets that they like from the Internet. If consumers think that using any pre-built asset is bad(which they pretty much do at this point), then I can't see that ending up as good for really anyone.
So in closing, I've got one more thing to say. I opt to not even say "asset flip" very often since there's a lot of controversy and confusion about what the term even means. I think a more useful and accurate term in most discussions(such as the whole Steam clutter problem thing) is to just say "bad game". Not all bad games are asset flips- in fact a lot of them aren't. Asset flips suck, but they're a subset of the larger issue which is low-effort and dishonest titles getting onto Steam and making things harder for everybody.
Anyway, thanks for watching and stay tuned for more videos that will probably make people mad at me in the comments section because this is a properly controversial topic.
Monday, 23 July 2018
Why Godot 3.1 Is Something To Be Excited About
So we got Godot 3.0 a few months back and this has proven to be a massive upgrade to the engine, I mean jeez Godot 2.1 feels awful, clunky and awkward in comparison.
However, we're about to get a new version of Godot 3.0, which as you might have guessed is named "Godot 3.1". This version is, in my opinion, at a similar hype-level to Godot 3.0, when that was just about to be released.
One of - if not THE - biggest reason why I think Godot 3.1 is gonna change things is the AnimationPlayer node. Currently, the AnimationPlayer involves putting keyframable properties into a timeline, each represented by little dots. These can be interpolated continuously, linearly, cubicly or not interpolated at all, and just represent discrete state changes.
This works pretty well and I love the AnimationPlayer node as it is, since it's a really intuitive way to change properties over time. However, it's about to get a hell of a lot better.
Firstly, you can put Bezier curves directly into the animation. This is awesome since it means that you no longer have to rely on messing around with cubic functions, you can directly control the Bezier curve for pretty much any numerical value. As it should do, this makes animations a LOT easier.
Additionally, you can now use AnimationPlayers to set frames of Sprites. This is also pretty cool since it even gives you a lovely preview of the frame you're placing at that specific point in time. This means that you can much more intuitively create sprite animations with potentially varying framerates for each frame, if for instance you just wanted to place the keyframes down and work out the interpolation frames at a later date for the sake of prototyping.
Also, the AnimationPlayer will feature DAW-like audio processing(with preview waveforms and everything), capture mode, track copying/pasting, visual method selection for callback tracks, and probably more stuff but I can't dedicate this entire video to the new AnimationPlayer node.
So what else is there in 3.1? Changes to KinematicBody nodes, which are going to be awesome. The first of which is "snapping", which involves sticking a character to the ground as they move along slopes and things, so that momentum won't launch them off as they get to the top.
Also, some changes to how RayCasts work with KinematicBodys, which allows for some tricks to make the player movement speed constant when moving up and down slopes.
Also, something which is fairly relevant to mobile developers and people with terrible computers is the advent of a new GLES 2.0 back-end. This means that people using computers that do not yet support GLES 3.0 will be able to use the engine again, and also more mobile phones will be compatible with the engine.
The engine will also support exporting with Mono and C# and all that jazz better, but another big one that I'm looking forward to is the optional GDScript typing. This means that finally we can cast a function or a variable to a certain datatype without being FORCED to do so. This makes things clearer for those of us who are fans of static typing, but doesn't upset anybody who prefers dynamic typing. Everyone wins!
There's also the visual shader editor, which took a brief vacation in Godot 3.0 and is now back and better than ever. It's more intuitive, things that can be done automatically now ARE done automatically, and it's a very nice way to interface with shaders.
Also, something which I don't quite understand is the new AnimationTree node and state machines that go along with it. I don't QUITE understand how to set this up but from what I can understand, this looks really useful- especially for things like AI or player controls, and the blend spaces look awesome for inverse kinematics, colour shifting and probably a hell of a lot more.
There are probably a lot more relatively small things that I'm missing out here, but that's the jist of it. I'm seriously looking forward to Godot 3.1 and I think it'll change my workflow for the better.
Thanks for watching, and stay tuned for more videos about the Godot Engine!
However, we're about to get a new version of Godot 3.0, which as you might have guessed is named "Godot 3.1". This version is, in my opinion, at a similar hype-level to Godot 3.0, when that was just about to be released.
One of - if not THE - biggest reason why I think Godot 3.1 is gonna change things is the AnimationPlayer node. Currently, the AnimationPlayer involves putting keyframable properties into a timeline, each represented by little dots. These can be interpolated continuously, linearly, cubicly or not interpolated at all, and just represent discrete state changes.
This works pretty well and I love the AnimationPlayer node as it is, since it's a really intuitive way to change properties over time. However, it's about to get a hell of a lot better.
Firstly, you can put Bezier curves directly into the animation. This is awesome since it means that you no longer have to rely on messing around with cubic functions, you can directly control the Bezier curve for pretty much any numerical value. As it should do, this makes animations a LOT easier.
Additionally, you can now use AnimationPlayers to set frames of Sprites. This is also pretty cool since it even gives you a lovely preview of the frame you're placing at that specific point in time. This means that you can much more intuitively create sprite animations with potentially varying framerates for each frame, if for instance you just wanted to place the keyframes down and work out the interpolation frames at a later date for the sake of prototyping.
Also, the AnimationPlayer will feature DAW-like audio processing(with preview waveforms and everything), capture mode, track copying/pasting, visual method selection for callback tracks, and probably more stuff but I can't dedicate this entire video to the new AnimationPlayer node.
So what else is there in 3.1? Changes to KinematicBody nodes, which are going to be awesome. The first of which is "snapping", which involves sticking a character to the ground as they move along slopes and things, so that momentum won't launch them off as they get to the top.
Also, some changes to how RayCasts work with KinematicBodys, which allows for some tricks to make the player movement speed constant when moving up and down slopes.
Also, something which is fairly relevant to mobile developers and people with terrible computers is the advent of a new GLES 2.0 back-end. This means that people using computers that do not yet support GLES 3.0 will be able to use the engine again, and also more mobile phones will be compatible with the engine.
The engine will also support exporting with Mono and C# and all that jazz better, but another big one that I'm looking forward to is the optional GDScript typing. This means that finally we can cast a function or a variable to a certain datatype without being FORCED to do so. This makes things clearer for those of us who are fans of static typing, but doesn't upset anybody who prefers dynamic typing. Everyone wins!
There's also the visual shader editor, which took a brief vacation in Godot 3.0 and is now back and better than ever. It's more intuitive, things that can be done automatically now ARE done automatically, and it's a very nice way to interface with shaders.
Also, something which I don't quite understand is the new AnimationTree node and state machines that go along with it. I don't QUITE understand how to set this up but from what I can understand, this looks really useful- especially for things like AI or player controls, and the blend spaces look awesome for inverse kinematics, colour shifting and probably a hell of a lot more.
There are probably a lot more relatively small things that I'm missing out here, but that's the jist of it. I'm seriously looking forward to Godot 3.1 and I think it'll change my workflow for the better.
Thanks for watching, and stay tuned for more videos about the Godot Engine!
Subscribe to:
Posts
(
Atom
)