Hey Everyone!

It’s been quite a while since my last update for my super secret project I hinted about a couple months ago. This isn’t because a lack of trying but just time. As some of you may know I’m actually graduating college soon! While this is an exciting time for most people for me it’s an extremely stressful one. This leads to having to not work on the game for a bit longer then I personally would have liked. Boring personal stuff aside however, I’m happy to announce the title of my top secret project!

It’s called:

Lucky Brain Noodle!

_{Don’t tell anyone just yet though…}

“Lucky Brain what now?”

Some of you could be asking. To which I say if you want information about it though your gonna have to wait a little bit longer as we are still finalizing some of the final things for the big beta release where we are gonna have a whole big party with it.

“Well why the big development blog announcement then?”

While we did want to talk a bit about the development and the HUGE milestone we just hit, which is Steam integrated Multiplayer functionality! Before that though I wanted to take a second and talk about some of the under the hood development of the game which could help other developers in the future as LBN did have it’s fair share of trials that it went through. In the future I’ll most likely talk more about LBN development in future blogs, as it really was a big part of what I did in my off time at college. For this blog specifically we are going to be talking about Multiplayer Functionality in UE5 and common pitfalls. It’s going to cover not only the mistakes I made but hopefully serve as a cautionary tale for things to look out for if you plan to make a game multiplayer.

Section 1 decide what you want your game to be at the start.

If you want a game to be multiplayer have this in mind when you start the game. While I was lucky enough to have known since the beginning if the game was co-op, I seen multiple people where they decided it randomly half way through development of their game try to include multiplayer inside their plans. This should be something that you decide as soon as you start your project as it will heavily effect the way you make your games logic going forward especially in Unreal Engine especially with blueprints. Unreal Engine blueprints are extremely helpful during the development of the game. It could rapidly speed up the prototyping efforts which is wonderful when your in that stage of development or want to test something without having too much commitment. While it does fall short in some area’s like math and compile time Where I’d argue it falls short the hardest is the networking section. While you completely can make a multiplayer game using Unreal Engine’s blueprint network features you will learn extremely quickly it’s quite limiting especially when it comes to trying to add multiplayer to systems you developed in blueprint. A large part of this is due to the simplicity of blueprints. For an example if you wanted to make a small emote that plays for all players you will need at minimum: A ServerRPC, A MultiRPC, A function to call both RPCs, Branches checking Authority, Replicated Variables, and references to other actors. That’s a lot to keep track of for something so simple! I find it easier in more traditional code as it’s just adding a new tag to the function instead of adding almost 6 different nodes with multiple wires.

This issue gets a lot worse when you add in variables. Variables have 3 states.

• No Replication
  • The variable is not synchronized through Unreal’s replication system. The server and clients can each have their own local value
• Replicated
  • The server’s value is replicated to clients.
• Replication Notify
  • The variable is replicated to clients and can trigger a notification event when its replicated value changes.

These settings are only on the details panel when you click the variable and for every variable you want to do one of these 3 options with you have to specify this. This issue gets extremely annoying if you were in a situation like me where a lot of the systems were already built so you have to spend a minimum of 30 minutes just going through clicking the variable, clicking details, and checking one of them in the box. Then the issue of debugging arises as well…

Section 2 Debugging on Unreal Engine with blueprints can be rough.

Unreal engine blueprints as I already described is phenomenal in multiple ways. Another pro I commonly use to talk about is the debugging tool. It walks you through the program in a step by step guide which really can make it a lot simpler for you. It also tells you by hovering over variables exactly what that variable is at the time. “But isn’t that just what every debugger does?” Some of you might be asking, to which I say yes! I just find Unreal engine does it the most intuitive in the way it does it. In most IDEs you just get a large list of variables with a small section for variables you can specifically ask it to watch. In bigger programs that list is going to become rather long and if your trying to debug you often don’t know what variable is the one that is actually messing up, leading you to have to turn on the debugger look at certain vars then turn it off mark another variable for investigation, then turn it BACK on. In unreal engine you can just hover over nodes to see EXACTLY all information about not only that variable but everything associated with the variable. For instance if I am loading in my weapon I can not only see my weapon but any references that might by included like the model, socket locations, actors, and even blueprints! This is why I adore the debugging tool in UE… In single player..! Most of what I just spoke about DOES work in unreal engine multiplayer but it’s very gimmicky. It can cause a lot of issues for example I couldn’t use the debug tool at all on my client’s code. It would just not parse through it line by line like it was suppose to instead of crashing the program. It also commonly will “Unfocused” so if 2 characters share a script like 2 players for example. Even if you focus one of them (Like for my instance the client player) If the server player executes the command it cause the debugger to unfocussed the client and snaps to the server player instead even when you specifically asked the debugger NOT to do that. Then when it comes to checking replications, network load, and packets. These are not automatically included in the debugger. Instead you will have too open the console then type something like stat net each time to check one of those which can get a bit annoying when testing to see if you fixed the issue. For C++ portions of the project, I found Visual Studio’s debugger to be useful because it gave me more control over stepping through and inspecting my code. However, Unreal’s networking tools are still necessary when investigating replication and network performance.

