What is a Fortnite?

Posted by on Jul 24, 2017 in Editorial, Featured, Fortnite

[Sorry for the lack of images…I absolutely suck at remembering to take screenshots, so enjoy the stock footage included in this post]

Image result for fortnite

The name Fortnite is a play on words: A “fortnight” is two weeks, but a “fortnite” is a game about building a “fort” in preparation for the “night”-time onslaught of a band of monsters that have appeared across the planet after the arrival of a mysterious storm.

After some 90%+ of the world’s population mysteriously vanishes in the wake of this mega-storm, those left behind can be assigned to one of two categories. There are the survivors who find themselves stranded in the middle of the maelstrom, and then there are the defenders who find their way to a bunker run by a floating droid named Ray whose organization may or may not be accidentally responsible for the storm. Technically, Ray and her bots were set up to prevent the storm, but something bad (and unknown at the start of the game) happened and things went to hell quickly. So with Ray as the dispatcher, the players assume the role of one of the elite agents who deploy technology to push back the storm while also rescuing survivors. This is accomplished in three phases.

Image result for fortnite

The first is the gathering phase. A team of four players is placed into an open zone which might be a town or a forest (in the initial rounds). During the first phase, players must destroy trees, rocks, buildings, cars, and an amazing array of pretty much anything in a bid to collect building materials (wood, stone, and metal). Along the way players might uncover crafting materials, ammo, or special unlocks by searching shrubs, bookcases, and bunkers.

Image result for fortnite

Once the players have located their objective, they need to “activate” it in some way, depending on the story of the round. At this point, they need to build a defendable fortress around the objective, made up of walls, floors, and traps. The building can be as simple or as elaborate as the players see fit (although there are sometimes requirements of the mission to build a certain amount, less than a certain amount, or in a certain direction).

Image result for fortnite

The final phase is when the monsters show up. They appear where the storm-born lightning strikes and amble in towards the fort. It’s up to the players to actively attack the monsters, but also to use their structure to keep the hoards from plowing through the fort and destroying the objective. Monsters come in different forms, starting in the early rounds with your standard shambling zombie-esque creatures. Then there are the tanking monsters who are harder to kill, and even monsters dressed as baseball players who throw electrified shin-bones at you from a distance.

The game is very reminiscent of Orcs Must Die with the addition of the free-roaming collection phase. You have control over how much material you gather to build walls, floors, and ceilings, so it always behooves players to spend time exploring the map. Players can also uncover survivors being swarmed by monsters ahead of the main event, and helping these NPCs provides rewards. Building is advertised as being easy, and it’s no lie: you decide what you want to build (wall, floor/ceiling, or roof) and the material (wood, brick, or metal) and you just place it where the glowing outline allows. Because the monsters will attack your fort, you have to be able to repair it in the heat of battle, which only requires the right material in inventory and the press of the “F” key as you are running past the damaged structure.

Combat is fairly standard. There are ranged and melee characters, although it seems that (at least with primarily ranged characters) anyone can equip both. Rounds that I have played so far are mostly cases where everyone is on the roof mowing down the waves of monsters. I suspect that as the game progresses and both the objectives and the terrain change over time, different structures and strategies will be needed. So far rounds have ranged from stupidly easy to frantic clusterfucks where the team was running around the perimeter to take on the waves and repair the fortification. I suspect that the former example is how the game was intended to be played.

Image result for fortnite

Is the game fun? Yes. Yes, it is, although I suspect that there’s a narrow set of conditions under which this is true. For example, the initial collection and exploration phase can take as long as you like. I’ve already had fears that some rando on the team is going to get impatient and start the process while the rest of the team is spread out across the map and insufficiently packed for the next phase. I do prefer co-op games over competitive games, but some people still find ways to make things all about them. I’ve played about 50% of my rounds with all random teams and so far everyone has been either cool or just silent, focusing on the game the way I believe it was intended to be played, but we always remember the worst experience above all else, so I’m dreading the time I end up alongside one of those “blame everyone but themselves” type players. That said, playing the game with friends can be a blast. The game doesn’t come with voice comms, so a Discord setup (PC) is very much recommended.

