hack.source.net’s Ludum Dare results analysis

Our fifth Ludum Dare was our first attempt at making a simple online multiplayer games. How did we do?

hack.source.net (Ludum Dare 34)

taro-ld34

hackSourceNet1

Above average. Fun, innovation, and overall stands above the 20% standing.  Innovation in particular stands at the 5% mark, and we certainly ranked within the top 100 in that category, so we’re very proud of that. Our score stands smack in-between 3 and 4 stars out of 5, so it could have been improved. Still, considering what a mess it was trying to develop this game, we’d say it’s pretty good.

How does this compare to our other Ludum Dare games? Let’s check them out in reverse order.


Can I Haz Monsters? (Ludum Dare 33)

taro-ld33

canIHazMonsters

Can I Haz Monsters? did do better than hack.source.net in comparison. Seeing that development went much more smoothly for this game, this isn’t a major surprise. A lot of players commended the dialog system in the game, explaining the rather high mood rating.


Star Driller Ultra (Ludum Dare 32)

taro-ld32

starDrillerUltra

Star Driller Ultra is easily the highest ranking game we’ve developed. The graphics above should make that pretty obvious. This is also the second Compo game (solo-only), so perhaps the ratings are more reflective of the impressiveness of that accomplishment.


Unconventional Stick Swinging Simulator (Ludum Dare 32)

japtar-ld32

usss

Joke entry Unconventional Stick Swinging Simulator is naturally the lowest ranking game. No surprises here: it’s made within 12 hours, with a portion of that time devoted in light-baking.


Laundry Day (Ludum Dare 32)

taro-ld31

laundryDay

Our attempt to make fun of free-to-play games with Laundry Day is…well, reflective of exactly what we expected people would react to the game. It’s not surprising a deliberately badly made game would get some mild scores.


The Sentient Cube (Ludum Dare 26)

theSentientCube

And the first Ludum Dare game has…no ratings, so there’s not much to talk about here.


Removing The Sentient Cube and Unconventional Stick Swinging Simulator, score progression for each game looks like this:

score

Overall has been dropping since Star Driller Ultra, since we admit being more interested in experimenting in Ludum Dare than making a polished experiment. Still, innovation and fun remains very high, which is fantastic. The rest…well, hasn’t been our focus, really. The same trends can be found in the rankings progression as well:

ranking

 

hack.source.net Post-Mortem

“Networking programming is hard,” I’ve heard, “don’t do it.” It’s been a common consensus among us programmers that online multiplayer is simply not a beginner-friendly material, let alone a game jam material. At the time, having bits of experience programming networked software in college, I agreed with this consensus. This left a strange hole in my large library of games: I have no online games listed. Perhaps it was the Ludum Dare 34 keynote that motivated me to kick this bad habit. Either that, or the Shia LaBeouf’s video mentioned in the keynote.

Either way, hack.source.net is the first attempt I’ve ever made at an online multiplayer game, and an open-source one to boot. Despite being a bug-laden, lag-filled, unoptimized experience, I’m proud of what I was able to make in the short time given throughout Ludum Dare.

What is hack.source.net?

hack.source.net is a 2-player online first-person shooter that allows one to hack and disable up to two buttons from the opposing player’s controls at any point in the game. Born out of this Ludum Dare’s theme, “two button controls,” hack.source.net forces both players to improvise as their best abilities are taken away from them.  The game is played on the keyboard and mouse, providing each player with the following abilities:

  • WASD or arrow keys to move or strafe. In the latest version (v1.5.1), only one directional key can be hacked at a time.
  • Move the mouse to look around. This cannot be hacked, so both players can turn at all times, even if a directional key is disabled.
  • Left-click or left-Ctrl to shoot a slow-moving bullet. This cannot be hacked, so both players can play offensively at all times.
  • Esc to bring up the hacking menu. While this is up, the player can still move and look around, but cannot shoot. This cannot be hacked.
  • Right-click or left-alt to briefly conjure up a shield, reflecting any bullets back to its source. Players cannot shoot while their shield is up. This can be hacked.
  • Space to jump. This naturally provides players access to higher vantage points.  This can be hacked.
  • Hold left-shift to run, doubling their speed. This can be hacked.
  • In addition to these buttons, the radar can be hacked and removed from the opponent’s screen as well.