Section 3 Testing Inputs on BOTH.

The way unreal engine works fundamentally is too start up it’s own instance of the game on that computer. Even when it’s playing multiplayer there will be 1 game instance they copy from one player (the server) and another one replicating it (the client). Both of these can have different bugs. For instance in my game a common bug that happened is 1 character would have the weapon in their hand but not actually inside their inventory meaning they didn’t have access to the weapons move set. In these situations I would love for a way to test inputs on both clients at the same time as something like unity has a plugin for this exact issue. Unreal engine does not have it built in or any plugins to support this feature when using their PIE window system. This was a huge issue for me as I had to constantly check inputs but didn’t want to keep having to awkwardly tab into bother games constantly, But I did figure out a small solution! If your game supports a controller and keyboard set up you can set 1 of these to each window allowing you test both games simultaneously. This will allow you to not only play 1 game but also another as your technically “not tabbed in” but still doing inputs.

The biggest lesson I took away from implementing multiplayer was that multiplayer cannot be treated as a feature that gets added at the end of development. It affects how your systems are designed, how your variables are handled, and even how you test and debug your game. Multiplayer is something you must consider from the start and I’m glad I knew since the start to design my systems to be modular enough to accommodate this feature.

Hey Everyone!

For my final Capstone at SNHU I was tasked with looking at some of the older games I have made in the development of my time at this SNHU as someone who is now about to graduate. The first thing I thought of was “Oh this is going to be embarrassing!”, which I was completely right! After looking at my older code for a while I realized I made so many mistakes back in the day that were extremely silly to make. As it was required by class to spend a week polishing the game (while not completely rewriting it) to make it a bit nicer for a portfolio; I wanted to make a semi post mortem/code review just for fun. I also wanted a chance to talk about thing I have learned from then along with how I would approach the same situation much differently if given a chance to do a complete rewrite instead of polish.

This project was made using mainly C++ but also does have a small aspect of blueprints for the UI elements. While I could talk about the blueprints for this code review I would only like to talk about the C++ as that’s where the bulk of the code is and what this project is suppose to be demonstrating.

The project can be found Here on my Github.

First I’d like to say the biggest issue with this entire project I really wish I was allowed to change for my polishing. Is where the code actually is. A major part of the code is located inside the: PlayerChar.cpp & PlayerChar.h. This is an issue for multiple reasons such as refactoring, tweaking, testing, and expandability along with even more. With a smaller game project, such as this one, it could be alright but a good programmer should always plan for expandability rather then expecting it will never be expanded upon or looked on again by another programmer.The larger issue is that several different gameplay systems are being handled directly inside PlayerChar.cpp. While player-specific logic belongs in the player class, systems such as resource management and building could be separated into their own components or classes as the project grows. You should try to the best of your ability to make every system modular to the best ability you can. While this can be seen as a time waste by some other people I’d argue the opposite, if you ever need the code later you will be thanking yourself in the past for having the forethought for making it a lot easier on yourself to scan through your code. This also is in general a great habit to develop like all of OOP principals, as it stops a lot of redundant code from having to be written along with heavily speeds up your development time.

Breaking down the code I’d like to talk about this at the start of PlayerChar.cpp

  BuildingArray.SetNum(3);
	ResourcesArray.SetNum(3);
	ResourcesNameArray.Add(TEXT("Wood"));
	ResourcesNameArray.Add(TEXT("Stone"));
	ResourcesNameArray.Add(TEXT("Berry"));

