[Day 0] Introduction to Guzman HR Derby

This is the game log for Guzman HR Derby!

About

"Guzman HR Derby" is a bat-and-ball, home-run contest game where you control Guzman, an aspiring baseball player taking part in a competition that requires him to hit as many consecutive home runs as possible. 

Past Experience

It is more or less an inside-joke game, but it is also a great excuse for me to learn how to make a 3D physics game in Unity. I am "proud" to say that I have 3 months of experience in Unity, which was all gained in an upper-division course that I took in college taught by Blizzard employees. After that, I haven't had much of a chance to use it, instead riding on GameMaker: Studio's engine until it became obsolete this past August of 2018. Now that GM:S is obsolete, I realize that I need to expand my skillset and learn how to use other game engines. Thus, while this game won't be my first Unity game, it certainly feels like making a game for the first time.

This game will be the first Unity and 3D game I am making not for a class. This will also be the first game I am committing to developing to completion not made in GameMaker: Studio, my primary engine of choice.

Goals

There are some checkpoints I want to reach as of today:

• Baseline 1: Get the ball to bounce off a bat
• Baseline 2: Create the "stadium" (for simplicity, all hit balls will be home runs; you score by hitting the ball in fair territory and not foul territory. This will simplify the game goals for this two-week project.)
• Baseline 3: Make a title screen and add some nice fonts
• Stretch Goal 1: Make a character select screen
• Stretch Goal 2: Add music/SFX

I will be going solo to challenge myself. 

Conclusion

Day 1 is tomorrow and I can wait to get started!

this is an awesome outline! i love that you're already thinking about how to simplify the game scope by either having fair or fouls. good luck!!

[Day 1] Ball and Bat

Today's goal is to program the basic mechanic of the game: hitting a ball with a bat.

Approach

Starting from scratch, I had to import assets from the Unity Asset Store to get myself something to work with. The only asset that I needed was a 3D bat that I can swing, and that was easily found with a search of free baseball bat assets. All other assets, such as the bases, walls, and field could be easily created with primitives such as cubs and spheres. Even I remember how to do that- if I didn't, those 3 months of being taught by Blizzard employees really would have gone to waste xP

I was not too worried about the aesthetics of the game at this time. In previous hackathons that I competed in, we only had 36 hours to complete our projects from start to finish. I knew that with this game jam lasting way longer than 36 hours, I would have time to draw up things later. I plan on visiting the field that Guzman plays on and have a photoshoot so that we can get sprites for his teammates and him as well as finalize the dimensions of the (weirdly-shaped) field. Furthermore, this is my first true 3D game, and I've primarily done games in a 2D game engine, GameMaker: Studio- so I'd rather learn how to get the collisions working first.

Simplification of Physics/Colliders

There are many tutorials online on how to create such a game (especially in Unity VR) and for the most part, I followed them. However, I had to remind myself that this game is called the Guzman HR (home run) Derby- our good friend Guzman always hits home runs. Therefore, instead of using a cylinder collider for the bat, I used a rectangular collider. On a collision event, I added a forward and upwards force to the ball, launching it directly into the seats! It is guaranteed that the ball does not land within the boundaries of the field (it will either be a home run or a foul ball) so I was not worried about adding collisions/features to the field.

Going with the "HR Derby" approach allows me to "cheat" the collision mechanics by forcing the ball to always go up and forward towards the stands. I do not need to create a complex collider to handle what happens if the ball is hit towards the ground, etc- because, well, Guzman always hits home runs.

Testing

We can test this implementation by binding the bat to a key and the ball to another key. The bat key swings the bat, while the ball key launching the ball from the pitcher's mound. As we can see in the gif above, the basic implementation seems to work well enough.

Next

Coming up next, we will need to implement the basic scoring mechanic of the game. This is actually easy- we can use invisible triggers along the outfield wall to determine if a ball is a home run or a foul. In an actual baseball game, if the ball clears the outfield wall between the foul poles in left/right field, then the ball is a home run.

We will need:

• A score controller object to track the score and draw it
• A game controller to determine if the ball is a home run
  • Stretch goal: a game controller that launches the next ball after a determination is made.

-Browntul

[Day 2] Score A Ball

Today's main goal is to implement the score and game controllers to facilitate scoring. This is all we need to have a working prototype of the game.

Approach

We have to first come up with the scoring logic of the game itself, as they differ from baseball itself. Specifically:

• The ball must be launched from the pitchers mound towards home plate, and the player must hit the ball with the bat.
  • If the bat misses the ball on the swing, the ball is foul.
