Jump to content
IGNORED

The Game Development Thread


A nice cup of tea
 Share

Recommended Posts

Man camera issues are driving me nuts now. 

 

Had to have a word with myself as I was getting so cross while debugging to no avail! 

 

Basically, I wanted to be able to hold a mouse button, then while moving mouse with button held down, change camera x position. 

 

It seemed to work fine at first. But I noticed if in middle of the map, it would jump to the extreme left / right (and alternated L/Reach time I pressed the button) first. When I commented out the code which restricted camera position to remain within he map, it would madly flick further and further out to the left and right, first by 20 units left, then 50something right, then 180keft, etc etc, it would to crazy huge numbers quite quickly. 

 

Absolutely bizarre, it made no sense to me at all. 

 

Gonna have to try and recreate the behaviour in a blank project and see if I can figure it out. 

Link to comment
Share on other sites

update! Not much visually looks different but!

 

  • Changed controls to single button (thinking about touch), touch to pan camera, touch ball to aim
  • Button to return to ball after panning
  • Can cancel shot by moving back to ball before releasing button
  • Angle of shot shown
  • Changed power/angle to dim when ball is moving (i.e to indicate you can't start aiming next shot yet)
  • Added 'rough' which is about halfway between green/sand in terms of material effect
  • Reworked all the particles to make them look better
  • Made a class containing course info, e.g. dimensions etc, so should be able to have courses of any size now and game will handle them. 
  • Properly pulled out all input / ball / camera updates into individual scripts for tidiness :)

 

 

Next feature is slight randomisation to angle/power when hitting ball out of sand/rough. :D

 

Link to comment
Share on other sites

Got the zoom working!  Well, kind of.  Zooming out is fine, but the zoom in shows tiny bits of out of bound areas unless I hack the speed, which makes it look less good.  Need to investigate how to do it better. 

 

But... I've found a new distraction.  I was doing some reading on doing parallax in 2D games, then came across some tutorials for the terrain editing / 2.5D.. oh my golly this looks good!  So now am going to spend some time messing about with Unity's terrain and sprite shapes :wub:

 

 

Link to comment
Share on other sites

@robdood

 

I was inspired by your posts to look into orthographic cameras because of something I'm dabbling with currently (I may post about it very soon). I found this, which may be of use. It's a bit slow, but it covers pretty much exactly what you're doing, I think. Also explains stuff that would never have occurred to me, having dealt only with perspective cameras so far.

 

 

Link to comment
Share on other sites

Well I've had an interesting evening experimenting with these new fancy pants tools. 

 

Though now I've got curved surfaces, it's really hard to get the ball physics to feel 'right'..  Like, it feels like it should come to rest on very gentle slopes but doesn't by default. 

 

Did some research and it seems simulating a rolling ball accurately, at low speeds, is one of the things game physics is notoriously shit at. Ffs! A bit disheartening, tbh. 

 

However, I'm undeterred. I kinda enjoy the cowboy hackiness involved. I've almost sussed it. For fairways. Lol. 

 

Setting my own expectations that the next few dev sessions are purely going to be about tinkering with how the ball feels on different surfaces and slopes.  No point doing the rest if I can't get that feeling right!

 

(I mean this was also true in my more 'angular' first project, but didn't feel as obvious, the 'game' was about reaching flat areas accurately, which may end up being more fun, we'll see, I guess!) 

Link to comment
Share on other sites

Yeah. I've played around with balls (he he) and physics and it's hard to get the results you're after. It's well worth googling very specific questions to get pointers to nudge you towards where you want to be. My memory is atrocious, but there are settings you can play with that make it a bit more manageable. PhysicMaterials might help too, but I've got an even shonkier grip on them than I have on the settings.

Link to comment
Share on other sites

8 hours ago, MarkN said:

Yeah. I've played around with balls (he he) and physics and it's hard to get the results you're after. It's well worth googling very specific questions to get pointers to nudge you towards where you want to be. My memory is atrocious, but there are settings you can play with that make it a bit more manageable. PhysicMaterials might help too, but I've got an even shonkier grip on them than I have on the settings.

Physics materials (in 2D) are pretty useless for anything but bounce.  The friction coefficient seems to make very little difference whether it was on 100 or 100000!

 

However, angular drag is a good one (though spoils how the ball appears to 'roll', so it looks wrong), combined with some checks to force the physics to 'sleep' when certain low angular/linear velocity thresholds are crossed. 

 

Just that the knock on effect of those hacks is suddenly I can't hit the ball at all in some situations! :D

 

Ahhhh gamedev. 

 

Link to comment
Share on other sites

On 17/01/2021 at 16:05, MarkN said:

