Electrum Labs

Hey everyone.

Last week, we talked about the level design for “Elephant”. Today, we’re going to talk about a few lessons we learned from this two week project.

1. Pacing
2. Communication
3. Opportunity Costs
4. Testing

Pacing was a huge point of contestation for this project. The idea to create this complete project in two weeks in hindsight was hyperambitious. But, I don’t think this was necessarily a bad thing. To summate what we expected:

• Multiplayer
• Persistent database
• Skill/Level System
• 10 maps
• An ecosystem of weapons and armors

In the end, we knocked out 2.75 of these things (the maps and ecosystems being the decimal points). And a lot of this was due to the pacing of how things were planned. If I knew what I knew now, I still believe that finishing all of these things would be extremely difficult — but not impossible. Perhaps if we had allocated more resources towards level design and weapon/armor design finishing the list would be plausible (but that’s a part of opportunity cost). However, the pace that we were working at was absolutely gnarly. Personally, I worked on the game for about 112 hours over the course of the two weeks.

A lot of my time was spent researching the systems we wanted to implement, designing the feel of the game, and designing levels.

This pace was not sustainable.

After day 9, I found it hard to focus on level design (which was the only thing I had to do left, really, other than test).

After day 11, I really wanted to take a break. I insisted on keeping up this pace. After all, in my mind, we were so far behind in some aspects, but strangely ahead of schedule in others.

After the project was released, I was relieved. To be honest, I have no desire to replicate such a pace for a long time HAHA.

But the main takeaway is really — be ambitious, but plan well and plan often.

I think I did a poor job communicating to the modelers and artists what the pacing needed to be. In college, getting to working code was drilled into my brain — the aesthetics didn’t really concern me until it was too late. We should have had a working armor prototype by day 2, but I believe it wasn’t until day 5 where we got something going for a set of armor.

Opportunity cost is a big thing I didn’t consider either. In my senior year of high school, I was taught by my economics teacher about opportunity cost — the idea that by allocating effort towards one thing, you are taking away effort from something else. I look back in hindsight and ask: How important really was a persistent inventory system.

What could I have been doing instead? Designing more maps, more weapons, more armor, you know — all the things that make a game complete. Maybe this lesson wasn’t about opportunity costs, but the order of operations. Yeah, let’s go with that: Make sure the systems you are creating are worth creating.

We got to working code pretty damn fast, but as for testing… I can’t really say we got to test early. I think that this was an iteration problem. Perhaps in the design, we should have taken more baby steps for the AI, so that we could test over and over and over again throughout each iteration, instead of waiting for a big merge just to find out something isn’t working.

It’s natural to want your benchmarks to mean something, but sometimes that comes at the cost of progress and problem solving. We really should have detached ourselves emotionally from these day to day benchmarks, and had something that we could test often. In the future we’ll have to create a system that gets us testing and providing feedback often.

Test early and test often.

I want to conclude with this: I wanted to create these blog posts and show our failures in development so that other developers can tread the water better than we did. So while this project in my opinion was by no means successful, I do feel pride in the amount of work we got done with all things considered.

We have a new project in the works, and we can’t wait to share it with you all (don’t worry, we’ll spend more than two weeks on it).

Thanks for reading, see y’all next week.  Be well and be safe.

Bui

Hey everyone.

Last week we talked about the conception of our latest project, “Elephant”.

If you really think about it, once you create the framework for a game like this, what’s left to do? Allow me to backtrack.

The big technological hurdles for us were going to be:

• Netplay
• Authentication
• Inventory
• Skills (which was later axed)
• AI
• Modular supply spawns + player spawns
• Gunplay

So after you finish these things, what’s left for the game? Creating weapons in the future is a matter of mesh design and gameplay balance. That leaves just level design. This game is fairly simple if you think about it, it’s broken down into two mechanics: gunplay and level design.

The first level of the game was extremely important to us for multiple reasons:

• It sets the atmosphere for future levels
• It’s the player’s first point of contact with your actual game
• It’s a showcase of all the things the player should expect in one way or another

So here, we just listed the interactions we wanted the player to familiarize themselves with and tried to present it in a way that was intuitive. First, you start with opening a door, then you breach through a wall, then you hack through a wall.