While this code is functional and does work as intended it could be written in a cleaner nicer way while still allowing for expandability. I’d change the initialization and data structure to make the resource system dynamically scalable. I manually initialized the array to a size of 3, which creates unnecessary rigidity. It also introduces the “Magic Number” issue as let’s say later down the line we want to add 100s of resources. We would have to memorize the size was 100 then remember to add to that number if we ever decided to add more or less which could cause issues in the future.

Another section of my code I heavily did improve upon even if I wasn’t allowed to “completely rewrite the code” is

void APlayerChar::SetHealth(float amount)
{
	if (Health + amount < 100)
	{
		Health = Health + amount;
	}
}

void APlayerChar::SetHunger(float amount)
{
	if (Hunger + amount < 100)
	{
		Hunger = Hunger += amount;
	}
	else {
		Hunger = 100;
	}
}

void APlayerChar::SetStamina(float amount)
{
	if (Stamina + amount < 100)
	{
		Stamina = Stamina + amount;
	}
}

void APlayerChar::DecreaseStats()
{
	if (Hunger > 0)
	{
		SetHunger(-1.0f);
	}
	
	SetStamina(10.0f);

	if (Hunger <= 0)
	{
		SetHealth(-3.0f);
	}
}

The first thing you might notice is “there isn’t a singular comment!”. Which is a good thing to notice but the bigger issue the naming convention + logic. For an example naming a function void APlayerChar::SetHealth(float amount) might make you think it’s to set a player health function but it’s actually a additive healing function intended to heal the player. I would rename it something like GainHealth instead then add a smaller comment explaining what it does. This is also true for a function named void APlayerChar::DecreaseStats() it only decreases 2 stat which a better way to write this might be void APlayerChar::PassiveHungerDrain()

There is also the issue with the logic. The logic in almost all of these isn’t set up in a scalable/Modular way. Firstly they all include the “Magic Number” issue I spoke about before where there is no context for most of these variables which could lead other programmers confused. They also could lead to hard coded numbers which could cause issues in the future. For an example a game designer says “Hey Justin, let’s make the player health around 150 instead of 100”. You’d have to manually go in and change a lot of variables as now if (Health + amount < 100) doesn’t work anymore. There is also edge case logic that is a even larger issue in this code. For this example we are going to use this snippet.

void APlayerChar::SetHealth(float amount)
{
	if (Health + amount < 100)
	{
		Health = Health + amount;
	}
}

Let’s say Your health is at 80 and you eat a berry which heals you for 30. It would be 80 + 30 which means your new health value is 110 and 110 < 100 isn’t true. This means you would need the EXACT amount of healing to regain HP to max again. This could be easily fixed by fixing this line of code or adding another snippet for KISS simplicity like:

else if (Health + amount >= MaxHealth)
{
  Health = MaxHealth;
}

This could easily fix the code while not introducing complex logic to the problem that might make it a bit harder to read.

Now for the big one which is the FindObject() function where MOST of the game logic is stored and has deep nesting issues along with no comments.

void APlayerChar::FindObject()
{
	FHitResult HitResult;
	FVector StartLocation = PlayerCamComp->GetComponentLocation();
	FVector Direction = PlayerCamComp->GetForwardVector() * 800.0f;
	FVector EndLocation = StartLocation + Direction;

	FCollisionQueryParams QuaryParams;
	QuaryParams.AddIgnoredActor(this);
	QuaryParams.bTraceComplex = true;
	QuaryParams.bReturnFaceIndex = true;

	if (!isBuilding)
	{
		if (GetWorld()->LineTraceSingleByChannel(HitResult, StartLocation, EndLocation, ECC_Visibility, QuaryParams))
		{
			AResource_M* HitResource = Cast<AResource_M>(HitResult.GetActor());

			if (Stamina > 5.0f)
			{
				if (HitResource)
				{
					FString hitName = HitResource->resourceName;
					int resourceValue = HitResource->resourceAmount;

					HitResource->totalResource = HitResource->totalResource - resourceValue;

					if (HitResource->totalResource > resourceValue)
					{
						GiveResource(resourceValue, hitName);

						matsCollected = matsCollected + resourceValue;

						objWidget->UpdatematOBJ(matsCollected);

						check(GEngine != nullptr);
						GEngine->AddOnScreenDebugMessage(-1, 5.0f, FColor::Red, TEXT("Resource Collected"));

						UGameplayStatics::SpawnDecalAtLocation(GetWorld(), hitDecal, FVector(10.0f, 10.0f, 10.0f), HitResult.Location, FRotator(-90, 0, 0), 2.0f);

						SetStamina(-5.0f);

					}
					else
					{
						HitResource->Destroy();
						check(GEngine != nullptr);
						GEngine->AddOnScreenDebugMessage(-1, 5.0f, FColor::Red, TEXT("Resource Depleted"));

					}
				}
			}
		}

	}

	else
	{
		isBuilding = false;
		objectsBuilt = objectsBuilt + 1.0f;

		objWidget->UpdatebuildObj(objectsBuilt);
	}


}