Get() and Set() functions feel like you're doing the right thing,

 

Not in C# they don't!

 

public int MyVariable { get; set; }

 

That's equivalent to a private member variable with separate get/set methods. Though even then, for most usage, you're absolutely fine with

 

public int MyVariable;

 

The main reason to use the automatic get/set notation is if you want to control access - a private set would ensure outside code can't modify an object's variable. Technically it's also useful if you're writing an API, but that's not applicable here.

 

But yes, generally I agree with the thrust of your post. Getting the simplest thing working will allow you to rapidly advance the game and get to the meat of it. A lot of the advantages of doing things "the correct way" also don't really become apparent until you're a more experienced coder, and until that occurs they'd just serve to frustrate and demoralise you. There's more value in doing things the "wrong" way and then eventually - if at all - bumping up against the limitations of the approach. 

Link to comment
Share on other sites

13 hours ago, Padaxes said:

Looking good,  have you dabbled with multi-touch yet?  Good idea if you are planning on moving to mobile.

Not yet! It's in the todo list though. 

 

Tinkering with the physics is so cowboy. But I'm loving it. 

 

I've now found a decentish solution that involves ignoring the unity variables of angular/linear drag, instead reducing those velocities by a % each frame (edit shit, this needs delta timing) while touching the course collision boxes. Works great uphill! Downhill, not so much. Need to figure that out somehow, not sure how yet. Gonna involve checking that we're moving negatively on Y axis and applying a stronger slowdown rate, perhaps. 

 

Need to tie the slowdown % to surface type, and also only apply the slowdown on flat or very shallow gradients.

 

Getting there! 

Link to comment
Share on other sites

Another good day of tinkering, almost ready to start making the main menu properly and plug the game manager into everything, then I can design some courses! :D

 

 

Much prefer my flat billboard hills in the background than the terrain I was using before. :) also pleased with the dynamics location of the power/angle meters, and the cancel shot circle. 

Its also super satisfying ticking things off my to do list and watching the completed items stack up! 

 

Loving it! 

 

 

Link to comment
Share on other sites

Be patient with it. I find game development often starts with a frantic burst of productivity before you hit a wall, which can happen due to hitting a technical barrier you need to overcome, finding a gap in your knowledge, or having to do something you enjoy a lot less but which is necessary for the game to really feel good.

 

This can happen even more so with Unity because it's so quick to get initial results, it feels like it accelerates the whole slamming into that wall.

Link to comment
Share on other sites

Oh I'm not going to give up!! I kind of know what I need to do, it's just going to take a lot of time and thought.  I kinda wish I'd approached it form this point of view from the beginning, but it's fine, it's a learning curve I'll only have to climb unprepared the once :)

 

There's defo a gap for this kind of object-orientated tutorial on the old youtubes though. 

 

 

Link to comment
Share on other sites

I think we've all been there, and learnt that lesson. I do try to be quite formal now when setting up a new project as I think I mentioned before, and get a game manager and a front end manager in from the start. The main thing I do early on is set up an enumeration of states for each - so the game manager will have states like initialiseLevel, inPlay, levelComplete, and frontEnd. Then there's just a switch statement that tests what the current state is and runs methods that update it (if it's frontEnd it'll be doing nothing because the baton has been passed to the front end Manager (this will have states for the different menus so they can likewise be handled individually, and also one called inGame, where it does nothing because control has passed back to the game manager). Apologies if that's completely irrelevant for you, but I find it a nice quick way to get organised at the start.

 

FWIW, I've hit a similar wall with my main project where I'm having to learn Unity's UI properly, and it's really frustrating because every time I solve one small problem I just immediately hit another (part of the problem is there's so much cool stuff I want to be working on, but the UI is a huge part of the game, so I want to get that done now, so each time I hit a new issue it just feels like a smack in the face). (In the past I've fudged UI using simple UI text objects rather than buttons (or 3d objects as with my Picross game), but I think that would be a bad solution here). So I find myself tinkering with a completely different project instead right now, with no idea if anything will come of it.

Link to comment
Share on other sites

1 hour ago, MarkN said:

e main thing I do early on is set up an enumeration of states for each - so the game manager will have states like initialiseLevel, inPlay, levelComplete, and frontEnd. Then there's just a switch statement that tests what the current state is and runs methods that update it (if it's frontEnd it'll be doing nothing because the baton has been passed to the front end Manager (this will have states for the different menus so they can likewise be handled individually, and also one called inGame, where it does nothing because control has passed back to the game manager).

Yep, this is basically where I am.  

 

Its that realisation that not enough initialising is done in a 'good way' in code..  Too many GetComponent<>() calls that will be getting me the wrong values, need to plan and write out the init functions and stuff. 

 

Fuck it though, it only really irks me because I can't make quick progress due to having partner/kids to tend to - I WANT TO JUST DIVE IN AND DO IT TIL ITS FIXED. :D

 

Link to comment
Share on other sites

@robdood I do use GetComponent() to find very common scripts where there will only ever be one of them (my game manager, front end manager, and global scripts, mainly, and those are done once in the Start() method of whatever object needs them and stored for later). Other than that, if I have one-off objects they're almost always part of the scene, so can be dropped on to any script as a public variable (either just a GameObject that I can use GetComponent() on to find the script, or actually as a script in which case you can just get right at all the public stuff without bothering). Also, FWIW, I tend to only have one scene in a project. Everything I do is fairly efficient, so I just skip the whole process of using different scenes, and do everything with instances of prefabs. In which case you can just use GetComponent() when you Instantiate them and store that for later use. (I may well be doing loads of stuff wrong, but it's worked well for me so far.)