My only complaint so far — which sounds generous until you understand that it covers everything that isn’t the act of collecting, building, and shooting — is that many pre/post round activities are horribly opaque. There are literally too many systems to enumerate here, and almost none of them are explained well enough in the game. For instance, you get “survivor cards” which can be used to build “teams”. You’re asked to slot some of these cards early on, but you can’t use those teams until you unlock certain nodes on your skill tree which, of course, aren’t nodes you unlock up front. You have two (at the start) avenues of advancement. Your research tree runs on credits earned simply through the passage of time, while skills level based on tokens you earn by completing rounds. Both weapons and playable characters can be assigned XP, but there’s no rhyme or reason to how: should we stockpile XP and test drive characters? Is the XP drop rate such that we can spend with wild abandon? And then there’s the blueprint and inventory system, which you can’t actually use until you are in a game.

We also had a bit of a hiccup in a friends-game where no one could build until I (the party leader and hence the map “owner”) gave the rest of the team permission through the shield generator control panel. I don’t remember that being explained at all, and that was an issue considering one goal of the mission was to expand the fort. I’ve also heard of issues where non-round owners couldn’t build or pick up items; I’m not sure if that’s related to the permission control panel, or just a really annoying bug.

Don’t let this dissuade you from considering the game, however. There is so much crap dropping that experimentation is easy and almost consequence-free. Between rounds, you can take as much time as you like to investigate the systems, although you might not be able to activate or use them early on. What I didn’t know was that Gearbox was involved in creating this game, which explains the game’s keyless lock box system of comically literal loot pinatas that you swing at to unleash a torrent of yet more stuff like XP boosters, blueprints, survivor cards, and materials. Like Borderlands, there’s no shortage of crap to fill up your inventory, and I say that in terms of it being a Good Thing(tm).

Image result for fortnite

Fortnite is a fun group co-op game that’s certainly more enjoyable with friends who can work together and share the same pace. Early on the mechanics are interesting enough between rounds that can range from easy-going to head-on-fire crazy-time. I have no idea what the game will be like in later stages after several dozen rounds of collect-build-defend start to get stale. I do wish the out of round systems were better explained or weren’t accessible until the system was ready to devote time to explain them. There’s a lot going on, and being able to click on things not only raises more questions than they answer but makes me (at least) feel like I’m always only playing at a fraction of the potential I’m allowed simply because the ancillary systems are just a little too black box. Still, the gameplay is fun, the visuals have their own style that lends itself to the sometimes bonkers premise, and the game has enough going for it to be either a primary progression game, or a secondary party game.

Read More »

Anatomy of A Menu

Posted by on Jul 19, 2017 in Game Development

Following not-so-hot on the heels of my not-so-hot request for UI design feedback (thanks to none of you who responded!), I wanted to post what I’ve gotten so far and talk a little about the standards that I’m going to try to apply to the UI work going forward.

As stated in the previous post, there’s not so much a “right way” to handle the organization of code and objects, but there are most certainly “wrong ways”. The quickest way to identify when you’ve turned down the wrong alley is to try and get your UI elements to work together, to access each other’s information, and to take actions that the UI is meant to enact. That’s why the hierarchy of UI elements is important.


This fine diagram to my left is what I came up with for my main menu hierarchy. I need to preface this by talking a bit about the data controller though. The data controller is an empty game object — which means you can’t see it in the game — that has one component: Database. Database is a C# script that handles tracking the state data (stuff that changes when you play, like your character and your progress) and main data (stuff that is always the same, like item stats). The empty game object that holds it is set to not be recycled when we switch scenes, so it will persist throughout the game. In addition, the code is set as a singleton, which means it is self-policing so that it ensures that there’s only ever one copy of the data.  The data controller isn’t represented in this screencap, but know that it sits above and outside of the Main Menu Controller

The Main Menu Controller is another empty game object. It is an umbrella beneath which we will find all of the UI elements that make up the main menu, the loading and saving screen, options, and confirmation dialogs like overwrite confirm and quit confirm. The benefit of this is that the empty game object can hold scripts that we can refer to from anywhere in the hierarchy, but more importantly, it allows us to make a prefab of the menu. A prefab is a “master copy” of an object that we can deploy anywhere in the project. When we make a change to the master object, it cascades to all deployed instances. If we make a change to deployed instance, we can either let that change stand just for that instance or have the instance update the master object. I’ve already created a prefab of the main menu hierarchy, which is why the text is in blue.