This is probably the most egregious example on the list. FindObject() is doing way to much for the start as it’s responsible for:

• Performs a line trace
• Determines what was hit
• Checks stamina
• Collects resources
• Updates resource totals
• Updates the objective UI
• Displays debug messages
• Spawns a decal
• Changes stamina
• Handles building
• Updates the building objective

That’s way to much for 1 function to be handling and could be broken down in multiple smaller functiones. Which it could look something like this:

• TraceForObject()
  • Handles line traces for objects
• HandleResource()
  • Handles resource gathering
• CollectResource()
  • Handles the math values of resource gathering
• UpdateObjective()
  • Handles Objectives

A simple change like this would make the function much easier to read and most likely even prevent issues arising in the future of being unable to find bugs.

There is also the issue of the naming convention like before FindObject() isn’t a descriptive name. It could be renamed to InteractWithObject() instead with a smaller comment explaining the functionality.

Magic numbers is also the biggest issue inside this function. So many numbers are purely magic numbers which is going to make almost anyone confused if you try to code with it or tinker with it in the future. Even though I made the code 2 years ago I still struggled to understand what was even going on until I read it slowly / played the game a bit to understand it. Like stated before this is a huge issue going forward as if any value changes; for instance the SetStamina(-5.0f); which is a stamina drain. You’d have to find every variable of a 5 to change it.

There is also the issue of logic problems much like the other issues I did found here:

HitResource->totalResource = HitResource->totalResource - resourceValue;

if (HitResource->totalResource > resourceValue)
{
    GiveResource(resourceValue, hitName);
    ...
}
else
{
    HitResource->Destroy();
}

While the code does work I am subtracting the resource value before checking whether there is enough resources that remain. This could cause an issue in the future where the player destroys a resource without having received the final amount. This is horrible for the player experience as it’s going to seem like the game is either broken or your input didn’t register correctly.

Most of the code here has been redone and is currently available on my Github located Here

You’ll find this post in your _posts directory. Go ahead and edit it and re-build the site to see your changes. You can rebuild the site in many different ways, but the most common way is to run jekyll serve, which launches a web server and auto-regenerates your site when a file is updated.

To add new posts, simply add a file in the _posts directory that follows the convention YYYY-MM-DD-name-of-post.ext and includes the necessary front matter. Take a look at the source for this post to get an idea about how it works.

Jekyll also offers powerful support for code snippets:

def print_hi(name)
  puts "Hi, #{name}"
end
print_hi('Tom')
#=> prints 'Hi, Tom' to STDOUT.

Check out the Jekyll docs for more info on how to get the most out of Jekyll. File all bugs/feature requests at Jekyll’s GitHub repo. If you have questions, you can ask them on Jekyll Talk.

This theme supports link posts, made famous by John Gruber. To use, just add link: http://url-you-want-linked to the post’s YAML front matter and you’re done.

And this is how a quote looks.

Some link can also be shown.

A notice displays information that explains nearby content. Often used to call attention to a particular detail.

When using Kramdown {: .notice} can be added after a sentence to assign the .notice to the <p></p> element.

Changes in Service: We just updated our privacy policy here to better service our customers. We recommend reviewing the changes.

Primary Notice: Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer nec odio. Praesent libero. Sed cursus ante dapibus diam. Sed nisi. Nulla quis sem at nibh elementum imperdiet.