Link to comment
Share on other sites

Yeah, I'm going for that approach this time.  Last week when I hacked together 3 courses and a title screen, each was using its own scene, which just seems more complicated than it needs to be for such simple stages.  My project hierarchy looks a bit like this:

 

image.png.a6f461c82ef58d78641b753c7647ba65.png

 

The enabled stuff at the top is 'common' across all gameplay parts of the game, I'm going to use the game manager to read / store arrays for each course & its holes, then enable/disable them as required.  I've tried to make things straightforward and atomised enough that I can design a new course, and then it should have all the data it needs to know where things go (e.g. tee off position) based on the locations of objects within each course/hole object.   Hopefully I can do all the course design in the editor/inspector, once I get it done!

Link to comment
Share on other sites

That looks pretty close to how I'd do it. For things like the ball, and the BG scenery (which I might be wanting to change from level to level, or to allow different looking balls or whatever) I'd probably make them prefabs, and Instantiate the ones I wanted when a new hole/course is started. It would also keep a few things out of your scene, which can be helpful (although mine are generally a mess, tbh). But for one of my current projects I've got a whole load of maps and they just sit deactivated in the scene until I need them - just like you have there. As long as they're not using too many resources it works a treat, and has the benefit of needing no pauses for loading. 

Link to comment
Share on other sites

Yeah, I might look at backdrop prefabs a bit later, for now happy to just have the same one the whole time tbh :D

 

Just realised I've gotta pull   out so much stuff from the 'ball', since it is where score/etc is tracked. Eek!

 

Gonna be satisfying when done though!

 

Link to comment
Share on other sites

On 18/01/2021 at 00:12, robdood said:

...spent ages moving code around, renaming & breaking things, taking ages to fix them, then had an undo / mass replace fail which meant I had to redo loads! Sigh. 


This is going back a bit in your journey but I’m only just catching up. However, are you using version control system (like GIT)?
 

If not you really should consider it as it gives you the freedom to use branches to experiment with new ideas, refactor, break things, etc... all while having the peace of mind that your Master branch is still intact and working.

Link to comment
Share on other sites

1 minute ago, FiveFootNinja said:


This is going back a bit in your journey but I’m only just catching up. However, are you using version control system (like GIT)?
 

If not you really should consider it as it gives you the freedom to use branches to experiment with new ideas, refactor, break things, etc... all while having the peace of mind that your Master branch is still intact and working.

Aye, I've used git from a non-dev perspective in work, and am going to experiment once I've finished this next big batch of dev.  Version controls  (and online code backups!) are super useful!  Though using it is another learning curve for me, one thing at a time!

Link to comment
Share on other sites

Yeah there is a bit of a curve there but I’d definitely recommend it, even if just for basic commits and branches initially.

 

The GameDevTV lot teach it alongside the Unity basics as it gives you more creative freedom and means you can “fail fast” on ideas without compromising your working code (or rely on mass undos).

 

It also means you can - if you are so inclined/disciplined - have a couple of ideas branches on the go at once to allow yourself a bit of headspace on a project (e.g. get the camera zooming bit started, get annoyed, and leave it for a bit and do some other stuff like UI and then come back to it). You just need to make sure you don’t end up with a huge collection of unfinished ideas/branches knocking about (I give myself a max 3 limit).

 

I really want to get back into this again. I had a really good stint learning it in early 2019 but it’s been mostly parked since the middle of that year due to work/family/life/covid/etc... If you get in the zone I found it really rewarding, especially as a bit of a tonic from the programming I do as a day job.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Use of this website is subject to our Privacy Policy, Terms of Use, and Guidelines.