Combining hacks allows for a variety of strategies to emerge. For example, one could leave the opposing player in the dark by disabling the forward key and the radar. Another may disable the back key and the shield to discourage the other player from playing defensively. Yet another could take the upper ground by preventing their opponent from running and jumping. It plays like the video below, which has an older build that does allow hacking two directional keys:

What went right

Using a Game Jam to learn something new

Historically, I’ve used #OneGameAMonth to learn new features in Unity 5, such as path-finding and the recent UGUI framework. This is for multiple reasons: for starts, even if my game turned out to be bunk, I still took something new and important away from it. Learning just one aspect of a game engine also helps me creatively, developing games that mechanically revolves around one focused feature. As of late, I’ve been focusing on creating Not a Clone mobile remake for so long, I haven’t had an opportunity to learn new things about my game-engine-of-choice. As such, I took the risk to learn and practice the latest UNET framework, using the hacking mechanic to justify the mandatory online connection. Even though the game is very rough on the edges, it’s still lauded for an interesting premise.

Utilizing Unity Standard Asset’s FPS controller

From experience, I knew that the majority of my time during this jam was going to be spent learning network programming. As such, I had to come up with how the game was going to be played as quickly as possible. In this case, I chose to use the first-person controller that comes with the Unity Standard Assets rather than the third-person controller. It comes with the game engine, after all, and it reduces the number of problems I would have to deal with such as camera placement. The rest of the design decisions came naturally from this first choice:

  • Players would fight each other with slow-moving bullets. This would give meaning to the built-in run button.
  • Neither player can hack the shoot button. If I were to allow it, both players could disable each others shoot button, leading to a stalemate.
  • Since the directional controls can be hacked, a player could potentially be cornered. For these situations, a defensive option is necessary, thus giving birth to the reflective shield.
  • This game favors implementing as many useful abilities as possible to balance out the hacking ability.
  • And so forth.

Quick GUI generation

Seeing as menus are a common thing that needs to be implemented in every game, I created a simple GUI manager in my Template Unity Project before the jam. Originally, the GUI manager, along with various example menus for the most common functionalities, was made for a single-player experience. To my surprise, the same code proved to be a time-saving feature for this game as well, allowing me to create a large number of menus in a short amount of time. The hack menu, for example, was simply a re-purposed pause menu that doesn’t stop time, and includes an extra hierarchy of menus that lists all the buttons available for hacking.

Incremental building, frequent testing

Perhaps due to my exposure to Agile development, I always develop with an hourly milestones in mind. In practice, this meant that the first few hours were focused on following tutorials to sync the position of two players, and testing to make sure this worked. The next few hour is focused on syncing the rotation of both players, and testing to make sure this new feature behaved properly. Next hour was on shooting, and so forth. Even the most basic feature was put into its own milestone, followed by thorough testing. To help this, I used tools such as version control (Mercurial + BitBucket) and continuous integration (Unity Cloud) so I can stay focused on coding and testing.

This strategy proved vital for this project since I was just learning network programming, and thus, prone to making errors and mistakes. By testing often, especially after a new feature has been implemented, it helps reduce the time spent on technical problems by keeping the scope of changes small.

Last minute graphical polish

I have a bad habit of focusing on graphics too early in development, which leads to a beautiful game that needs gameplay polishes. This time around, however, I worked on graphics last, which provided me more time to work out technical problems. Unfortunately, technical problems defined my entire development process of hack.source.net, so this isn’t saying much.

What could have been better

One day wasted

As it turns out, I was planning to work with barcode on MaskGarden on the first day of the jam. They overslept, however, and arrived at our real-world meeting place at around 5:00 PM. In a bit of a pickle, I’ve decided to start on my own project at around 1:00 PM. Those doing the math and correctly assuming we live in the Eastern timezone will realize I lost 16 hours. Yikes!