Info Notice: Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer nec odio. Praesent libero. Sed cursus ante dapibus diam. Sed nisi. Nulla quis sem at nibh elementum imperdiet.

Warning Notice: Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer nec odio. Praesent libero. Sed cursus ante dapibus diam. Sed nisi. Nulla quis sem at nibh elementum imperdiet.

Danger Notice: Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer nec odio. Praesent libero. Sed cursus ante dapibus diam. Sed nisi. Nulla quis sem at nibh elementum imperdiet.

Success Notice: Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer nec odio. Praesent libero. Sed cursus ante dapibus diam. Sed nisi. Nulla quis sem at nibh elementum imperdiet.

Want to wrap several paragraphs or other elements in a notice? Using Liquid to capture the content and then filter it with markdownify is a good way to go.

{% capture notice-2 %}
#### New Site Features

* You can now have cover images on blog pages
* Drafts will now auto-save while writing
{% endcapture %}

<div class="notice">{{ notice-2 | markdownify }}</div>

Or you could skip the capture and stick with straight HTML.

<div class="notice">
  <h4>Message</h4>
  <p>A basic message.</p>
</div>

Only one thing is impossible for God: To find any sense in any copyright law on the planet.

Mark Twain

Abbott: Strange as it may seem, they give ball players nowadays very peculiar names.

Costello: Funny names?

Abbott: Nicknames, nicknames. Now, on the St. Louis team we have Who’s on first, What’s on second, I Don’t Know is on third–

Costello: That’s what I want to find out. I want you to tell me the names of the fellows on the St. Louis team.

Abbott: I’m telling you. Who’s on first, What’s on second, I Don’t Know is on third–

Costello: You know the fellows’ names?

Abbott: Yes.

Costello: Well, then who’s playing first?

Abbott: Yes.

Costello: I mean the fellow’s name on first base.

Abbott: Who.

Costello: The fellow playin’ first base.

Abbott: Who.

Costello: The guy on first base.

Abbott: Who is on first.

Costello: Well, what are you askin’ me for?

Abbott: I’m not asking you–I’m telling you. Who is on first.

Costello: I’m asking you–who’s on first?

Abbott: That’s the man’s name.

Costello: That’s who’s name?

Abbott: Yes.

Costello: When you pay off the first baseman every month, who gets the money?

Abbott: Every dollar of it. And why not, the man’s entitled to it.

Costello: Who is?

Abbott: Yes.

Costello: So who gets it?

Abbott: Why shouldn’t he? Sometimes his wife comes down and collects it.

Costello: Who’s wife?

Abbott: Yes. After all, the man earns it.

Costello: Who does?

Abbott: Absolutely.

Costello: Well, all I’m trying to find out is what’s the guy’s name on first base?

Abbott: Oh, no, no. What is on second base.

Costello: I’m not asking you who’s on second.

Abbott: Who’s on first!

Costello: St. Louis has a good outfield?

Abbott: Oh, absolutely.

Costello: The left fielder’s name?

Abbott: Why.

Costello: I don’t know, I just thought I’d ask.

Abbott: Well, I just thought I’d tell you.

Costello: Then tell me who’s playing left field?

Abbott: Who’s playing first.

Costello: Stay out of the infield! The left fielder’s name?

Abbott: Why.

Costello: Because.

Abbott: Oh, he’s center field.

Costello: Wait a minute. You got a pitcher on this team?

Abbott: Wouldn’t this be a fine team without a pitcher?

Costello: Tell me the pitcher’s name.

Abbott: Tomorrow.

Costello: Now, when the guy at bat bunts the ball–me being a good catcher–I want to throw the guy out at first base, so I pick up the ball and throw it to who?

Abbott: Now, that’s he first thing you’ve said right.

Costello: I DON’T EVEN KNOW WHAT I’M TALKING ABOUT!

Abbott: Don’t get excited. Take it easy.

Costello: I throw the ball to first base, whoever it is grabs the ball, so the guy runs to second. Who picks up the ball and throws it to what. What throws it to I don’t know. I don’t know throws it back to tomorrow–a triple play.

Abbott: Yeah, it could be.

Costello: Another guy gets up and it’s a long ball to center.

Abbott: Because.

Costello: Why? I don’t know. And I don’t care.

Abbott: What was that?