So what about the organization itself? There are five main levels: MainMenu, GameList, Options, QuitConfirm, and ConfirmOverwrite (yes, OCD folks, I will change the Quit and Overwrite to match naming patterns).

Main Menu is what you’d expect: the main menu. This is what you’d get when you start the game, or when you hit the ESC key while playing the game. It allows you to start a new game, load an existing game, set options, or quit.

This is where the difficulty comes in. Both NEW and LOAD share the same concept: choose a slot from three options. If it’s filled with details, we need to know what option we chose from the main menu: are we starting a new game? If so, we need to make sure the user knows she is going to overwrite an existing file. Are we loading an existing game? Then we need to get the save game data into Database from disk.

And here’s our load/new UI. The first slot is filled in with an existing game. We simply call it “Save game 1” and display the last save date. The other two slots are empty. If the user is starting a new game, she can choose the last two slots and just start the game. If she chooses “Save game 1” then we need to warn her.

If she chooses YES, then we’ll set up a new game and overwrite the slot that’s currently occupied.

What handles all of this? There are two scripts: Main Menu and Game List.

Main menu is attached to the MainMenuController game object because this handles the opening and closing of panels other than the main menu itself. One thing that UI systems need is a way to handle which windows are open and which are not. One way to do this in Unity is through GameObject.SetActive([boolean]). When boolean is false, the window is inactive. Unfortunately, when a game object is inactive, it is unaddressable, meaning we can’t tell it to show itself because it’s just not listening. To get around this, we put a script at a higher level than the object, create a property, and drag that object into the property. Now, when we want to show the windows, we do so from above the window itself…at the controller level. Currently, the main menu itself isn’t represented, which will get fixed later.

What we do not see are methods called event handlers. These are code bits which the buttons use. When someone clicks NEW GAME, the event handler “hears” the activity and takes an action. We point the button’s click event to that method in order to join the two. Here, we have three event handlers: One to display the game list panel, one to display the options panel, and one to display the quit confirmation panel.

The real tricky part was the game list panel.

In this case, we have the script attached to the UI element itself. Why not attach this to the Main Menu Controller? Well, for one reason: we need to take an action when the UI is activated — when the button on the main menu is clicked. If we put this on the Main Menu Controller then as soon as that object is created (at scene load) then those actions would fire. Since the game list panel isn’t active at that point, running that code is pointless.

The activation action runs the code within Database that loads the list of saved games. We use this to update the text of each button on the panel. If there’s a save game in slot one, then we need to change the text of slot one from EMPTY SLOT to the name and last saved date. We need to have references to these buttons inside the script in order to do this, so we create properties to hold those references. We could technically use hierarchy and search methods to find SaveGame1,2,3 buttons, but searching like that is expensive and doesn’t make the assignment visible through the inspector during design time. We also have a reference for Confirm Overwrite Panel because its visibility is controlled based on the state of the button the user presses, and the action she intends to enact (new or load).

If the user is starting a new game, then Database handles the initialization by loading the master data, creating a new Game State Object, merging data where necessary, and then making all of that available through the Database instance. If the user is loading a game, we load the master data and read the appropriate state file from disk. In the case of a new game, we will then send the user to another scene where she can make some limited customization of her character (since the character has no visible presence, it’s mostly just custom name, gender, and paper doll selection). Then, she’d have to decide whether or not to tackle the tutorial. If she’s loading a game, then we would send her to the scene where she left off when the game was saved.

So that’s it! 1300 words to describe a menu system (be thankful I didn’t include all the code!). Needless to say even something as “simple” as a menu can be more complicated than you know, so remember that the next time you’re ripping into a game about animations or physics — there’s a lot of moving parts, and what you see is only the end result of mountains of effort whose structures are really only as good as the organization of its parts.

Read More »

Secret World Legends; MasterxMaster; Ready Player One

Posted by on Jul 19, 2017 in Editorial