• The batted ball must be hit beyond the outfield walls and between the two foul poles to be fair.
• Otherwise, the ball is foul.

We can use large triggers represented by GameObjects to detect when the ball crosses the outfield walls (or out of play along the foul lines). If the ball crosses the trigger, we can judge accordingly if the ball is fair or foul. This logic is also applied to the field grounds themselves, since balls that are not home runs are fouls (it's the home run derby after all).

Score

We can implement a UI text element to display the score. When the ball crosses a fair/foul trigger, it increments the score if appropriate. This is one thing I still remember from that Blizzard Unity class!

Other Changes Since Day 1

• Stadium: I had some extra time to import a sports stadium from the Unity Asset Store. I removed the soccer field from the arena and added my baseball field in its place. The stadium does not have any colliders itself, since that is already handled in my own implementation as described above.
• Cameras: I realized that I would want the player to observe the ball flying into the stands. Thus, after a swing, I change cameras to an outfield camera that follows the ball so that the player can judge for themselves whether the ball is a home run or not. After a judgement is made, the camera resets to the one behind home plate.

Demo

The demo for this prototype is linked here.

Controls:

• Space Bar: Swing
• Enter/Return: Pitch ball (once per 2 seconds)

Next

We have plenty of time left to diversify the controls of the bat-and-ball mechanics. Right now, the player can only direct the ball in certain directions via timing of the bat swing. Perhaps we can implement a power mechanic in some way, such that the player must swing hard to hit a home run? 

Anyhow, we'd need to show indicators of whether a ball is fair or foul still. We also need to define a definitive game start/end state.

wow your breakdown on how you implemented the hitboxes for the batting (re: box instead of cylinder) is really well thought out... it's really cool to see your process for solving problems in general! great stuff!

[Day 3/4] Transitions and Animations

We will be using a scene transition to define the game over state, and then we will add Guzman into the game after a short photoshoot.

Scene Transition

Actually, loading scenes is pretty easy for the scope of this project. When the game is over, we will transition from the game scene to the results scene. This concept is similar to that in GameMaker: Studio, where scenes were called rooms. In GM:S, there is a built-in function called:

room_goto(index) 

that transitions from one room to another. In Unity, we can use the Scene Manager:

SceneManager.LoadScene(index, LoadSceneMode.Single)

to load the next scene in the same manner.

The challenging part was finding the equivalent of passing certain existing objects into the next scene. In GM:S, we can make an object "persistent" and pass it over from the old scene to the new scene, then un-"persist" it at the new scene. In Unity, we could mark the object with "DontDestroyOnLoad" and pass it over to the new scene. "DontDestroyOnLoad" in Unity has the same behavior as persistence in GM:S, so that was not difficult to implement. 

I decided to mark a single GameObject as my "global" object to pass around to all scenes. This is usually not a good practice, but since my game is simple and only has at most three scenes (title, game, results), I don't see this as a big deal. Maybe it's just my GM:S logic kicking in to Unity. Anyways, this global object holds two variables at the moment: "game over", a bool; and "score", the number of home runs recorded in the game scene.

Animation

Now, GM:S is primarily a 2D game engine, and for the most part I've been using that engine to make games. Thus, all of the "sprites" are in 2D, and there was no need for 3D modeling.  Now that we're making a 3D game, a dilemma arises.  How in the world can I make my own 3D models? I could ask the Discord or learn how to draw up a model myself- but instead, I decided to try something that old 3D games used to do...

Use 2D sprites of 3D models! And actually, I'm not even drawing those 2D sprites. I figured that if Guzman was going to be in the game... well, why not just take pictures of him swinging?

I'll let the pictures describe the rest.

Using the Unity animator was probably the hardest thing in the world.  But this was probably because I was used to the way GM:S handled sprites and their respective animations. I do appreciate the fact that an "Animator" object in Unity can define states such that the animations in those states do not necessarily need to be programmed in user scripts. Specifically, Guzman only had two animations (idle and swing) and I was able to transition between states using little code. 

Since I cheated the entire 3D modeling world by making 2D representations of real-life models, effectively turning this game into some sort of Nintendo 64 knock-off, I had to alter the angle of the main camera such that the Guzman sprite was actually standing in the batters box. The bat remains in 3D. More tweaking of this hybrid sprite/bat combination will probably happen towards the end of development.

Next

Now that we at least have a cheap animation of Guzman and have implemented it into the game, we can focus on the mechanic I decided I wanted to add a twist to: bat power. This will make the game a little bit more interesting. How will I implement this power mechanic without making complex the controls? (We want the game to be controlled with one button only, and the mouse/touch.)

[Day 5] No Time

I had no time today so I made a title screen graphic instead.

A truly simplistic game. Some really famous independent designer guy once said,

True simplicity is derived from so much more than just the absence of clutter and ornamentation. It's about bringing order to complexity.

Next

Speaking of complexity, I should probably stop writing about this bat power mechanic and actually implement it over the next few days. A truly simple yet complex mechanic indeed.

[Day 6] Power Mechanic and GUI

Today we will add the power mechanic and a basic GUI for the game scene.

Power Mechanic

As previously mentioned, the power mechanic will help make the game more interesting to the player without adding extra buttons to the game.

The power mechanic will work as follows:

• Press and hold the SPACE BAR/PRIMARY MOUSE to build up bat power.
• Release that button to swing the bat with power.

When the button is held, a power meter will fill up. If the player releases the button when the meter is full, then Guzman will hit the ball hard with power! However, if the player holds the button too long, the meter will reset and Guzman may hit the ball weakly, so the player must be careful not to hold the button too long. 

The meter is mathematically represented by a decimal value, 0.0-1.0, which when added to a constant can then be multiplied into the formulas that determine the force of the ball off the bat. The timing mechanic does not need to be changed as the bat speed remains the same regardless of the power. 

To represent this meter, I used an asset that fills from left to right on the bottom of the screen, as seen in the image below. 

An obvious change is that with the introduction of the power meter,  balls that are hit may not necessarily be hit for home runs. This case was already handled previously, however- as programmed in a previous day, balls hit in fair territory but not beyond the outfield walls are already considered foul.

GUI

While I was at it, I created the GUI for the score and balls/time left indicators (see next section for details on these two modes). 

These indicators are simple, as you can see above. The home run counter is on the left. The balls/time-left indicator is on the right.

Other Additions

Placeholder music and two modes were added.

• Placeholder Music: I was inspired to make this game by Wii Sports and MLB Power Pros. Music from the latter was used as placeholder music until I start working on BGM/SFX.
• Modes: I modified the ball spawning controller to allow for two modes:
• Stock: The player gets 10 balls to swing at.
• Time: The player gets 60 seconds (for now) to swing at balls.

Demo

The demo for this prototype is linked here.

Controls:

• Mouse: Select Options
• Space Bar: Swing

Next

At this point, we have a good enough prototype to give to others to test the game mechanics. We can gain feedback from the Discord.

Next, I will need to add a character select screen. As you may probably infer, that character selection screen may or may not be a joke, because- well, who wouldn't pick Guzman in Guzman HR Derby? Stay tuned!

-Browntul

[Day 7] Gameplay Improvements from Feedback

The first prototype from Day 6 was enough to be a functioning game. It features a problem for the player to solve (hit home runs).  Obviously, gameplay improvements and mechanics can be added over the next 9 days. Today's development changes are based on feedback from others on this prototype. 

Feedback 1: The game feels slow

First, I received feedback that the game feels slow. By this, they mean that the ball travels so slow that they could fall asleep watching their home runs go into the stands. I actually agree with this, but I haven't made the effort to adjust the physics until now. I simply increased the gravity and adjusted some forces.

Feedback 2: We don't know when to swing

Second, I received some feedback that the player does not know when to swing the bat at the right time. This could be caused by a variety of issues, but one suggestion was to add some sort of visual indicator of the ball's distance to home plate. I settled on using a "timing" meter. If the meter tops off at the white line, then the player's timing is good. I will probably explore this interface over the new few days.

Other Changes

There was two other miscellaneous changes today: 

• Leaderboard. I'm a fan of implementing a top 10 leaderboard; but I decided that for a simple game like Guzman HR Derby, the high score table should really be one entry for each of the two modes. I also decided against implementing an online leaderboard for now. I usually host my online leaderboards on Google Cloud, but I've been having issues with securing cloud credits this summer.
• Cameras. I added two field cameras as alternate angles for viewing home runs. There is approximately a 33% chance of triggering a camera on a hit. 

Next

Could there be future gameplay changes in the next few days? I want to explore the idea of adding targets in the bullpen areas of the stadium and challenge the player to hit the ball into those targets for extra points.

I'll also be adding the character select screen. I can't wait for you all to pick Guzman!

-Browntul

[Day 8]  A New Challenger Pitches In

Today we will be adding a character (player) select screen for the batters and add our pitcher into the game!

Character Select

In an idea world, we would have multiple characters available in the game. For the scope of this project, we will restrict it to just Guzman for now- but in case we add characters in the future, we will need a character select screen to handle character selection and make it easier to implement down the road.

Having participated in hackathons prior to this game jam, I know that it is important to display a prototype of an important functionality of the final, envisioned product, even though it is not functional in the prototype itself. That being said, I implemented the character select screen in full, even transferring a variable that saves the character selection from this scene to the game scene. However, I also introduced a variable stopping players from using non-implemented players- literally the entire roster of characters except Guzman (we call him "Anthony" in the player select screen by request)- using a boolean to disable the "start" button.

This is the first time I used the UI scroll view in Unity, and I'm very much prefer this over GameMaker: Studio's lack of a build-in scroll view object. I don't have to code in the placements of my character select buttons; Unity does this for me!

I also moved the "Mode" button to the character select screen just so I can consolidate all settings into one scene.

Animating the Pitcher

I finished a short photoshoot with the pitcher of Guzman's team. I implemented it in a similar way as Guzman's animation implementation, which I won't re-describe in detail here.

There was one different in this animation that I implemented with the pitcher. I wanted the pitcher to spawn the ball after the animation is ended. Thus, I used an Animation Event to trigger the ball spawn. A timer is still used by the spawn controller to trigger the start of the pitching animation.

The resulting batter's view looks like this:

Demo

The demo for this prototype is linked here.

• Space/Touch (hold/release): Swing
• Mouse: Select option

Next

This is a good time to ask for some feedback. I may take a break tomorrow as we head into the weekend- and this will also help me think of more gameplay elements, such as bonus targets, which I can implement as I finish modeling the outfield features!

-Browntul

[Day 9] Uwu

I did nothing related to this project today, for the most part.

Google Cloud Platform

I really just spent time changing my billing account so I can keep my previous award-winning hackathon project alive on the server :'(

HACKUWU MUST STAY ALIVE!

[Day 10] Prideful Aesthetics

Today I will be adding some sound effects into the game as well as some cool aesthetic-looking things.

Embrace the Crowd Mixer

I implemented a sound mixer into the game. This way, players can change the volume of the background music, crowd, and other sound effects.

Sound effects that were added include the ball hit off the bat and the scoring sound for successfully hitting a home run. I separated the crowd effects from the sound effects because as a sports game player (video games and real life), I feel that some players would value hearing only the sound effects over the crowd effects.

I'm not sure whether to allow the player to change the volume during the game or to restrict this setting to the title screen. In general, I am not sure whether I would want to allow the player to pause the game overall. This is something I will have to deliberate over the next few days. 

Admire The Prideful Trail

Players can now track the ball's flight more easily thanks to its rainbow trail. This is in honor of the game's theme, "Pride!" The rainbow trail only appears when Guzman hits the ball. In addition, I added a distance tracker to put a number on the distance of the batted ball. Let's hope you hit 500ft homers!

Demo

The demo for this prototype is linked here.

Controls:

• Mouse/Space (hold and release): Swing
• Mouse: Select

Next

I still need to add outfield field features! I may not have time to add more functionality in the game as I previously hoped for, so I may instead focus on quality control and bug-squashing to close out the game jam.

[Day 11] Where's the Amenities?

Today, we will be filling in the empty spots in the stadium beyond the outfield walls.

Here Lies The Bullpen

I didn't want to try too hard on this since I am not a 3D designer. But sticking to the traditions of professional baseball fields, I had to add at least two sets of mounds/homeplates on each side of the field. After all, what if Guzman decides to play a full-fledged baseball game at this field?

I also decided to add a video board in center field. The video board's only function is to follow the flight of the batted ball. So if you're a fan of Guzman, you can watch the flight of the ball in-person at the stadium!

Doing this required cutting into fair territory; but most baseball fields don't look like rectangles, so this is a good excuse to round out the field dimensions. The field dimensions are about 350ft to the corners and 400ft to center field (both distances from home plate).

Other Changes

• Music: I added free music from the Unity Asset Store to replace the Konami placeholder music that was used in previous prototypes. I'd say the music sounds pretty hype!
• Game Over: I added text that tells the player that the game is over, because- well, I never told them that in-game visually other than change scenes.
• Bonus Time: I added a bonus mechanic to the stock game mode. If a player hits 10 home runs in regulation, they can keep hitting until they miss/do not hit a home run. This can make the game last forever! (And due to the lack of variance in the pitches, perhaps the game will indeed last forever. That's something to think about.)

Demo

The demo for this prototype is linked here.

Controls:

• Mouse/Space (hold and release): Swing
• Mouse: Select

Next

Well, this is a fully-developed game, isn't it? It has a start/end state with clearly-defined goals. The player can customize their character (except yes, but actually no) and the sound volume. Not bad for a first Unity 3D game made in true 3D.

There's no need to add more mechanics to the game at this point in the game jam. However, if I were to add features in the next few days, they may include (but are not limited to):

• Pitch height/distance variance to avoid cheating via visual computing/machine learning (hmm)
• Fireworks and night mode (dark mode)
• Time bonuses in timed mode, in some form.
• Easter eggs??

[Day 12] Prideful Things

Today's changes pertained to bug fixes and changes to the outfield's features- but it also included some prideful changes.

Downloadable Content

The game will feature "downloadable content" that the player can "purchase." Now, for the purpose of the game jam (and due to licensing reasons) the player can't actually buy anything from what we will call the DLC store- but I mean, a proof of concept is good enough to get the point across.

As a famous producer once said:

Please allow us to offer this pass before we’re ready to reveal its contents. I hope only those who are confident in its value will purchase it. 

So with the leaks bound to happen, we just showed the entire world what DLC packs we could release.

Show Your Pride!

As you can see in the DLC Store screen above, it is rainbow colored! The last entry, the "Pride Pack" has a link to an article about the origins of the Pride flag, replacing the default "Purchase" button, which does nothing when the player clicks on it.

The "Pride" flag can also be see in the in-game stadium, on the sides of the video board in center field; and the rainbow streak can be seen on the batted ball as implemented previously.

I must mention that the official logo of My First Game Jam is featured right above the video board. You can't miss it!

Next

More bug fixes on the way! I love more stability!

From the previous post: I were to add features in the next few days, they may include (but are not limited to):

• Pitch height/distance variance to avoid cheating via visual computing/machine learning (hmm)
• Fireworks and night mode (dark mode)
• Time bonuses in timed mode, in some form.
• Easter eggs??

...Oh that's right, I added an easter egg in the game. But I'm not supposed to tell you about that, right?

[Day 13] Look at the Shadows

Today, I added/polished the UI elements for the non-game scenes. There will be no gameplay updates to report today!

[Day 13.2] Beta Release

At this point, the game is almost complete. In other words, if I don't get to finish adding features to Time mode, etc. as previously stated, this game can still pass as complete! That is a major accomplishment for me in this game jam, with 3 days to spare to work on bug fixes and last-minute features.

Demo

The demo for this prototype is linked here.

Controls:

• Mouse/Space (hold and release): Swing
• Mouse: Select

[Day 14] Beta Release 2

Just some bug fixes today, so nothing to see here*.

The next two days will probably have to do with recording a promotional/gameplay video for the game and submitting it on itch.io.

Demo

The demo for this prototype is linked here.

Controls:

• Mouse/Space (hold and release): Swing
• Mouse: Select

* If you include easter eggs though, then I did A LOT. Hmm...

[Day 15] Guzman HR Derby Complete!!!!!

After getting the approval of the man himself, Guzman HR Derby is ready for release!

https://itch.io/embed/449476?bg_color=0a0a0a&fg_color=d6d6d6&link_color=e53b44&border_color=333333

https://www.facebook.com/plugins/page.php?href=https%3A%2F%2Fwww.facebook.com%2Fguzmanhrderby%2F&tabs=timeline&width=340&height=500&small_header=false&adapt_container_width=true&hide_cover=false&show_facepile=false&appId=394908714489814

The itch.io submission page for this game is linked here.

Controls:

• Mouse/Space (hold and release): Swing
• Mouse: Select

Now What?

In the end, I can look back on this project and say that I completed a Unity 3D game (or more generally, a 3D game) by myself, without having to do it for a class! 

I already had previous experience with game development cycles and game design fundamentals; but this game jam was useful in that, among other things:

• It was my first game jam ever! And its duration of 16 days compared to an in-person hackathon's 2-day average duration was what made this project conceivable. 
• It got me involved in online communities. I never have a reason to use Discord, so it's nice to learn how to use.. uh, Discord. And not Piazza. Or proprietary school message boards. Or email threads.
• It added a skillset to my portfolio.  I previously mentioned my experience in GameMaker: Studio, which is technically obsolete now (in favor of GameMaker Studio 2). Adding the free Unity software to my skillset is going to help me in the long run, whenever I want to make my next game or work somewhere that uses Unity!

As for the future? I don't know what games I'm going to make next. A few years ago when I was working on games in 2D, this one nice lady one told me that I really need to make a QWOP clone. Well, my friend- that is starting to become a closer reality ;) (no promises though)

Peace out!

-Browntul (Arthur)

Development of Guzman HR Derby

Attached is a video that acts as a TL;DR of this DevLog!

Thanks for watching!

- Browntul (Arthur)