Slow testing, debugging

Network programming is hard. This bears repeating: network programming is really, really hard. A huge annoyance I needed to deal with while testing was the actual setup itself. For a single player game, testing a feature is as easy as clicking the play button on Unity. For networked game, I needed to build the game (a long process on its own), play it, then press play on Unity and connect the build to Unity. I would have to test both the game running on Unity and on the build to make sure when either sends a message to the server, the other receives that information. And this is before I notice something goes wrong! If something goes wrong on the build side but not on Unity, I then have to stop both, host from the build, then connect Unity to the build to check for any errors that may appear on the console. And if I make a fix, I need to go through all this process again to verify it’s gone.

Needless to say, testing and debugging a networked game is a time-consuming process. Since I was just learning how to code with networking, technical issues would occur often, and the grand majority of time developing was taken from debugging and the many attempts at fixing bugs. This experience sure gave me a whole new respect for network programmers.

Missing features

One major feature I never got around learning, let alone implementing, is the latency prediction in most online games. This is pretty huge: I knew that I needed to keep the data sent to the server to a minimum, so I could have drastically improved the user experience by making predictions to player movement and bullets. Sadly, the debugging process alone was enough to punt this feature out of the scope of the jam, leading to a very laggy game. As someone who prioritizes the user experience above all else, this is very shameful.

No play-testing

Sadly, I was never able to find the time to have the game play-tested by other players. Consumed both by the debugging process and hosting the real-world meeting event at the same time, there simply wasn’t enough time to ask others to play, let alone setup. Given this nightmare situation, I simply went with the fastest, minimal plan. Naturally, this resulted with an unstable, laggy, difficult-to-setup game.

Convoluted setup process

The current game requires setting up your computer’s firewall properly, and knowing how to obtain your own IP address to send to your friend to connect to your computer. Due to the minimalist peer-to-peer network setup, a lot of Ludum Dare judges could not actually play the game. This obviously breaks down the most important feature in Ludum Dare: the online feedback of other developers, letting you know what you can improve on next time. It would have helped if I knew how to make the process of connecting 2 players easily, such as creating a lobby server everyone can connect to and find others online to compete with. Obviously, this is well beyond the game jam scope, but it would have been nice to have.

That strange moment where a stranger was staring at what you’re doing

At the same time I was developing hack.source.net, I was also organizing our real-world meeting. Fortunately, the meeting has gone very smoothly, with our participants creating 8 new games, including become a game developer in 60 seconds. That said, the weirdest experience I had throughout this event was when we were visited by a certain tourist. To clarify, we reserved a quiet community room in a makerspace building, so while the makerspace receives a lot of tourists, the room itself remained a quiet and productive place. We did have, though, one persistent visitor who was curious enough about game development to ask if they can see what I was doing. I agreed to this, but immediately regretted it when they sat next to me, staring silently while I try to figure out what I was doing before. This experience only lasted for about 20 minutes, but it was the most awkward moment I had in a jam. I can only say I’m glad I was the only one who suffered from this.

What will I do next