Secret World Legends

 

Last night a few of us folks from the Combat Wombat Discord and Off-Brand Outlet actually managed to carve out some time to meet up in Secret World Legends to run the first dungeon, “Polaris”. This was a relatively easy mission as we were all above or on the upper end of the suggested level range for the event. I hadn’t done this dungeon in many, many years and it was fun to go back to, although I’m hoping that with the renewed interest in SWL that I can actually see more dungeons in this game this time around.

Master X Master

This is a weird game. A few folks I know had expressed interest, so I jumped in thinking it would be the next Skyforge or Trove: A game I liked just fine, but which would never be my “go to” game.

Thing is, MXM is really a weird game. At first glance, it looks like a MOBA because you have a whole wall of characters that you can unlock and play as. There is a MOBA mode which plays like a traditional MOBA. But that’s not all it does. MXM has a single player element to it; you can run random zones which all end in a boss fight. You can participate in multiplayer arenas. And there’s an active social zone in between.

The game gets its name from your roster, who are referred to as “Masters” (of combat and such), but the duplicate use of the word informs you that every time you enter into a scenario, you get to take two characters with you. At any time (after a short cooldown), you can switch between them at will. Needless to say that if you thought getting good with a single character in a MOBA took practice, you’re in for double the fun.

I’ve been jumping in almost every night to deal with the daily missions for rewards used in upgrading my roster, and to gain the currency used to unlock additional characters. So far I have at least three — the two you get by default (whom I have been using almost exclusively at this point because I like them) and one character I got for free during the tutorial, whom I do not like. Interestingly, because it’s an NCSoft game, there’s crossover from other NCS games like Blade and Soul and Guild Wars 2, a la that “other” MOBA people get all breathless about. And yes, this is the game that pissed some people off by including characters from the ill-treated City of Heroes.

Ready Player One

You can stop here if you don’t want to see me getting ranty, but otherwise…carry on.

I picked up Ready Player One because no, I hadn’t read it up to this point. And going forward, I can solemnly say I will not be reading it because, for me, this book is a terrible experience.

It reads like someone got ahold of the Wikipedia entry for the entire decade between 1980 and 1989 and decided to make a novel out of every single pop-culture bullet point mentioned therein, embedding references as if the novel would turn into a speeding bus that exploded if everything that happened or was produced during those years wasn’t mentioned at least once. Reading this book felt like being at a party and having to listen to that one douche who injects himself into every conversation and does nothing but name-drop every time he opens his mouth so people know how much and who he knows. I call this condition “Crichtonitis” after the late Michael Crichton, an author who creates characters strictly to serve as a mouthpiece for the author’s enthusiastic relay of what he learned while researching his subject. Hell, I’d rather read a textbook.

Whew! OK, that was the sarcastic criticism portion of this entry, so let’s calm down a bit. Earnest Cline is a good writer. I liked his prose; it was easy to read and flows naturally. At this point, the subject is probably kind of dated. It’s somewhere between Wargames (which is mentioned in the book several times, if you see what I’ve done there) and Sword Art Online. Maybe a poor-man’s Snow Crash that aspired to be Neuromancer with a dose of Internet age attitude. That’s not a knock, because I understand that ideas are eternal, and there’s always going to be overlap and levels of engagement in any product.

In a surprise twist, I am kind of interested in the movie treatment. A lot of the grief I am slinging here is due to the fact that the protagonist has to tell us what’s going on, why, and how he’s dealing with it because it’s actually kind of bizarre: a billionaire recluse dies and leaves his fortune and company to anyone who can solve his 1980’s themed adventure mystery, all/most of which happens inside the virtual reality world that he had created. I mean, under other circumstances I could totally get behind something like this, but the wall-to-wall 80s references are just way overkill and really, really put a hard stop to the book for me. I suspect that because of what a movie has to keep and what it has to cut that the live production can let a lot of those overt references fade into the background, which is kind of true to form. Having lived through the 80s, I recognized the majority of references made in RPO, but they were never as in-your-face as they are when someone is trying to make you see them. In reality, they weren’t artifacts or stand alone references we pointed at and identified by name; they just were.

Read More »