Costello: I said, I DON’T CARE!

Abbott: Oh, that’s our shortstop!

This post has been updated and should show a modified date if used in a layout.

All children, except one, grow up. They soon know that they will grow up, and the way Wendy knew was this. One day when she was two years old she was playing in a garden, and she plucked another flower and ran with it to her mother. I suppose she must have looked rather delightful, for Mrs. Darling put her hand to her heart and cried, “Oh, why can’t you remain like this for ever!” This was all that passed between them on the subject, but henceforth Wendy knew that she must grow up. You always know after you are two. Two is the beginning of the end.

All children, except one, grow up. They soon know that they will grow up, and the way Wendy knew was this. One day when she was two years old she was playing in a garden, and she plucked another flower and ran with it to her mother. I suppose she must have looked rather delightful, for Mrs. Darling put her hand to her heart and cried, “Oh, why can’t you remain like this for ever!” This was all that passed between them on the subject, but henceforth Wendy knew that she must grow up. You always know after you are two. Two is the beginning of the end.

Mrs. Darling first heard of Peter when she was tidying up her children’s minds. It is the nightly custom of every good mother after her children are asleep to rummage in their minds and put things straight for next morning, repacking into their proper places the many articles that have wandered during the day.

This post has a manual excerpt <!--more--> set after the second paragraph. The following YAML Front Matter has also be applied:

excerpt_separator: "<!--more-->"

If you could keep awake (but of course you can’t) you would see your own mother doing this, and you would find it very interesting to watch her. It is quite like tidying up drawers. You would see her on her knees, I expect, lingering humorously over some of your contents, wondering where on earth you had picked this thing up, making discoveries sweet and not so sweet, pressing this to her cheek as if it were as nice as a kitten, and hurriedly stowing that out of sight. When you wake in the morning, the naughtiness and evil passions with which you went to bed have been folded up small and placed at the bottom of your mind and on the top, beautifully aired, are spread out your prettier thoughts, ready for you to put on.

I don’t know whether you have ever seen a map of a person’s mind. Doctors sometimes draw maps of other parts of you, and your own map can become intensely interesting, but catch them trying to draw a map of a child’s mind, which is not only confused, but keeps going round all the time. There are zigzag lines on it, just like your temperature on a card, and these are probably roads in the island, for the Neverland is always more or less an island, with astonishing splashes of colour here and there, and coral reefs and rakish-looking craft in the offing, and savages and lonely lairs, and gnomes who are mostly tailors, and caves through which a river runs, and princes with six elder brothers, and a hut fast going to decay, and one very small old lady with a hooked nose. It would be an easy map if that were all, but there is also first day at school, religion, fathers, the round pond, needle-work, murders, hangings, verbs that take the dative, chocolate pudding day, getting into braces, say ninety-nine, three-pence for pulling out your tooth yourself, and so on, and either these are part of the island or they are another map showing through, and it is all rather confusing, especially as nothing will stand still.

Of course the Neverlands vary a good deal. John’s, for instance, had a lagoon with flamingoes flying over it at which John was shooting, while Michael, who was very small, had a flamingo with lagoons flying over it. John lived in a boat turned upside down on the sands, Michael in a wigwam, Wendy in a house of leaves deftly sewn together. John had no friends, Michael had friends at night, Wendy had a pet wolf forsaken by its parents, but on the whole the Neverlands have a family resemblance, and if they stood still in a row you could say of them that they have each other’s nose, and so forth. On these magic shores children at play are for ever beaching their coracles [simple boat]. We too have been there; we can still hear the sound of the surf, though we shall land no more.

Of all delectable islands the Neverland is the snuggest and most compact, not large and sprawly, you know, with tedious distances between one adventure and another, but nicely crammed. When you play at it by day with the chairs and table-cloth, it is not in the least alarming, but in the two minutes before you go to sleep it becomes very real. That is why there are night-lights.

Occasionally in her travels through her children’s minds Mrs. Darling found things she could not understand, and of these quite the most perplexing was the word Peter. She knew of no Peter, and yet he was here and there in John and Michael’s minds, while Wendy’s began to be scrawled all over with him. The name stood out in bolder letters than any of the other words, and as Mrs. Darling gazed she felt that it had an oddly cocky appearance.