Chanced are very high the next game jam game I’ll work on will not involve with networking again. The time spent on testing and debugging alone is enough to make the task unfeasible in a short amount of time. That said, for any longer-term projects (such as #OneGameAMonth), I think it’s worth learning how to create latency prediction and lobby servers to create a more streamlined experience. Improving hack.source.net, especially down-grading the power of hacking, will need a lot of brainstorming and efforts that won’t be easy to do alone. Efforts on that game will probably remain stagnant for a while as I finish developing Not a Clone.

Also, to avoid the same strange visitor incident from happening again, I’ll need to let the building organizers know that we don’t accept tourists into our area.

The post Ludum Dare update (and minor updates to Not a Clone)

Last weekend, we took a stab at creating an online multiplayer shooter for the Ludum Dare game jam. If you haven’t seen it already, it’s a fun 2-player experiment where each player can hack the controls of the other player, disabling up to two buttons. Since the original release had a lot of technical problems, we’ve created a post-jam release that improves on the following:

  1. Explosions and sparks will not sync their positional data to the server more than once.
  2. Increasing how often the player and bullet syncs their data.
  3. Made the opposing player’s animations to be much more reactive.
  4. Changed the health meter graphics.
  5. Vastly increased the range of the radar.
  6. Player avatar now appears as arrows in the radar.
  7. Added a laser to indicate the path the bullet will follow.
  8. Prevented disabling more than one directional key
  9. Shields (called “Reflect”) can now be disabled. The programmer actually forgot to enable this button, and was meant to always be hackable.
  10. Made the player avatars and their colliders much larger.

Hopefully these simple changes will improve the playability of the game.

In the meantime, there’s only a few minor updates with Not a Clone: basically our entire team are enjoying their holidays. There is, however, one new feature in works. Called “inverted mode,” the instructions of a couple of minigames may randomly change to something opposite of the originally intended instruction. For example, in a Totemman minigame, the instructions will change from “Slap!” to “Die!” As one would expect, the intended solution to this minigame would be to figure out how to kill your poor character within the time limit. Obviously, there will be a lot of setup necessary for this new mode, such as keeping track of how many times the player won the minigame before allowing inverted mode, or providing a visual indicator for more experienced players. More updates will be coming in the near-future about this neat feature.

Happy holidays to everyone!

New Ludum Dare game: hack.source.net

We’re back from Ludum Dare 34, which means a new game! We’ve attended the Jam (team development challenge) with a new challenge: learn how to program a networked multiplayer game with Unity in just 72 hours. It was a tough ride, with lots of bugs, errors, computer screen coming alive, dragons being real, and philosophy wars, but we finally got it done! Our new game is hack.source.net, a 2-player hacking FPS by Taro Omiya. Did we also mention that it’s open-source, too?

Full Description:

Is your friend over-powering you in any FPS game? No worries! hack.source.net is a 2-player FPS that let’s you disable up to two button inputs from your opposing player! Keep your friend from moving forward, take away their ability to jump, and shoot your way to victory!

Controls:
* WASD to move
* Space to Jump
* Hold the Left Shift to run
* Move the mouse to look around
* Left-Ctrl or Left-click to shoot
* Left-Alt or Right-click to put up a reflective shield
* Esc to bring up the hack menu

Created in:
* Engine: Unity
* Graphics: everything is created by Unity Standard Assets, excluding Box-chan (part of Unity-chan package).
* Music: GarageBand
* Sound Effects: Unity Standard Assets and BFXR
* Font: Fira-Sans by Mozilla

Special thanks to our Patreon patrons (https://www.patreon.com/OmiyaGames):
* Adam R. Vierra​
* Joshua Jennings
* David Lin
* Tommy Pedersen
* Jacob Clark

If you can, please rate the game, and let us know what you think!

Link to Itch.io: http://omiyagames.itch.io/hacksourcenet

Link to GameJolt: http://gamejolt.com/games/hack-source-net/114008

Link to Ludum Dare voting page: http://ludumdare.com/compo/ludum-dare-34/?action=preview&uid=20557

Some screenshots!

This slideshow requires JavaScript.

And for those interested, we have a time-lapse, too!

Reminder: Ludum Dare 34 is this weekend!

A reminder that we’ll be attending the Ludum Dare 34 this weekend, and won’t have any updates to Not a Clone. In fact, we’ll be hosting at the physical location in Tech Valley Game Space! If you happen to be around nearby, just RSVP in the meetup below, and join us this weekend in a fun 72-hour online game jam!

Happy Jamming!

Ludum Dare 34

Friday, Dec 11, 2015, 7:30 PM

Tech Valley Game Space
30 Third Street Troy, NY

6 Space Cadets Went

https://youtu.be/XVrgCgtKobIThe time has come…to make games for the 34th tri-annual online game jam, Ludum Dare!No experience in making games necessary!  This is just a fun challenge for all of us, and often serves as an educational moment to learn how to work with deadlines.  We will be going through game idea brainstorming and team building e…

Check out this Meetup →