If you’re reading this, there probably aren’t very many posts yet. But don’t worry, you can be the first! Either create a new post or just reply to this one to say ‘hi’.
I didn’t find any existing “general feedback” topic around here except for the early access section, so I think I’m going to hijack this topic to do it. 
I think it might be fitting, since it’s related to the project’s state at this point.
Feedback
So far I’m loving the course. The game I have in mind will be trying to poke fun at RPGs and play with player’s expectations, so I was naturally happy to see Rick & Ben & Mike are also aiming to create a funny, sometimes absurd experience. It had a slower start, of course – there’s a lot of things to consider, a lot of things to set up before delving into a project this big – but in the previous section, we gained momentum and it really felt like we made progress with each video. And now that I caught up with the current stage of the project, I also find I do more things on my own while waiting for new lectures.
If I compare the Complete Unity Developer with the RPG Creator, I’d say the former was more focused on learning and this one on accomplishing something; or getting the knowledge vs. using it. Both are important.
It’s also nice we split focus on big variety of things and even the style of the videos change every once a while (Ben ↔ Rick), so whenever we’re just about to get tired of doing one thing (e.g. specific code, a design aspect), we often move on to do something else. I think Ben and Rick make a great duo and complement each other well; with Rick being crazy creative and enthusiastic, and Ben taking the more organised and methodical approach. And the presentation is engaging and funny, nothing too “complexificated”.
Here’s a list of other things I’ve noted down during the last section.
-
Thanks for the tip to tinker with prefabs and values in unusual ways in order to get an interesting idea. I found out slapping materials on things they weren’t made for can produce quite interesting results.
Say hi to Ethan the Stone Golem, Ethan the Ghost, Ethan the Leaf Spirit and Ethan using a cloaking device.
-
Some quiz questions probably weren’t as important to include in the quiz, and we might not remember the answer if we didn’t watch the lecture they’re referring to recently.
- E.g. “What was the name of a character we mentioned?” (or something like that); “What was the name of the Visual Studio extension we used?” (← useful information, but only once; no need to memorize it)
- The last quiz has just 5 questions, while the previous ones have 10. Just an observation.
- But yes, of course, the next section is going to be BOOOM!
-
Lecture 71 includes importing World Objects 2017-04-05.unitypackage. However, unlike the previous packages, this one contains everything (scripts, characters, scenes; not just world objects which were renamed to environment anyway).
It could – of course – be a deliberate trap to check if we remembered the warning to not import everything a package contains, but otherwise it might overwrite some people’s custom settings, additions to script etc. if they’re not careful. -
◄ Suggestion ►
I really like how Ben takes time to consider things which will make our life easier, like organising folders, refactoring and customising the editor. I remember one of the developers of Ori and The Blind forest stressing how useful it was to write custom editor scripts in order to convert Unity into a machine for producing levels of your game. There was already a lecture about editor scripts (CameraRaycasterEditor?), it’d be cool to see something like that again later on. Property drawers, context menu, or even just built-in attributes to categorize variables, e.g.:public class Player : MonoBehaviour, IDamageable {
[Header("Hitpoints")] [SerializeField] private float maxHealthPoints = 100f; private float currentHealthPoints = 100f; [Header("Combat")] [Range(8,31)] [SerializeField] private int enemyLayer = 9; [Space(10)] [SerializeField] private float damagePerHit = 10f; [SerializeField] private float minTimeBetweenHits = 0.5f; [SerializeField] private float maxAttackRange = 2f; private CameraRaycaster cameraRaycaster; private float lastHitTime = 0f; [Header("Equipment")] [Tooltip("Weapon to hold in the dominant hand.")] [SerializeField] Weapon weaponInUse; // …}
-
◄ Suggestion ►
Do you have any plans to include a lecture about version control, git commands? I think for a project as large as this one, even for solo developers, it could be incredibly useful to learn how to revert changes, look at an older version of a script, etc. -
◄ Suggestion ►
Would it be possible to create a forum category here (such as “Showcase”) specifically for exchanging models, art, code snippets with each other? I have seen people post stuff like that in some topics or in replies (this chicken is probably prettier than my main character will ever be), but it quickly gets buried under the flood of new topics, so this might keep these people who are trying to help others in the spotlight.
Over time, more and more people (me included) might want to come back here and post some self-made assets for others to use if they find them useful.
And also, I thought I’d point out some of the project’s current bugs. I’ve been following the course pretty closely up to this date with just some subtle changes, so while it’s possible I just made a mistake at some point, I’m quite confident the following problems could be in “Project Dragon” as well.
And even though I’m sure @ben would most probably get to fix them eventually, I’m writing this just in case some weren’t noticed yet, or to provide some suggestions. I also don’t want to make large edits or tamper with code which would most probably radically change in further lectures, or would be deleted completely.
Shooting and projectiles
Archer hits himself
Most enemies face towards the player while attacking, but when somebody has greater attackRadius than chaseRadius, they don’t turn to look at the player and try to shoot through themselves – and the projectiles will bounce off.
I put if (isAttacking) transform.lookAt(transform.player) in the Enemy script to fix it, but if we wanted a stationary archer who doesn’t magically know we’re sneaking behind him, we could probably check for an arch instead of full circle as Ben once mentioned.
Deleting old projectiles
While filming the bug above, I left the game open and my RAM nearly started burning of all those 100+ projectiles in the scene. A projectile destroys itself whenever it hits something except an enemy (e.g. the player, a tree, a hill), but if it dodges all that (or if the archer stands on top of a hill) and flies off into the “white void”, it’s stuck in the hierarchy forever, draining memory. So, what about deleting the projectiles when we no longer see them (or 10 seconds after that)?
void OnBecameInvisible() {
Destroy(gameObject, 10.0f);
}
Dead enemy’s projectiles
Projectiles keep track about who shot them – but when we kill an enemy, all his projectiles in the scene are now trying to compare their layer to a null's layer, which spawns MissingReferenceException whenever they collide with something.
Easy way to get rid of the exception is to check for the shooter's existence before checking the layer, but that’s not the right thing to do here because that would make all dead enemy’s projectiles harmless and indestructible.
Destroy delay
This is just something to think about, not really a bug. The documentation says that if distance 1 means 1 m in our game, 1 mass unit should also be 1 kg. I’ve begun to fill in the mass of the rigidbodies in the project, because the main character of my game is going to be a child and I want it to make a difference, e.g. a 32 kg kid (average weight at 10 years) can’t push with the same force as an 80 kg adult enemy or a stone block or so.
I’m writing this under projectiles, because when we get shot by a tennis ball the size of our head (or any projectile we’ll use later), I’d except some sort of impact, not just *poof* and and it’s gone. But even if we set a proper mass for the projectile, the physics engine doesn’t register it, because the delay is too short. I set the delay to 0.04f which seems to be enough for the projectile to ‘touch’ us, but not too much to bounce away.
SecondsBetweenShots resetting
In light of Rick’s advice to set ridiculously large numbers for testing, I set the healing projectile’s mass to 100 (kg) and discovered that when you quickly enter and leave enemy’s attack range, the enemy will shoot immediately, ignoring the cooldown interval.
Camera
Enemy UI
This didn’t seem much of a problem in Ben’s & Rick’s videos, but initially, I had a problem with Enemy UI Socket for displaying health. The rotation of the socket didn’t really work well with zero values (0,0,0) – it resulted in something like this:
I manually updated its rotation for every enemy to make it look okay, but perhaps the script itself might need a little update. Even at its best, the health bars tilt a bit whenever they are not in the centre of the screen, because they are trying to face the moving camera.
Steep hills – raycasting
My first level is in a valley surrounded by mountains from all but one side. However, there’s a problem when you run across a very high hill between the player and the camera. The hill is still part of the terrain, which is on a prioritised layer, thus it blocks the raycasting and you are effectively stuck and can’t move at all.
The obvious answer is to put on your level designer hat and scream at yourself for creating such a stupid hill, but because this problem might force players to reload or quit, it probably should have a better solution than “just don’t make high hills on the southern side”. For the moment, I added camera zoom and rotate in case of the raycasting scripts being updated in later lectures, but I thought of something like “go in the direction of the cursor if the mouse button is being held” (as seen in Diablo).
Steep hills – height mesh
And just a closing tip I think some people with similar problem might find useful – I had a problem that my player and the enemies would begin to “hover” few inches above the ground if they ran uphill.
This can be fixed by baking a height mesh alongside the navmesh.
So, what I basically mean by putting together the wall of text above: great course so far, keep up the good work; we’re all looking forward to it. I hope at least some of the feedback is useful. 
Happy Easter!
3 Likes
Just back from holiday, what a wonderful post! I’ve bought it to Rick’s attention, and will read it thoroughly myself later today just before I get back into RPG production.
Wow, this is really great input and feedback. Ben and I are going to put the actionable points on our To Do lists.
One quick thought regarding your hills / level design. Unless you need the player to get right to the edge of the hills, can you put something (boulders, fence, creek, etc) that prevent the player from getting too close to the hill that it becomes a problem. I assume the point is to still see the hills and how cool they are, but not to get buggy navigation issues. And yes, with a fixed camera there are some things that we just need to level design our way around. 
Also, I really liked that you took the extreme tuning on board and experimented - great thinking with the rock golem, I think I might use that myself!
Glad you liked my BOOM quiz question, and I bet you thought it was that crazy Rick that wrote that one 
Thanks for the feedback on other quizzes, I’ve improved them in response.
Re the asset pack in lecture 71, I do want people to be careful of import settings, however I’ll annotate this video to make it even clearer.
Re property drawers and headers, we’ll be using them a little later.
Re version control I’m struggling with this, as it’s a big topic but dry topic. I’ll certainly talk through what I’m doing more, and maybe you’ll learn it by absorption.
There is already a showcase category here: https://community.gamedev.tv/c/rpg/showcase
Thanks so much for all of this, the projectile feedback is noted too.
Thank you both for taking the time to reply and I’m really glad you found my feedback useful.
Rick, it’s definitely a good tip to keep the player from hills using natural obstacles, thanks! I think I don’t consider running on hills’ edge exactly the game’s feature, so it’ll be no big loss to make it unreachable. At least from the “northern” side.
Ben, thank you for listening to my and other students’ feedback! I noticed you showed some aspects of version control in a bunch of newer videos; that’s great! When I wrote that suggestion, that’s all I wanted – not to know git’s every nook and cranny, but those small tips you gave us, like the diff, or stashing/popping changes before, or when you mentioned multiple people shouldn’t work on one scene since they don’t merge well – those are all good tips I mostly didn’t know about before.
About the showcase category, I’m aware of it, although I though it’s purpose is something like “Hi! This is my game, check it out and give me some feedback!” rather than “Here are some free assets for your game if you want.”, but I guess it doesn’t matter that much.
Once again, thank you both for responding. 
1 Like