[HariSeldon]

When will you move to UE5 and use Lumen?

When it's retro.

Made a start last night on my first attempt at something in Unity with no tutorials, no hand-holding. It's Breakout, of course, what else would I choose? Well anyway I've got a basic title screen in, and switching into the game screen, and I've made a few assets to get the job done and got some game objects in place. Likely I'll get the basic Breakout concept working with a single proof of concept level first, but then I'm thinking I might go a bit Jeff Minter on this thing.

- Add in a ufo popping up and wandering around the screen trying to shoot your bat, you can only kill it by hitting it with the ball.
 - Arkanoid style power ups to do random shit:
   - wider bat
   - reversed controls
   - Two bats but one goes the opposite way
   - Multiball
   - Spawn a monster sheep that eats the bricks - as you move the bat left and right that steers the sheepdog that herds the sheep - some bricks are poisonous and will kill the sheep
   - Space invaders mode - simultaneously keeping the ball in play while also firing bullets at aliens coming down, dodging the aliens bullets

Should be a good workout I reckon, and get me some decent familiarity with the tools before I switch to 3D for my next test project.

 

[Stifler's Mom]

For sure I'd use C# any time as it's as lovely as Java, but that would also likely necessitate working in Windows which I don't absolutely love.

I do all the conversion scripting for my games in C#. Using Mono on my Mac. Works like a charm.

Not sure how that integrates with the lib you use, though.

 

[HariSeldon]

I do all the conversion scripting for my games in C#. Using Mono on my Mac. Works like a charm.

Not sure how that integrates with the lib you use, though.

Not well I suspect but I'm currently investigating Unity as a better option as LibGDX is an absolute pain in the balls when it comes to 3D. It can do it but it requires an incredible amount of masochism.

 

[Stifler's Mom]

Not well I suspect but I'm currently investigating Unity as a better option as LibGDX is an absolute pain in the balls when it comes to 3D. It can do it but it requires an incredible amount of masochism.

I searched for an engine to teach a bit of game dev to my ten year old son, and someone recommended "Godot" to me.

It's completely free and it seems you can do some really decent stuff in it.

 

[HariSeldon]

I searched for an engine to teach a bit of game dev to my ten year old son, and someone recommended "Godot" to me.

It's completely free and it seems you can do some really decent stuff in it.

Yeah Godot is cool. I went with Unity as my second choice after LibGDX as in code it pays to follow the crowd. It means lots of people to ask questions, lots of quality documentation (tbh the Unity docs are MUCH MUCH BETTER than the shite LibGDX ones - tbh a common problem with open source stuff if there's not corporate backing), etc.

 

[HariSeldon]

I searched for an engine to teach a bit of game dev to my ten year old son, and someone recommended "Godot" to me.

It's completely free and it seems you can do some really decent stuff in it.

Btw for a 10 year old I'd probably suggest something like Game Maker Studio. OO programming is a fucking nightmare for kids to understand, where GameMaker uses its own proprietary language that's a bit more procedural. Now obviously it's not something he'll use in the real world (outside fo the fact that commercial games have been made in GM) but the important job it does is in building an understanding of code and logic. Unity is great for me, I'm a programmer anyway so the round the houses ways of grabbing data make sense to me, but for a kid you want something a bit morer sensible.

 

[Stifler's Mom]

Btw for a 10 year old I'd probably suggest something like Game Maker Studio. OO programming is a fucking nightmare for kids to understand, where GameMaker uses its own proprietary language that's a bit more procedural. Now obviously it's not something he'll use in the real world (outside fo the fact that commercial games have been made in GM) but the important job it does is in building an understanding of code and logic. Unity is great for me, I'm a programmer anyway so the round the houses ways of grabbing data make sense to me, but for a kid you want something a bit morer sensible.

Godot also seems to use C#

I will just create one function and explain basic program flow to him in there. No OOP stuff.

 

[HariSeldon]

Godot also seems to use C#

I will just create one function and explain basic program flow to him in there. No OOP stuff.

Yep, that's why I suggested GML. Tricky bit is there's not much way to avoid objects in C# really. If he's already coding then fair enough, crack on, but consider lines like Vector3 position = Camera.main.WorldToViewportPoint(transform.position) or gameObject.GetComponent<Rigidbody2D>().velocity = new Vector2(UnityEngine.Random.Range(-3f, 3f), 3) in C# in Unity - that shit will put kids off. I'd be surprised if Godot had a magical way around that kind of stuff.

In news of my progress, I've been learning my way around Unity and getting more comfortable with it, making a Breakout game as I mentioned earlier. Tbh last time I tried making a game properly was the mid-90s. When I've tried more recently I've done the tutorials, got something working, got fed up eventually usually at the point in LibGDX where I was trying to sort out multiple scenes, level loading, all that kind of bollocks. Unity really lets me work much more effectively. Not had huge amounts of time yet but I've got the bat moving around with the ball and releasing it, bouncing off walls, which I'll likely re-use once I get to bricks. The bounce off the bat is a little different obviously as you want to bounce in different directions depending on where it hits the bat. Interestingly the physics are NOT suitable for Breakout, so I had to manually handle changing the velocity of the ball when it hit the sides of the screen.

 

[HariSeldon]

Eugh. Physics. For those not following I took a bit of a side turn to learn Unity and am doing some simple 2D projects to get my head around it, then some 3D, then back to Mega-Lo-Monger. Right now I'm doing a Breakout clone.

So I've had a bit of time doing other things but got back to it today, trying to get the damn game working. So I've got the basic objects to get the job done.
- A camera. It has an AudioListener.
- A single brick which I've not yet done any actual work on but it'll form the blueprint for other bricks once I'm happy with its behaviour.
- A bat which moves left and right with the mouse (a script attached simply runs camera.ScreenToWorldPoint(Input.mousePosition) to get the position and I apply it to the gameObject.transform.position). I also added some tools to change the bat size since I expect that to happen with power-ups. It has a sprite renderer which loads a 9-sliced sprite allowing for resizing without losing quality. It has a RigidBody2D. I have my suspicions that this is a bad idea.
- A ball. It has the most complex script. It has a RigidBody2D and a CircleCollider2D. Again I feel like the RigidBody2D may be a bad idea. The SpriteRenderer is simply rendering a ball.

Unity professionals would probably look at what I've done and call it shite, and they'd be right, but this is early learning shit code. I'll find more efficient ways to do things in due course. The ball was happily bouncing off the walls, and has now decided it no longer wishes to do so. The event triggers, it's in my logs, but though I change the ball's RigidBody2D's velocity it still keeps moving the exact same direction. This is a pain in the balls.

Now I'm avoiding tutorials to keep out of the trap of following people's code and learning nothing, so I've been googling questions when I have them (how to check what an object is colliding with, how to get the position on screen without things exploding when window size changes, etc). This means I'm making a lot of stupid mistakes, but they're useful as I'm learning from them.

My gut feeling is I've got this quite badly wrong. Breakout doesn't really have physics in a real sense. Objects don't have weight, so when they collide energy is not absorbed, the bat isn't moved when the ball rams into it for instance. The edges of the screen don't absorb the impact at all so the ball just bounces perfectly off it. The bricks will do the same. Real physics will try to split the energy between the collider and collided objects, which isn't what I want. So, google time.

Looked around at some tutorials as I concluded I've done this horribly wrong and came to realise everyone's using PhysicsMaterials which actually let you do some fairly unrealistic things with your physics objects. Not so far off after all. Turns out I've been scripting far too much of this behaviour too - I suspect my scripting is fighting with the physics and I need to do one or the other, not both. Ultimately I've carried LibGDX habits into Unity, as in Java I have to build everything, but Unity expects you to work with what it provides, and that's taking a little bit of getting used to.

Taking that physics approach I now have a ball bouncing around the screen in a fairly Breakout-y way, but I'm dissatisfied with how the deflections off the bat are handled. I want it to go different directions depending on where you hit the bat as in traditional breakout. I've seen an approach of a polygonal sloped collider but all that does is go left on the left and right on the right, with no nuance as to how far along you hit it. An oval collider would be lovely, sadly it looks like you can only have polygon, rectangle or circle colliders (and you can't distort the circle). A pill is available, it's not perfect, but for now it'll do so I can get on with more important things. No point getting bogged down.

Onwards and upwards.

 

[Stifler's Mom]

Eugh. Physics. For those not following I took a bit of a side turn to learn Unity and am doing some simple 2D projects to get my head around it, then some 3D, then back to Mega-Lo-Monger. Right now I'm doing a Breakout clone.

So I've had a bit of time doing other things but got back to it today, trying to get the damn game working. So I've got the basic objects to get the job done.
- A camera. It has an AudioListener.
- A single brick which I've not yet done any actual work on but it'll form the blueprint for other bricks once I'm happy with its behaviour.
- A bat which moves left and right with the mouse (a script attached simply runs camera.ScreenToWorldPoint(Input.mousePosition) to get the position and I apply it to the gameObject.transform.position). I also added some tools to change the bat size since I expect that to happen with power-ups. It has a sprite renderer which loads a 9-sliced sprite allowing for resizing without losing quality. It has a RigidBody2D. I have my suspicions that this is a bad idea.
- A ball. It has the most complex script. It has a RigidBody2D and a CircleCollider2D. Again I feel like the RigidBody2D may be a bad idea. The SpriteRenderer is simply rendering a ball.

Unity professionals would probably look at what I've done and call it shite, and they'd be right, but this is early learning shit code. I'll find more efficient ways to do things in due course. The ball was happily bouncing off the walls, and has now decided it no longer wishes to do so. The event triggers, it's in my logs, but though I change the ball's RigidBody2D's velocity it still keeps moving the exact same direction. This is a pain in the balls.

Now I'm avoiding tutorials to keep out of the trap of following people's code and learning nothing, so I've been googling questions when I have them (how to check what an object is colliding with, how to get the position on screen without things exploding when window size changes, etc). This means I'm making a lot of stupid mistakes, but they're useful as I'm learning from them.

My gut feeling is I've got this quite badly wrong. Breakout doesn't really have physics in a real sense. Objects don't have weight, so when they collide energy is not absorbed, the bat isn't moved when the ball rams into it for instance. The edges of the screen don't absorb the impact at all so the ball just bounces perfectly off it. The bricks will do the same. Real physics will try to split the energy between the collider and collided objects, which isn't what I want. So, google time.

Looked around at some tutorials as I concluded I've done this horribly wrong and came to realise everyone's using PhysicsMaterials which actually let you do some fairly unrealistic things with your physics objects. Not so far off after all. Turns out I've been scripting far too much of this behaviour too - I suspect my scripting is fighting with the physics and I need to do one or the other, not both. Ultimately I've carried LibGDX habits into Unity, as in Java I have to build everything, but Unity expects you to work with what it provides, and that's taking a little bit of getting used to.

Taking that physics approach I now have a ball bouncing around the screen in a fairly Breakout-y way, but I'm dissatisfied with how the deflections off the bat are handled. I want it to go different directions depending on where you hit the bat as in traditional breakout. I've seen an approach of a polygonal sloped collider but all that does is go left on the left and right on the right, with no nuance as to how far along you hit it. An oval collider would be lovely, sadly it looks like you can only have polygon, rectangle or circle colliders (and you can't distort the circle). A pill is available, it's not perfect, but for now it'll do so I can get on with more important things. No point getting bogged down.

Onwards and upwards.

Hmm, I wouldn't avoid tutorials completely. Almost all of these problems have been solved, and you usually come up with worse solutions than what has been found out before for game physics.

Just my experience and 5 cts.

And on Breakout, I have done a clone for the Vectrex many years ago, and it was basically just that the spot where the ball hits the "bat" changes its trajectory. Other than that the ball always does the same entry/leave slope. That's how I did it, anyway.

 

[HariSeldon]

Hmm, I wouldn't avoid tutorials completely. Almost all of these problems have been solved, and you usually come up with worse solutions than what has been found out before for game physics.

Just my experience and 5 cts.

And on Breakout, I have done a clone for the Vectrex many years ago, and it was basically just that the spot where the ball hits the "bat" changes its trajectory. Other than that the ball always does the same entry/leave slope. That's how I did it, anyway.

There is method to the madness re tutorials. I don't deny that there are good ones out there that can shortcut how to do something but I want to build my own power to be able to handle most things and just do an occasional search of stackoverflow to figure out small snippets. The problem with tutorials is that you end up copying code and then having no idea how you got there. Information goes in one ear and out the other.
Where they are useful is once I've tried it, got a bit stuck, but at least understand the problem space a bit, I can quickly skim a tutorial to see if there's some other pattern or different resources they're using, which is how I found PhysicsMaterial in this case.
Had a bit of a think overnight - I put in a temporary solution of just a pill collision object, which at least sent the ball flying at the ends but as you observe that's not really the breakout way. As such it should go to the right if the ball lands on the right of the bat, left on the left, and the angle should increase as you get closer to the edge. This could be solved with an oval collider but no such thing exists. I had an initial idea that maybe I'd make a trigger collider, ie no physics and I can implement the reflection there but that brings some issues where the ball may become stuck in the bat or even pass through it, which clearly sucks. However I then realised I'm an idiot, and that I can detect a collision with the bat even as a proper physics object, so I can at that moment adjust the ball's velocity. The fun bit will be maintaining the same speed as I have to bleed off vertical velocity if I want to add horizontal velocity. Likely some trigonometry will help. All this was in my head at 3am, as is the way with these things.

 

[Stifler's Mom]

As such it should go to the right if the ball lands on the right of the bat, left on the left, and the angle should increase as you get closer to the edge. This could be solved with an oval collider but no such thing exists. I had an initial idea that maybe I'd make a trigger collider, ie no physics and I can implement the reflection there but that brings some issues where the ball may become stuck in the bat or even pass through it, which clearly sucks. However I then realised I'm an idiot, and that I can detect a collision with the bat even as a proper physics object, so I can at that moment adjust the ball's velocity. The fun bit will be maintaining the same speed as I have to bleed off vertical velocity if I want to add horizontal velocity. Likely some trigonometry will help. All this was in my head at 3am, as is the way with these things.

Can't you just brute force check for coordinates and do your own hit boxes and then your own math?
Sounds much easier than trying to get engine physics to do stuff like this...

 

[HariSeldon]

Can't you just brute force check for coordinates and do your own hit boxes and then your own math?
Sounds much easier than trying to get engine physics to do stuff like this...

Can do, but there are collider objects that can be set without physics etc. The brute force approach might not work so well as I plan multibat and multi ball stuff as well so it might get a bit expensive. Also I'm trying to do things the way the engine expects where I can, fit existing dev conventions.

 

[HariSeldon]

So I've made some progress with Breakout - excuse the programmer art. We now have a bat and ball that work as they should, and bricks as a prefab - they can be dotted around and my generator will place them on a grid with health amount and colour.



Next job is to have levels load from a file to make them a bit easier to create, and then I can start on power ups, audio, scoring, etc. I probably need to tweak the speed up after you hit a brick…

 

[HariSeldon]

We now have multiball. Had to rewrite quite a few things since the ball looks for the bat on first creation to attach to it before you fire it off. I plan to have multiple bats and multiple balls so needed to break the link a little. There will still be a main bat, so the attached ball will still look for that, but new balls are created unattached and are given a random velocity to kick off with.

Power ups will enlarge or shrink the bat (already the bat can have its size changed with keypresses for debug so that's working), add additional bats (say one going the wrong way, one going vertically, one with the bounce direction reversed...), add additional balls, space invaders mode, all the fun stuff you'd expect. Really learning a great deal from doing this, and hopefully once I have something done I'll put it on a Itch.io for you guys to have a look at if you're bored as hell one day.

Did some groundwork for loading levels from a file but I'm going to push that back a bit - first figure out what kind of things I want in a level - do I want indestructible items that don't count towards the need to destroy all the bricks for example?

 

[Soodanim]

Mate, you haven't finished this yet? More like HariSeldomDoesAnyFuckingDevelopment

 

[HariSeldon]

Mate, you haven't finished this yet? More like HariSeldomDoesAnyFuckingDevelopment

I get about half an hour some evenings when the baby's in bed. The pace is slow. That and I'm learning Unity so it's a lot slower than I'd be in a framework I know well. That said I'm definitely getting faster. Got a fairly big job done tonight in a fairly short time.

 

[Soodanim]

I get about half an hour some evenings when the baby's in bed. The pace is slow. That and I'm learning Unity so it's a lot slower than I'd be in a framework I know well. That said I'm definitely getting faster. Got a fairly big job done tonight in a fairly short time.

I respect the dedication, a long term project in a new engine is a hell of a thing to undertake when you have a child. I need to catch up on the thread, looks like some interesting stuff from a quick skim

 

[HariSeldon]

I respect the dedication, a long term project in a new engine is a hell of a thing to undertake when you have a child. I need to catch up on the thread, looks like some interesting stuff from a quick skim

It's a big job definitely. I found LibGDX just wasn't up to what I wanted to do hence the switch. This Breakout project is a quick sidequest to build up some XP before I tackle the main story.

 

[Grumpy Karen]

Mate, you haven't finished this yet? More like HariSeldomDoesAnyFuckingDevelopment

Ugh. I bet there's going to be a game delay announcement at some point.

It's like Molyneaux all over again.

 

[HariSeldon]

Was going to call it a night but decided to add multibat capabilities. Added the first type - the one going the wrong way. Currently adding bats and balls is trriggered by hitting keys, just for debug, but that'll be fired by powerups in due course. Need to add some more bats of course, but the separation is working and it's all hanging together reasonably well at this point.

 

[Stouffers]

Why is there not a legit Lego free build game?

 

[HariSeldon]

Minor update today. I added some UX elements to display the score and lives, and they are now incrementing and decrementing appropriately. As a bonus, the score goes up faster if the ball is moving faster, incentivising hanging on with a faster ball (it gets faster after each brick hit). Somewhere I need to get some feedback when you're on an epic run, think how Bejeweled used to play the voice when you had a nice run, but it's all basics right now, the spit and polish comes later.

I'm going to push power ups back a bit - I want to end state the game, and to handle level completion by going to the next level, though the latter may require storing level information in resources, and loading from those resources so that's probably a two-part job.

 

[HariSeldon]

So I'm thinking it's time to start digging into 3D stuff. I'm feeling reasonably happy that I can build stuff in 2D, but I'm an impatient son of a bitch and I want to build some 3D stuff. First focus is definitely the 3D landscape, for which I need to be able to build meshes custom. There's some built-in landscape stuff in Unity which is fine but it doesn't look like it'll do what I want in terms of making that very low-poly 16-bit style landscape. I'm gonna go custom motherfucker.

So, I went in search of tutorials, which I'm aware goes against everything I've said up til now, but I want to get a handle on the rough method of how others have solved the problem of making custom meshes with code. Had a look around and holy fuck I found a tutorial that didn't suck donkey balls.



Planning to do some experiments just rendering a few shapes and thinking about how my rendering routine might work, then I'll take a look at a later video in the same series...



... to see if there's anything useful I can learn. Time to make this motherfucker happen.

Oh and I'll likely also have a look at another tutorial for colouring based on height etc...

 

[regawdless]

So I'm thinking it's time to start digging into 3D stuff. I'm feeling reasonably happy that I can build stuff in 2D, but I'm an impatient son of a bitch and I want to build some 3D stuff. First focus is definitely the 3D landscape, for which I need to be able to build meshes custom. There's some built-in landscape stuff in Unity which is fine but it doesn't look like it'll do what I want in terms of making that very low-poly 16-bit style landscape. I'm gonna go custom motherfucker.

So, I went in search of tutorials, which I'm aware goes against everything I've said up til now, but I want to get a handle on the rough method of how others have solved the problem of making custom meshes with code. Had a look around and holy fuck I found a tutorial that didn't suck donkey balls.



Planning to do some experiments just rendering a few shapes and thinking about how my rendering routine might work, then I'll take a look at a later video in the same series...



... to see if there's anything useful I can learn. Time to make this motherfucker happen.

Oh and I'll likely also have a look at another tutorial for colouring based on height etc...

 

[HariSeldon]

Walked through those tutorials only to find the bits on shaders were all wrong, had to go do a bit of research around that to get a better understanding but still much to learn on the topic. Still, I picked up enough information to be able to push out a mesh and put colours on the vertices to which a shader can fill in the gaps.

My terrain generator is working in 3D - currently using random generation but I plan to update it a bit to read the terrain in from a file, and to make the shaders a bit more sensible in terms of not interpolating from vertex to vertex but rather having a consistent colour for each triangle. Getting there. Random height map looks a bit ugly and pimply without really having a proper landscape flow, such is life, but hand-built levels will look much nicer. I'll have to carefully lay flat areas for villages to form, and create suitable places for roads to join villages to each other, etc.

 

[HariSeldon]

Having to bite the bullet and learn shaders. I've managed to avoid it so far but having gone through the pain of figuring out generating meshes, and having them render with correct normals etc, it's time to learn shaders.

I started with pixel shaders..

A Beginner's Guide to Coding Graphics Shaders | Envato Tuts+

Learning to write graphics shaders is learning to leverage the power of the GPU, with its thousands of cores all running in parallel. It's a kind of programming that requires a different mindset,...

gamedevelopment.tutsplus.com

.. which was quite fun and gave me a solid account of doing interesting things with videos and images, playing a bit on https://www.shadertoy.com - I was able to mix and match, remove greenscreen, etc which I'm quite pleased with. Next job is to figure out how vertex shaders work.

EDIT: Unity Shader Graph is fucking amazing.

 

[HariSeldon]

So Unity's Shader Graph tool is awesome, no doubt about it, and it's great to use it to noodle around and figure out shaders. I do however still want to get a solid understanding of how it all hangs together under the hood. Got myself some light reading (116 pages actually counts as pretty light reading in the world of code) by getting this...

GLSL Essentials | Programming | Paperback

If you're involved in graphics programming, you need to know about shaders, and this is the book to do it. A hands-on guide to the OpenGL Shading Language, it walks you through the absolute basics to advanced techniques.. 3 customer reviews. Top rated Programming products.

www.packtpub.com

.. so I'll be reading that in bed to get an understanding of GLSL so I can start doing cool things with shaders. Yes I can probably grab shaders off the Unity Asset Store but I don't want to do that. I figure understanding this stuff will give me more control over it and I'll be able to make exactly what I want.