But as you can see from the map above… it seems pretty lifeless. And it kind of doesn’t make sense… why am I breaching through a door right away? Wouldn’t that give away the player’s location? What’s the point of hacking the door after?

So, I tried to start thinking about things logically and pull from source files. I figured that maybe the first thing the player should do after going through a door is to hack the next door — something that is a bit more discreet than explosives going off. I liked the idea of gunplay in a restaurant/kitchen, so I based the first part of the level off of that.

The breaching of walls is a huge turning point. It’s a big “HEY I’M HERE” to the AI, so I figured that this should lead to something cool. Lately I’ve been talking to my friends about money laundering joints. Sometimes I’ll point at a restaurant or facility and say, “Hey, you think this is a money laundering front?” or “Do you think crime goes on in there?” And the beauty of making worlds, is that you get to make your own worlds.

So, the basement of “Freshman” is a nightclub.

And then what proceeds after is the “crime bosses’ office,” where the player must traverse through and get to the extraction point.

The visual inspirations for this map were the restaurants I ate at as a kid, Payday 2, and Cyberpunk 2077.

If you watched the video, you would see that the other two designed maps were blocked out and one was axed in the end, so I figured that I would post the designs here.

Interior level design is new to me, and it was a long needed break from the past ten months or so of outdoor level design. It’s common for me to walk into buildings and ask myself, “Would this be fun to play in a game? Why? Why not?” And I’m really excited to scratch this itch as time goes on.

Well, that’s going to wrap up this entry.

Thanks for reading, see y’all next week.  Be well and be safe.

Bui

Hey everyone.

Long time no talk and in this capacity — first talk.

It’s been about 9 months since the last update on “Denny”.  “Denny” is a project we’ve been working on continuously for about eight of the last nine months, but this month, we decided to take a small break and work on something else.

Something we didn’t foresee from our original projects to Denny is that developing is a marathon.  Day in and day out, it’s very hard to see your progress as opposed to our projects done in one week or one month, where every day is monumental progress in respect to the finished product.

About seven months in development, I (Bui), started to question whether the game was even “fun”.  After all, we basically have to play the game everyday, seeing little differences from playthrough to playthrough.  Not to mention, the longer it takes for you to finish something, the more obliged you feel to improve upon what you have.   I started to think, “if we take a year longer, would the quality of this game be acceptable?”

So, we decided to take a break, and kind of go back to our roots.  

Anh and I had a talk, and asked ourselves, “What is a game we’d like to play?”  or rather, “What’s a game that we can play with our friends?”  And so, we’ve arrived at a project we’ve codenamed Elephant.

Something John wanted to go back to was a sprint-like pace.  So after two weeks of development, we plan to release the game.  At the time of writing (June 23rd), this is our 8th day of development, so we have a bit of catching up to do.

My thought process this time around was to create the menus first, and then fill in the functionality afterwards.  This way, there was no doubt of how much needed to be done.  Because this game is multiplayer and requires a persistent database, we opted to use PlayFab’s services to handle authentication and persistent data. 

The biggest challenge so far is filling out this pipeline.  This pipeline contains the main gameplay loop, which is the majority of what a player will experience.  

1. This gameplay loop must be fun.
2. This gameplay loop must work.

There’s always risks to be taken when designing.  If you have a fun idea that doesn’t work, well you quickly realize that fun ideas are a dime a dozen, and mean nothing if cannot be implemented (well).

If you make something that works but it’s boring, then what’s the point?

We had a rough multiplayer and inventory framework prepared the week before we started, so our goal was to make something that worked as fast as possible, so we could find out if we needed to abandon ship or not.  Our goal was to get something playable by Day 2.

And just as planned, we got something playable on Day 7. 

We ran into a lot of problems when it came to making things work.  We “wasted” a whole day refactoring code.  I had a lot of trouble integrating things from PlayFab into things for UE4.  We had trouble with the remeshing, and haven’t even started to begin prototyping levels.  

But around Day 5, we faced our most daunting task.  

Creating the first level.

And that’s what we’ll talk about in the next blog.  Thanks for reading, and thank you so much for your continued support.  Be well and be safe.

Bui