In Part 1, I went over the chronological story of Emit, a startup I co-founded and ran with my team from 2019 to 2021. It ended up in failure, but a worthwhile failure with loads of lessons. If You haven’t read Part 1 yet, please do! This post builds off of it.

The Lean Elephant in the Room

There is an elephant in the room that has to be addressed, and anyone who’s had decent exposure to the startup world would probably have alarm bells ringing soon after they’ve started reading the chronological story of Emit.

Startups are supposed to be strategic experiments, where you do as little as possible to get the most information about what works and what doesn’t. There’s a science to the madness, and it’s called the lean startup methodology. At Emit, we didn’t follow it as well as we could have.

Frankly, it’s not something I want to delve into deeply because it’s so fundamental that you can find swathes of material online about it. At the same time, it’s so fundamental that not getting it right was harmful, so it must be addressed. Here are lean startup’s steps:

• You notice or learn about a problem
• You do some bottom-up research on the problem, while also reading on the problem.
• You start talking to people to probe the problem. I write later on in this post about how to do this properly (to summarize – do not pitch).
• Make a value proposition.
• You list your assumptions and understand the variables of the experiment
• You make an MVP (Minimal Viable Product). This doesn’t need any bells and whistles, shouldn’t scale, and often shouldn’t take more than a few weeks to make. Ideally, this MVP should test your main assumptions only, which is why simplicity is important.
• Constantly learn from the MVP through analytics and talking to (and observing) [potential] users. Refine your assumptions and iterate.

One of the big mistakes I made earlier on was that I mentally and emotionally invested myself into a full product before talking to people. I didn’t even think of the initial version of Emit as an MVP: I thought of it as THE solution. I think this mistake carried on for the rest of the following two years: a bias had been set. It became even worse when I started pitching to people and received almost unanimously positive feedback, even though it’s known from literature that feedback from pitching to friends is dangerously unreliable.

Biases hold their power because we underestimate them.

When I started doing my first interviews earlier on, I think there may have been some decent signs that the market for Emit wasn’t very strong. People seemed pretty unfazed about the problem and were perfectly comfortable with their current ways of solving it. I tried to stay optimistic though, and mostly saw it as an opportunity to get new features onto my current understanding of the needed solution instead of really assessing my assumptions. To make matters worse, I was doing this alone.

I believe this problem of not critically assessing assumptions and being attached to our solution carried on when my co-founders joined. We did do some things right – we performed several rounds of interviews throughout Emit’s lifetime, and made some informed decisions based on our learnings. However, we never really had a list of assumptions or a static value proposition to vet; we even had trouble narrowing down our assumptions and value proposition over the recovery summer.

I was aware of this problem, but for a while I thought we were lucky. We assumed our assumptions were obvious. Moreover, we had a huge list of apps that had tried something similar to Emit in the past. Some predecessors were big names like Google, some were nobodies like us. Some even became successful, at least for a while. That didn’t signal to us that this was a dead end; it signaled to us that there was demand, and that all these companies were attempting, but failing, to serve that demand.

I think Emit would have failed even if we followed the lean startup better. Under normal circumstances, our failure probably would have been sooner, cleaner and more informed if we did follow lean startup better. However, my inclination is that COVID’s influence on our timeline and testing environment made this murky. Even if we were more methodical, it still would have been difficult to determine if our problems stemmed with the testing environment or the product, and whether they were transient problems or not.

For many students of Danny Warshay, they would see the story of Emit and say we became a solution in search of a problem. This is used to refer to a situation where under-informed founders create a solution ill-suited for its intended problem and hence hop from problem to problem with the hope that they can find a hole that fits their useless key. To some degree, I’d argue that’s something that Emit suffered from; our episodes with tradeshows and Small Victories might be symptoms of that. However, I’d exercise caution on over-emphasizing that characterization, lest you think all the experiments and pivots Emit made were symptoms. We were learning about the problem space as we were building, and COVID made things more uncertain and difficult, so turbulent change and a bit of wandering should be expected. That being said, I think we could have waded through the darkness better.

Generally, lean startup is great advice, but I sometimes wonder how well preliminary bottom-up research applies to novel non-niche social platforms. When thinking about platforms like Instagram, Snapchat, Twitter or Houseparty, they mainly address wants or conveniences. It’s hard to imagine being able to talk to and observe people to correctly judge how much of a need there would be for these platforms. Neither Instagram nor Snapchat did preliminary interviews; they started as hobby projects.

We often think about these platforms within the context of their attained popularity currently. They often seem so obvious now, but before they became popular I surmise they would have sounded just as washy as anything else. This is something we also experienced at Emit; it made the interview process hard to gauge. When it comes to the social world, people make due with, and get used to, the means they have. So, due to this inherent comfort, it’s hard to tell if people will make use of a new dimension brought about by a new platform. As we know from the temporary success of the Clubhouse^[1] app, we also don’t even know how long they’ll use these for.

So knowing this, I am left somewhat torn. More thorough and critical initial research might have done Emit some good, but at the same time I’m not sure if my optimism from my sketchy initial research was the wrong way to go about it. I don’t have an answer for this specific edge case. I’m not even sure if it’s an edge case, but it’s something alright.

Why Emit Failed – Specifics

This is going to have a bit of repetition from the chronological story, but it is more focused and touches on more nuanced things about the app’s positioning itself.

Ultimately, Emit failed because there was not a great market for our product. There wasn’t enough pull getting people on our platform, and nothing we did changed that. Given our team, our product, and the type of school Brown is^[2], I’m doubt there was much we could do to change this. Eventually, Emit was no longer worth the time it was taking, and it was time to cut our losses and stop racking up the opportunity costs of building something else.

When Emit was just about food, its thematic focus was a benefit. Its focus on just food gave it a clearer value proposition and made it easier to explain its relevance. Additionally, its constraints made it easier to design and brand. Even better, its focus was a high-frequency event: people eat all the time! Biteup would focus on making it easier to see who’s available to eat, prevent the annoyance and awkwardness of messaging people regularly for food meetups, and make it easier to communicate and coordinate amongst different friends and friend groups simultaneously.

At least, in theory.

The problem, though, was that the want for an easier way to eat with friends was lukewarm. People were fine with group chats, even though Biteup was meant to be “more efficient.” Additionally, the network effect worked against us because of our low initial user count. Moreover, people were generally fine with happenstance meetings and, if all else fails, just eating alone.

So eating was a high-frequency event, but further optimizing its social dimension wasn’t really that important, at least at Brown. COVID, of course, worsened this.

When we decided to pivot to a more general meetup app, we were making a gamble as a response to COVID. We hypothesized that since our single meetup channel was crippled, a more general use case might be beneficial, even though it would result in the loss of thematic focus. The associated disadvantages were troublesome, however. Since the app was no longer specialized, people often weren’t able to differentiate it from group chats. As we did the work to teach people the difference, we saw that said said didn’t matter much to many people. They often liked the concept, but in practice, they were already embedded into the social networks of other platforms that this wasn’t worth the switch (Porters 5 forces anyone?). Emit was just making something people already did easier, but it wasn’t fundamentally changing anything.

Our switch to a discovery app (i.e. finding new people and new activities) was the natural response to this, with public flares being the spearhead for change. With this, we hypothesized that the network effect would be less troublesome since the network wouldn’t need to contain your existing friends to be valuable. Additionally, it was focusing on discovery, something that current platforms don’t really focus on.

It was good in theory, but it was its own Pandora’s Box.

One problem was the problem of motivation. Within a circle of friends, the motives for both posting flares and reading flares is clear. Within a circle of strangers, it is a bit less clear why you’d post a flare. For organizations and clubs, it’s an obvious recruiting tactic; that’s why we spent so much effort reaching out to them. For individuals, it can be a bit uncomfortable though, especially if you don’t really have that much of a filter of who will end up coming.

There’s also a little dynamic between introvertedness and extrovertedness. People who are more comfortable with the social uncertainty of posting public flares are likely more extroverted, but they’re also the people least likely to need to post flares since they have so many other avenues to reach people. This is a sad failure, since Emit was meant to be an introvert’s haven.

The concept of value is another problem we ran into.

One part of the equation is the value of the events on the platform. Niche events are great only if you have a niche audience or a very large audience; we had neither. Seth Godin recommends that startups focus on a particular niche at first and spend considerable effort making them as happy as possible. They’ll be loyal first adopters and you’ll learn a lot from them. We didn’t think we could find a niche within the Brown community that was large enough that they’d need Emit, so we decided to keep things general.

So, we postulated that Emit would need more high-value events, like parties and conferences that are generally liked by the student population. Parties turned out to be a fluke; exclusivity and information control happen to be important aspects of how parties operate. More popular open events also already had sufficient channels of advertisement.

The other side of the equation is the value of the people attending the events. As mentioned before, you don’t really have a large amount of control over the people who see and respond to public flares. For both the flare sender and readers, is there much of a guarantee that you’ll like the people going there? The only thing you know you have in common is the interest in the event; is that enough? The only way to tell is to suss them out in the chat and attend the event physically. This can end in disappointment. There wasn’t a way for people to benefit from Emit without taking considerable effort (like going to an event vs just liking a post on Instagram); that’s one thing that separated us from other platforms. So, these types of discouraging factors were dangerous. We considered implementing a, event recommendation system to combat this, but by then our confidence in Emit had already waned.

One other issue that worried us was the issue of graduation. Let’s assume that Emit was successful in getting regular users and regular flares. As people used the app, they would find more friends and more events to regularly attend. Over time, they would build their repertoire and schedule. They’d need discovery less and eventually graduate the app. To take this further, what happens when people leave school? Does the app keep relevance?

Because of the problem of graduation and uncertain value, there’s a low repeat potential for the app, meaning we couldn’t be confident people will always be coming back and stay engaged.

The feeling of commitment is another thing to battle: I may want to attend a flare, but I may not be committed enough to press the “I’m in” button and have my profile actually associated with the flare for all to see. But if everyone acts that way, so many flares will be false ghost towns. This is discouraging for both flare creators and flare writers.

There are even more variables to further complicate the equation that we hadn’t really designed for. Whether or not you go to an event, even one of mostly strangers, will sometimes depend on whether your friends are also going. And what about all the other things you could do with unexpected free time, like reading, exercise, hobbies, extra studying, or YouTube? Emit is simultaneously battling with all of them. People aren’t sitting around twiddling their thumbs

The current solution just didn’t fit into reality and wasn’t addressing a hair-on-fire problem. It was addressing a want rather than a need, and sloppily so. Even us co-founders were barely users of the app.

A little note on monetization

From day one, before Emit even got a name, I decided that Emit would not be monetized until it got critical mass. When it did, the first monetization strategy would be partnerships with restaurants. We could suggest restaurants to people wanting to eat together, and even collaborate with venues such that they give discounts if users come in Emit-facilitated groups.

For a little while we considered using this strategy even before we got critical mass to help us through our problems. Plainly, as a Band-Aid. At the very least, we thought it’d help us fix the network problem. We spoke to JJ, though, and were dissuaded. Really, it would involve trying to make a whole new marketplace (users to restaurants) to fix our initial marketplace (users to users). Maybe it could work, but what If people only cared about the user-to-restaurant marketplace in the end? We’d become like a weird Snackpass. JJ told us that the discount business is not an easy one to work in, and that we should work on our fundamental issues instead.

More Lessons

We didn’t know the Mom Test

Anyone who wants to make anything for anyone has to read The Mom Test. It’s a book about how to really talk to people in order to determine the value of your ideas. Though we already followed some of the advice in the book before we read it (only a few months before Emit ended), I’d like to think reading it earlier might have improved our interviews and helped us fight our attachment to our current iteration of Emit.

Consumer Tech is the Habit Business

This is a realization I came to after watching Kevin Hale’s video on evaluation startup ideas, and it became more obvious to me when I started realizing that getting downloads was easy but getting active users was very difficult.

When you’re making a piece of consumer tech, I think it’s often useful to think of how habits come into play. Specifically, two behaviors are in play that you’d like to manage: the habit for your users to confront the problem your startup seeks to solve, and the habit for your users to address it using your product (instead of any other product/method).

For example, imagine you were new to the e-commerce space, and you were trying to open an e-commerce store for fresh produce. You have to both get people into the habit of purchasing produce online instead of in stores, and to get them to do this on your platform, instead of someone elses.

Of course, the dynamic of these habits changes depending on whether you’re making an app that’s trying to solve a relatively untouched problem space, or an app that’s entering a crowded space.

For Emit, I think we started to realize that we had to cultivate both of those habits. People were generally fine getting in touch with friends through existing channels and meeting new people through happenstance. We had to convince them that those channels weren’t enough and that our channel was better, and ensure they keep coming back.

Gamification is a great way to cultivate habits. However, I sometimes find it to be insidious, for two main reasons. First, I think it’s a bit of a Band-Aid, because people may rely on gamification to compensate for the fact that their product isn’t a great solution on its own. Secondly, gamification can become addiction-oriented design that flips the equation from the startup serving the consumers to the consumers being trained to serve the startup. I think this is a failure of startup design.

Of course I’m not saying gamification should never be used; I’m aware it’s a tried and tested method that works. However, restraint could be exhibited to determine if it should be used and to what extent.

The tech is sometimes the easy part

Emit’s codebase is something I’m very proud of because it’s the best and most complex product I’ve ever worked on to date. Regardless, there were many parts in the startup journey where deciding whether to add a feature was far harder than actually adding it.

Initially, I had to put a lot of effort and research into architecting and designing Emit’s stack and design. But as time went on, I became used to the technical kind of thinking Emit’s code required. That’s not to say some features didn’t require a good amount of thinking and head scratching.

But understanding users, how to improve user retention, deciding which features to add, and the direction to take Emit were less deterministic than programming. I felt like a master of my codebase, but not so much for these other things. Learning was constant and my knowledge of the playing field, other platforms, and strategies increased steadily over time, but a feeling of mastery was elusive.

Being flexible

People handle times of uncertainty differently.

During the recovery summer, I saw this dynamic play out between Brandon and I. We both saw the summer as our last shot to get Emit right. To him, that meant we should only put effort into updates and experiments that had a high probability of success or a high probability of teaching us something if they failed. I, on the other hand, thought of the summer as a way to consider many things to increase the possibility of finding many maxima.

Both of us were right in our own respects. In general, it’s up to the team to find a culture that balances both. Note that this culture should be explicitly talked about. Brandon and I did not talk about it until we noticed that our differences in responding to uncertainty made it progressively harder for us to agree on even the most minute decisions. But once we did, the culture was agreed on, and it made things smoother.

I surmise that there is a similar dynamic for people (and companies) and how they handle success, where some may go into lockdown mode to ensure they mess nothing up while others try to experiment because they know they have something to fall back on if they fail.

Suss out your team

Without a capable team with good team dynamics, you cannot succeed. Whichever way you look for co-founders^[3], you need to be precise, frank and factual about who you choose to eventually work with. These are people you’ll potentially be in the trenches with for years, hence you need to optimize your chances of success. Be honest about assessing the competence and compatibility of team mates. Be very attentive to early red flags concerning things like commitment, dedication, attention to detail, and proactiveness. Find people with competency in a variety of applicable skills, and see if you can get people from the Six Thinking Hats.

I want to re-emphasize the importance of sussing out early red flags: from what I’ve experienced they often get more and more frustrating as the stakes rise. That’s not to say any presence of a red flag merits action, but sustained presence early on definitely does.

Additionally, be aware of the 4 stages of team formation: forming, storming, norming and performing. My knowledge of them made going through them less confusing and frustrating when my co-founders came on board.

Talk to your co-founders

During Emit’s recovery summer, Brandon, Nate and I were in 3 different corners of the country – Providence, Seattle and San Diego. For a while, we were only virtually meeting and talking shop, especially short-term things. But after a while, our interactions started to feel transactional. So, I started doing spontaneous one-on-one calls with my co-founders. I asked how they were doing. I asked them about what they thought about features. We’d have long brainstorming sessions. I wanted to be able to gauge their mentality irrespective of the other person. I wanted to get to know them more again. I needed our team to have a human component, and I also needed us to have more honest conversations about our thoughts about Emit’s trajectory.

These were some of the most productive and impactful calls of the summer, and definitely brought me closer to Brandon and Nate. I wouldn’t necessarily say I was the leader of the group – we tried to remove hierarchies at Emit. But as consultants Morriss and Frei revealed during their consultancy work with Uber, it’s important for leaders (or, in our case, team members) to show that they care about their team members in more than just a business manner. It built trust and understanding.

Funding isn’t always default or a goal

Oftentimes when I talk about Emit to folks, one of two questions is the first one asked by my audience: “How many users do you have right now?” or “When do you guys think you’ll seek investment?”

I had no problem answering the first question, even though sometimes I’d be embarrassed exposing how poorly Emit was doing quantitatively. For the second question though, I often had to remind folks that my team and I were consciously not placing investment in our timeline.

I understand where this question is coming from. I can imagine that from the outside, the startup world sounds like the world of investments and acquisitions. That’s what’s in the headlines, and that’s what excites many. And for many startups, investment is a must in order to scale, especially if you’re R&D-driven or capital-intensive venture. Investments, however, come at a cost, like equity and control costs; investors will likely influence decisions. But more than that, there’s the cognitive overhead of looking for investors, of changing the startup to be favorable to investors, and of factoring in this favorability into further decisions down the road. For a fast-moving startup with lots of variables to balance, it’s not always a good idea to bring in additional variables that are not needed.

I’ve had conversations with folks that were trying to contribute to Emit whose perspective was solely investment based. Their sentences often ended with “that’s what X did and they got Y amount of funding,” or “because investors like that.” I’d argue that it’s not a good way to think because it shifts the focus away from the problem and users.

Getting investment capital should never be the goal, you need specific reasons for every penny of it. It’s only a means to an end, don’t go for it if you don’t need it. It can be a great distraction that can derail you. If you can, see how far you can go without it. Its absence may keep you more focused; the scarce resources may stave off complacency, and the constraints may bring more innovation. The best innovation is birthed from constraints.

Want some examples of companies that went far without any funding ever? Mailchimp and DownDog.

No one outside your team should be relied on early

Everyone has their own reasons for wanting to work with you, and no one cares about your startup more than you. When dealing with folks outside of your team, you have to make it very obvious early on what the benefit is to them. Additionally, you have to understand that since they have considerably less skin in the game than you (if at all), they often have little to lose from just abruptly cutting contact and stopping collaboration with you if they no longer think you’re worth the time or effort.

Many people are just flaky.

Numerous people we’d been in the middle of talks with for partnerships or symbiotic relationships simply stopped answering calls and texts. They had nothing to gain from even stating that they no longer had interest.

Don’t rely on folks too early, and expect flakiness from many.

Momentum is a valuable resource

For student founders, there is a lot to distract you from your startup, especially studies. Studies are technically a fulltime job! One of the things I realized is that if you don’t maintain momentum in your team, everything else steals time and mental bandwidth, and the startup lulls. There’s been times where the whole team would get discouraged or sidetracked, and one blink afterwards we’ve gone three weeks without progress.

Be sensitive to lulls, dips in momentum, and dips in motivation. Short bouts are natural; long ones are dangerous.

Be strict, but not possessive, over code

When my co-founders first started adding their code to Emit’s codebase, it had already existed for a year. I had a large attachment to it, and they had a lot to learn to be able to contribute cleanly to it without adding lots of technical debt. So, initially, I tried to silo them. I tried to make sure people only worked on the simple things while I took on the harder tasks. For a while, this worked, since it also provided a relatively simple and safe way for them to learn about things without breaking stuff, blocking people, or making code that would have to be thrown away.

But after a while, when I got busier (especially over the Amazon internship), I became a blocker myself because everything that needed to be done was considered a “hard” task and hence under my jurisdiction. So, for the benefit of the team and the product, I had to let go. Delegation increased. Back-and-forth code reviews increased. Production was broken a few times. I wrote more documentation, and taught more.

Over time, though, my co-founders got better, and needed my help less with every pull request. There were even times I saw flaws in their designs, but because I wanted them to feel ownership over their features I didn’t mention solutions until they came to me explicitly.

You cannot expect your team members to learn and improve if you do not give them the space and trust to make mistakes and feel ownership.

Having a marketing-oriented person

Startups are really only as strong as their teams. There were many respects in which I think Emit’s team was strong. We had good technical prowess, useful networks, good chemistry, and some decent branding and UX capabilities. One thing we missed though, was a strong drive to get out and market the product face-to-face with strangers on campus. We did it a few times, but I think it was harder for us than it should have been, and it was infrequent.
Next time, I think I’d put a higher value on a team member who’s able and willing to do such marketing frequently and intelligently.

Sometimes good design takes data and time

This is something I got used to when I was really into game design and graphic design before Emit. I’ve even written a bit about it. Good design, like logo design or UX design, often requires intentional constraints and immersion. This is something I encountered many times when I was designing the brand, UI and tech behind Emit.

I’m super happy with Emit’s logo, but it took several weeks to get. Before Emit, I had already learnt a lot about logo design for previous projects. Nonetheless, I spent weeks looking at hundreds (if not thousands?) of logos and determining what I do and don’t like for Emit’s intended brand identity. I also spent that time looking at which designers I can and cannot afford, and started reaching out to some. I wrote brand specification documentation for my to-be designers. I learnt how logo designers think and prefer to be treated. Even after all this, the first designer I hired didn’t make something I liked; it was a sunk cost.

A similar process goes for many parts of Emit’s UI: they were the products of hours of looking at what worked and didn’t work for other companies and how that blends in with our constraints.

If you want to be able to make consistently good designs, you have to make sure you’re constantly feeding yourself data to draw from, and that you’re also giving yourself time to ruminate and iterate in your mind and on paper.

The team realized the hallmark of a good designer is someone who has optimized this process to make a profession out of it. They always ask for constraints and what we do and don’t like. They’re always immersed in the designs of others, and often need time to make gold.

Please mind the paperwork

This is a simple point, but an important one. Remember that startups are small companies. Trademarks, contracts and copyrights are important, even if the startup feels too informal to require them. If those are not taken seriously as a precaution, copyright claims, equity, trademark conflicts and more may come and bite you in the back when you grow and incorporate.

Take the time to make even basic paperwork for this. Emit was trademarked (we did this the semester of our launch). The founders had an MOU. We made contracts for contracted designers.

Off to a new journey

That’s it! I hope you were able to take something away from this long post.

Emit was quite the journey, and it’s one I’m extremely glad I embarked on. I made great professional and personal connections, learnt a lot about entrepreneurship, and discovered a career path I will seriously consider for years to come. The journey of being a founder is a hard one, but it’s extremely fun and rewarding, even when faced with failure in the end. The journey is the reward.

I’m always happy for folks that I see who are embarking on the journey. I have an even higher level of respect for the successful ones I see around me. I sometimes even advise folks who are early on the journey  – imagine that! For example, I advised a group who was early in the process of starting a platform similar to Emit; it was such a “full-circle” kind of experience.

To all else wanting to give startups a try, please do. Learn the process, find a problem, get a team, and start. There is nothing else you need to do; you must start. You’ll be way ahead of most of the curve already. Once you start though, you must put in the hours. Half-assing is a ticket to true failure: your startup will fail and you’ll learn nothing. It should consume you and you should give it your all, akin to an obsession.

It’s funny, though. Many career paths now seem mundane or insignificant to me after such a journey. I’m now stuck trying to find the next problem to solve that will captivate me as much as Emit’s did, and I wonder how long I’ll be in the standard 9-5 software world before I can escape and try once again.

No matter; I’ll search as long as necessary.

Signing off for now.

^[1] Clubhouse is an audio-based social media platform that exploded in popularity in mid 2021. Its peak in popularity was temporary.

^[2] Brown, especially during COVID times, isn’t necessarily the biggest party school.

^[3] You might want to look into the “power of loose connections,” a piece of advice on how to properly look for co-founders.

The post The Life and Times of Emit Part 2: The Lessons <br /> <span style='color:#787878 ; font-size:16px;'><i>The lessons from my first startup and my best failure yet</i></span> appeared first on Loading Developer.

Looking for the second part? Click here.

It’s fitting that the longest post I’ve ever written so far would be about the longest project I’ve ever undertaken. For the past two years, from about November 2019 to November 2021, I had been working on my first startup ever. While there were periods of hiatus, it was the personal project that got me through my first two and a half years of Brown University and through the COVID pandemic.

But alas, at the end of the day, it ended up like 90% of its brothers and sisters – in failure.

So, this blog post has two purposes.

First of all, it’s a medium of reflection. I’ve made a lot of great connections through this process, and I’ve also learnt a lot of entrepreneurial lessons. I can’t hope to write them all down here; that’s both difficult and unnecessary. However, what I don’t think is unnecessary would be explaining some of the specific things that brought about this startup’s downfall. This would both solidify my lessons and also serve as an answer to anyone else who wants to know why we failed.

During my time writing this post, I met a man on a train from Boston to Providence who was the founder of a consultancy firm and the vice chair of one of Boston’s entrepreneurship networking companies. I love it when these types of random interactions happen; I always get nice nuggets of conversation or ideas. He told me that I shouldn’t think of this post as a post-mortem, but as a reflection. “Parts of Emit will live on in future startups,” he said.

This leads me into the second reason for writing this post – failure stories are important. There’s a twofold danger to only learning from successes. Firstly, you often won’t hear about as many things successful companies did wrong because they aren’t as interesting/exciting/inspirational to talk about as things they did right; their mistakes might not even be as known because their consequences were overshadowed by the things they did right. Secondly, it doesn’t give you a full picture to judge your decisions with. If you have a portfolio of only success stories in your mental vault, and you’re trying to decide if you should do something those protagonists never did, how do you know if they never did it because it’s something to avoid, or because they simply didn’t need to/want to?

So, this post is going to be somewhat of data dump with reflections afterwards. It is going to be pretty long, because there’s so much in Emit’s failure story that I don’t want to perform lossy compression and compromise on the learnings.

Oh, and one more thing. I don’t do affiliate links here, so no link here is sponsored or monetized. Click away!

Okay, I’ve set the stage! Let’s get going.

What was Emit?

Emit had a number of pivots, but it was always centered around tackling the problem of imperfect information. Essentially, Emit was a platform that was centered around making it easier for college students to spontaneously find things to do on campus, with a focus around things that are happening within hours.

The Emit team and I thought of the app as a discovery platform for events and opportunities to meet new people. Event broadcasts were called flares, and they could be sent by anyone. If the sender wants as much visibility as possible, flares can be sent to all nearby users’ feeds. Otherwise, they can be sent to specific friends’ and groups’ feeds.

Events could be anything, from club meetings to a cappella recitals to impromptu frisbee games. Flares could be viewed either on a map or on a conventional list feed. They contained time, location and live participant information, as well as anything else the sender desired.  Joining a flare also lets you chat with others who joined the event, and flares are automatically cleaned up once the event is over, ensuring that only flares for relevant events are visible.

Emit was never meant to be just for colleges, but we thought colleges were the ideal environment for this type of product (also it was the environment we were immersed in). So, we intended to grow it in that environment before expanding to other use cases.

Some screenshots of Emit:

Emit’s Chronological Story

It’s important to have knowledge of Emit’s entire timeline before going over its strengths and weaknesses because everyone would have the ability to apply hindsight.

The Mustard Seed

Emit started as an unnamed solo project that I started in the later months of my first semester at Brown University in 2019. At the time it had a much more specific target – food. I was tired of the tediousness, awkwardness and inefficiency of finding people to have lunch with during the busy weekdays. Texting people would often result in ghostings, “no”, or “I already ate.” Moreover, it’s tedious to have to text a bunch of people on different platforms asking if they want to join me; I also had to regulate how often I texted each person so I don’t irk them with daily texts for lunch meetups.

After one ghosting too many, I decided that this was a problem I wanted to dedicate time to solve. I immediately identified the problem as imperfect information about who is available to eat, and started planning the platform that would solve that. This platform would make it easier to have spontaneous food-based get-togethers with friends. To gauge interest, I started talking to my friends about my plans; feedback was almost unanimously positive.

I started researching the possible cloud platforms I could use to build my stack^[1] and settled on React Native + Google Cloud Platform^[2]. In December, I started programming the smaller parts while architecting and planning the larger parts of the platform and settled on the name Biteup (pronounced similar to “meetup”). I also made pitch decks to pitch to friends, mentors and my Presidential Scholar’s cohort. These were not investor pitch decks – I had 0 interest in investors.

Some early sketches of Emit:

Christmas break was spent learning all the nuances of Firebase while also starting the implementation of some core features; this continued into the spring semester.

In late January 2020, I decided that this could be a very serious entrepreneurial project, and decided to talk to someone from Brown’s Nelson Center for Entrepreneurship. I ended up meeting Danny Warshay – the meeting didn’t go the way I expected.

I pulled up to his office very excited and bubbly, and showed him my pitch deck and working prototype. I don’t exactly know what I was expecting. Maybe some secret sauce advice, or even just idea validation. Instead, he told me that I was doing it all wrong. He said I was clearly talented and passionate, but I was operating within my own world and hadn’t properly researched the users I plan to serve. I was setting myself up for failure. I told him I had been pitching to people and that feedback was overwhelmingly positive. He cautioned me that the positive responses were invalid because I was using the wrong feedback gathering methodology. He advised me to do better anthropological research into Brown students to see if Biteup is even needed.

I somewhat knew that he was right, but frankly I didn’t feel like putting myself out there. I was comfortable living in a mindset where my code and passion for the project were the only things that mattered. Like almost everyone else, I felt like an exception.

Nevertheless, I conducted a short episode of interviews. Insights were not forthcoming. I did realize, though, that the problem I was trying to address didn’t seem as urgent to others. Regardless, I figured people would come around when they realized how much easier Biteup made things.

I continued on steadily with development. By the time Brown evacuated its campus due to COVID, Biteup was more than a minimum viable product.

The later part of spring and all of summer were spent on polish and extra features. I also developed a brand identity and hired designers for a professional logo. The logo process was surprisingly expensive, involved, long, and interesting; I’ll touch on that later on.

The Wall

Biteup was shaping up to be a pretty impressive personal project, and I had gotten a lot done despite occasional haituses. COVID, however, presented a particular problem. It was quite literally one of the few things that could have prevented me from finally getting this product into people’s hands. The next semester was going to be completely remote and the one afterwards, unbeknown to me, would end up being hybrid with limited physical contact. Biteup simply wouldn’t thrive in such environments. The more the magnitude of this barrier became apparent, the less feverishly I worked on Biteup.

It was also around the summer time that I started consuming more media on entrepreneurship, like the How I Built This podcast. Building Biteup and treating it as more than just a technical side project was challenging yet fulfilling and made me consider entrepreneurship as a career.

I was not on campus during the next semester (sophomore fall 2020). This semester was completely virtual, and I had no idea on how to progress with Biteup. I had hit the wall. So, I spent my time learning about entrepreneurship in general through workshops, talks, podcasts, videos and zoom meetings.

This impasse ended in late December with an email from a fellow student. Brown’s entrepreneurship center had mentioned me to 3 students who were thinking about solving a similar problem to Biteup’s. Their names were Nate Goodman, Brandon Li and Eyal Levin. I nonchalantly agreed to meet, and I was pleasantly surprised and refreshed. These guys were the first people I spoke to who understood Biteup as deeply as I did.

They had already started a long round of student interviews to better gauge the problem space – they were doing the interviews Danny had suggested to me so long ago. We were a good mix – I had the platform and they had already started some of the more user-centered work that I hadn’t done. So, we decided to join forces. We continued the rounds of interviews, decided to generalize Biteup to more than just food meetups and started giving the app a UI overhaul to fit its new generalized purpose. This overhaul process also had its own round of feedback interviews in-between design and implementation.

The Launch

Finally, sophomore spring would be Biteup’s launch date. The semester was hybrid, but with Biteup being generalized to any type of physical interaction, we thought we could slip into some of the cracks and gain some traction. During this semester, we also worked on Biteup for course credit. So, we had the guidance of our professor Jonathan Jannotti (AKA JJ) and worked in the same course as other entrepreneurs, such as the founders of Zaar and Hometown Academy. From the course and from our own network, we were able to interact with the founders of DownDog, Monthly and Pangea (amongst others) for advice. This constant exposure to external entrepreneurial stimuli acted as a source of many reality checks.

A lot occurred in that semester, as would happen in the first months of any startup’s launch. We changed the name from Biteup to Emit, and released our product to the Apple and Google app stores. We started our first targeted download campaigns. We started by slipping business cards under all the dorm doors of Keeney Quad, the largest freshman dorm at Brown University. It was fun, but proved ineffective. Next, we had a few sessions of going to the main quads and giving out candy to anyone who would sign up for the app in front of us. We got a couple hundred downloads from that, and about 100 accounts.  That, in our books, was a success.

As the adage goes, “You only succeed in what you measure”. So, we started adding analytics to our app. For part of the semester, we also experimented with Emit being a platform for virtual meetups by hosting a couple game nights. We got few attendees, and the virtual experience was clunky., We surmised people had had enough zoom fatigue from classes that they also didn’t want to participate in more virtual experiences for leisure. Then again, it was hard to tell due to sparse usage.

Most importantly though, we started seeing how people actually used and perceived the app. We started seeing people’s confusion when we were explaining its value proposition.

“I’ve heard about you guys but I don’t really understand what you guys do.”

“What’s the difference between this and a group chat?”

We started seeing people’s light bulbs turn on (or stay off) after we explained it further.

“Oh, that’s a really cool concept!”

“I wish more people were on it, then maybe I’d use it.”

We started seeing more problems with UI and making over-the-air^[3] updates. We started experimenting with more features, including friend recommendations, contact book integration, or public groups (before that, all groups were invite-only). We got a lot of feedback from multiple sources, and had to start prioritizing and scheduling features that mattered. Our Asana lists were getting pretty large as a result.

As we hosted game nights on the app, and as a couple of people also started making their own flares, we started to see that some of our assumptions about people’s motivations to make or respond to flares, and how often they’d even be able to do that, were wrong. In some respects, which I will detail later, we started seeing that people had less reasons to respond to flares than we expected. It also became clearer to us how difficult it is to overcome the network effect as a new startup.

Recovery Mode

By the end of the semester, we had made some victories, but also been presented with many existential questions about Emit. Why was retention so low? How can we make the value proposition clearer? Many people didn’t know how to justify Emit’s existence in the face of group chat platforms. How can we make it easier/more worthwhile for users to use the app when not everyone they know is on it? We’d learnt a lot about the power of analytics, user journeys and intentional iteration, but we had such little user interaction that we couldn’t really determine if the problems of low retention and an ambiguous value proposition were due to the network effect or from a fundamental flaw in Emit. This poor understanding of our problem made it hard to find solutions. So, when other founders gave us advice, we couldn’t really see how they could fit in the puzzle.

We saw the next semester (my junior fall) as our best shot at attaining some level of market fit at Brown. We thought that people were going to be eager to do things after a year of COVID restrictions, and if we failed to get it right in the face of such an opportunity, our chances afterwards when people revert to normalcy were slim. Many startups’ successes are highly dependent on their timing, and while the time during COVID was the worst possible period for Emit, the time after COVID’s peak might be the best.

With the departure of Eyal from the team, the rest of us were determined to fix Emit over the summer in preparation for the fall semester. My remaining co-founders joined Brown’s startup accelerator Breakthrough Lab  (AKA B-Lab), while I interned at Amazon and committed to working on Emit after-hours.

A lot happened that summer. Frustratingly, much of it got us nowhere until the tail end of the summer. Initially, we were a bit scattered about what it meant to fix Emit. After all, we weren’t exactly sure what was broken. So, we tried simultaneously fixing as many things that could have been broken, even if we were skeptical of the significance of some of the things we focused on.

We held interviews for UI designers early on, and almost contracted one. Eventually, we dropped it. UI wasn’t a fundamental problem, and as Adam Alpert told us “If your product really solves a problem, people will hit themselves with a brick to use it.”

We considered exploring other markets beyond the college environment to see where else Emit could fit in. A product like Emit thrives where there are lots of people in a close geographical area that want to meet in subsets for whatever reason. After some brainstorming with a B-Lab mentor, Jason Harry, we decided to try the tradeshow industry. We imagined Emit as a platform for people to have a better understanding of what’s going on in large trade shows. After talking to trade show organizers though, we dropped this too. We simply lacked intrinsic interest in  tradeshows, and also concluded that Emit would need to be a very different product to satisfy their needs.

One interesting thing that occured is that Emit began to be used by some interns in my Amazon internship cohort in Seattle, at least for a while. They used it for the opposite reason Brown students did. Instead of having too little information about what was going on, the Amazon interns had too many channels for events (i.e., Slack, Discord, Snapchat groups, word of mouth). Emit acted as a great centralized platform designed just for events, and some folks loved the simplicity and readability of it.

Truth be told, we didn’t really know what to make of this new type of motivation and we decided to treat it as a serendipitous anomaly. Nevertheless, we tried to take advantage of it by attempting to get interns to take Emit to their colleges and help its propagation. So, we ran a sweepstake to increase usage and hopefully get some new users to talk to. We only got a couple of responses, but tried to keep in touch with the folks who genuinely liked the app. Our efforts eventually withered when interns started getting comfortable in their cliques.

One pivotal thing we did early on was to implement and release public flares. Public flares were broadcasts that could be sent to appear on the feeds of nearby users, not just people you know or members of groups you’re part of. It was a feature that was repeatedly requested for in the previous semester, and it added a completely new dynamic to the platform. It also, eventually, became the catalyst for us to critically think about our value proposition.

We began to appreciate that public flares showed more value than its predecessor (we called those private flares). It became easier to explain to users what made Emit different from group chats. Over the summer, we sought to form partnerships with lots of clubs, and the value of Emit became more convincing when we portrayed public flares as a recruitment mechanism. Public flares also made new users’ journey smoother, since they could immediately see public events upon signing up without having to join any particular group.

We initially brought in public flares as a secondary feature to grow our userbase, under the assumption that eventually people will start to make their own groups and social networks and resort to using the classic private flares. The problem was, the introduction of public flares no longer made Emit an app about doing spontaneous events with friends. It made it an app about doing spontaneous events with people who are more or less strangers.

That was a value proposition change. Another pivot.

We eventually came to terms with this pivot over time, particularly after we forced ourselves to refine our value proposition in preparation for Product Hunt^[4].

Brandon and Nate deserve credit for being the spearheads for navigating this pivot for the team; I had less bandwidth at this time.

While all this was happening, we were also thinking about (and sometimes implementing) new features, like scheduled flares, editable flares, sending flares to non-users via SMS and anonymous accounts. We also started developing a feature for users to join flares only after a certain number of other users expressed interest, so you can avoid the awkward situation of being the first to commit to a flare. This feature was never released because the semester started before we could finish it.

It was a packed, difficult, sometimes worrying, but ultimately a fun summer. While balancing my internship, I was being a PM and technical lead of the Emit team. We had several code reviews over Github, and regular progress reports in the morning where we tracked progress over Asana. We were having to grapple with the pivot, new features, what we should/shouldn’t do, and how this pivot will affect Emit’s trajectory and brand.

Despite our pivot, we remained uncertain of our success. Many of the decisions we had made were based on thought experiments and founder-to-founder conversations (though we had conducted some interviews with users). We needed a new launch to see if this new Emit could attain market fit. As the summer ended, and our co-founder Nate left the team to start his full-time job at Amazon, it was left with only Brandon and I. We got ready for one last go.

One Last Chance

About a week before the semester began, Brandon and I decided to start “faking” the supply of flares. Every morning, Brandon would look through Brown’s underutilized event noticeboard (Today@Brown) and post flares for interesting events. Generally, artificially creating supply is a common tactic digital marketplaces use to get off the ground; we decided to give it a serious try.

Our months of Zoom calls with different clubs and organizations had resulted in at least a few that we were reasonably confident would try out Emit as a recruitment medium. However, it wouldn’t be until Brown’s activity fair one week after the start of the semester that clubs would start having meetings. We attempted to use the booths of these promising clubs as advertisement sources during the fair, but it didn’t really amount to much. About 2-3 weeks later, it became apparent that none of those clubs would be of much help. Most didn’t really follow through with their commitment of posting their events and getting their members to use the platform.

Following this failure, we decided to try and make Emit a party app. We figured that if we could market Emit to party organizers and goers, it would be a gateway to get Emit into people’s hands for other purposes. We wanted to target Providence College, which was much more of a party school than Brown. So, we hit up the Old Irish Social Club – a bar nearby the College. We met no Providence College members that night; the bar was taken over by Brown students! We ended up meeting one Brown student who was well into the party scene and was willing to help us test out the party domain at Brown.

At around the same time, we also teamed up with a TikTok star (Over 4 million followers at the time) who was willing to help us use her fame and knowledge to get Emit into the party sphere of other schools.

Simultaneously, we started getting some press. A bit of a distraction, honestly. We had an article written about us in Brown’s main newspaper, and also had a video-pitch to a virtual crowd of investors and entrepreneurs as a way to conclude B-Lab (which actually ended 2 months prior).

By late October, it was clear to us that our party-app approach wasn’t working. The fellow from the bar underdelivered. We also discovered that people prefer the preserve of exclusivity in their party invitations, which Emit was pretty antithetical to. Moreover, our TikTok star was unfortunately unable to affect our analytics that much, or get us into other schools through channels like Barstool.

Momentum was very low at this time. For the first 3 weeks of October, only about 70 flares were made, the vast majority of them by us. There were only 43 views, meaning a flare had a 50% chance of never being tapped by anyone. To top it off, there were only 2 people who officially joined a flare in that period.

 At this point, the light at the end of the tunnel was becoming increasingly faint.

Throwing in the Towel

Brandon was still trying to go strong, but I was starting to come to terms with my premonition that we’d reached the end of the road. Keep in mind that for two semesters I had been taking entrepreneurship courses and reading several case studies about failed and successful businesses. Whenever I thought about Emit’s progress, the dissimilarities with the successes worried me.

To either confirm or debunk my fears, I decided to have a call with Boon, one of the investors that we had met at the B-Lab video-pitch.  As I did with most people I spoke with, I was planning on taking his advice with a pinch of salt.

That call completely confirmed my fears. He was frank about the fundamental issues he saw about Emit, and why he thought it would not succeed. We’ll get into those in a couple of sections later. To me, it wasn’t that he was just listing issues. It was that some of the problems he saw as blatantly obvious had taken Brandon and I months to find out. It was a wakeup call to me about our porous assumptions and weak assessment abilities. After that call, this was the last nail in the coffin. I was ready to end Emit.

I told Brandon about this call and about our few options left: keep trying, sell the code, or just stop Emit all together. We agreed that we’d stop, but only after trying one more thing. A grasp for straws, honestly. About a week earlier, we had gotten in touch with  Small Victories, an organization that threw massive popular college parties in Providence. We wanted to be their vendor for last-minute tickets. We figured if we could link flares to their events and get Emit popular through them, we could expand afterwards. Our pilot was somewhat successful, we sold out in a couple seconds. But that was because they gave us less than 10 tickets to sell. They simply didn’t really need us; talks with them later on confirmed that.

5 days later, on 6^th November, Brandon and I met up and agreed to end it all. In the days that followed, I sent a final email to our users, set the app on auto-pilot, deleted plenty of our cloud infra that was no longer needed, and open-sourced the code.

We drew the curtains – the show was over!

What went wrong?

If you made it this far, thanks for reading. In Part 2, I’ll go over some of the many things we learnt while running Emit, and also give a critical analysis of what went wrong and where we could (and couldn’t) have done better.

See you there!

^[1] A stack is the set of technology tools and platforms used to build software.

^[2] React Native is used to build mobile apps with Javascript, Google Cloud Platform is a cloud computing platform.

^[3]These types of updates do not require developers to re-upload their app to the Google and Apple playstores, making update deployment much faster.

^[4] Product Hunt is a popular platform for announcing launched (or soon-to-be-launched) startups. This Product Hunt blurb was written as we were still navigating what the value of Emit was.

The post The Life and Times of Emit Part 1: The Story <br /> <span style='color:#787878 ; font-size:16px;'><i>The story behind my first startup and my best failure yet</i></span> appeared first on Loading Developer.

“Aaall aboooard the the Aaaaamazon Twiiiisterrr!” yelled the rollercoaster operator with the handlebar mustache. Our protagonist Andy stepped in line, along with the other bright-eyed and smiling to-be riders; the Amazon Twister is the talk of the town and tickets can be hard to come by. The inevitable chit chat helps pass the time as Andy steps closer and closer to hit seat. “Click!” goes the safety restraint as he’s strapped in. Anticipation builds. “Let’s see what the Amazon Twister has in store for me!” Andy ponders.

I wasn’t really sure what to think when I first got my spot in Amazon’s 2021 summer SDE internship. On one end, I was super excited about the opportunity to use my skills in an actual work environment, peer into the actual world of SDE work, and just try something new. On the other hand, I was nervous about working in such a large company like Amazon, especially since up until then I’d been the sole developer in all the games, apps and side projects I’d done. Collaboration is great (really, it is!), but the associated sacrifice in individual freedom can be a bit frightening sometimes.

The Amazon Twister might be the best ride in town, but its not necessarily a walk in the park! Before the ride begins, an onboarding video is shown on the monitors on the backs of the seats. “Huh, you don’t see that everyday,” Andy remarks.

First things first, I loved Amazon’s onboarding material, both from a technical and a non-technical perspective. From the outside, Amazon’s Leadership Principles seem like kind of a trope, and even some internal communications during my time there may make it seem so. However, the talks, anecdotes, and courses within Amazon’s onboarding material gave me some practical insight into how those principles are used and what effect they have on Amazon’s way of doing things.

To provide you with some context about my perspective, I should mention that I’m not usually someone who programs for the sake of it. Yes, programming is fun, but to me it’s ultimately a means to an end – a means to bring about creation and change.

So as I learnt about the early days of Amazon, their “It’s always Day 1” principle, how they manage and create small teams, what “customer obsession” actually looks like and works, the Empty Chair Principle, Customer Anecdotes, and the concepts of working backwards, Press Releases before products, and team tenets, I realized there’s actually a lot a startup founder like me can learn from it.

The ride jolts into motion, even before the video is over! “No time to waste!” the grinning operator declares. The cart starts escalating upwards. Tick…tick…tick…tick it goes as it rides up the chain to the top of the first (and largest) drop-off point. “The first rise is always the scariest,” Andy reminds himself.

The onboarding material was also helpful from a technical standpoint. It was relatively thorough and very easy to follow. That, however, doesn’t necessarily mean all of technical onboarding was easy to complete. Amazon is a company with impressive and mind-boggling scale – you truly don’t realize how large Amazon’s engineering is until you’ve worked inside of it. That size, however, translates to their stack as well. They have a lot of internal tools and layers, and to get something decent and quality going you have to use and understand a decent amount of those tools. There’s always more to their stack the more you dig.

Might be endless, to be frank. ¯\_(ツ)_/¯

It was rewarding to see me get used to their CI tools, build tools, dependency tools, container tools, permissions tools, website-generation tools, security tools, and the tools they use to manage internal AWS accounts. One of the things that made it rewarding, though, is that it was hard. I was being thorough because its important stuff to understand well from the get-go. I wanted to be sure that when I start my project, I’m starting it off right.

This is probably a good time to talk about what exactly I was tasked with building.

Over the summer, I was part of the Ingestion and Storage team for Amazon Timestream. Timestream is an AWS timeseries database service with some pretty large customers, including Disney Plus. A hallmark of timeseries data is that it is produced in large amounts, so in order to facilitate the large amounts of throughput needed for ingestion and storage, Timestream heavily utilizes partitioning.

You can think of timeseries data as a series of points on a 2D graph of an arbitrary measure (like temperature) against time. So, if you wanted to partition that ­very large and very dense series, you could split that graph into rectangular segments called tiles.

The way tiles are created and how they are split is an important thing to perfect, since it can affect data availability, ingestion speed, query performance, and everything in-between. Moreover, it’s important that the developers thoroughly understand that algorithm and have good tools to be able to debug issues that might arise from tile management.

What I was building was a web-based visualizer called Timestream Mondrian[1] to visualize the tile structure for development and production-scale Timestream tables.

Figure 1 A simplified diagram of the structure of Mondrian

By the time I finished, Timestream Mondrian helped the development team answer questions like:

1. How many tiles constitute this table?
2. How are the tiles arranged? (Mondrian can display tens of thousands of them at a time)
3. How large are they temporally and spatially?
4. How densely packed are they? (This is a surprisingly useful feature)
5. How much data do they have? What queries are touching them? How often?

It was a bit of an ambitious project to finish in 12 weeks, so I was eager to get started! The first couple weeks was tough though, as most of my time was spent reading and tinkering to understand Amazon’s stack and tools. I should add, though, that my team was very supportive whenever I reached out to them for help. I made the choice to do most of this learning alone (which did provide me with some good depth), but in retrospect asking my team for pointers more often would have saved me some time. Remember that. There was also some time spent researching non-internal development tools and libraries as I made my design document for Mondrian and eventually defended it amongst the team. That was a great experience.

Admittedly, there was also a good chunk of time spent enjoying, exploring and biking the beautiful city of Seattle!

Finally, the ticking stopped and we reached the top of the first hill of the Twister. A strange silence filled the air; “The hardest part is over; now the fun begins!” One more tick erupts, and the cart starts zooming down.

Around the third or so week, I got the ball rolling. I started making the first React pages, AWS Lambdas and HTTP Gateways, and started programming the initial visualizer in D3. It was a blast! I was able to have demos with new features every week, I was able to engage with the team and get their feedback, and I was able to report news during the daily sync-ups. I came to the offices (they are really beautiful by the way) and met my team members and manager. This was my honeymoon period of the internship, and it was during this time I really got to appreciate my team. They continued to be super supportive whenever I had questions, and they were surprisingly fun. These people were exceptionally fluent in their field, veterans of 30+ years sometimes, but at meetings they would still make (sometimes contrived) jokes, bring snacks, and have a good time while also being good at their job. It was a joy to see this.

Over the next month my project was being fleshed out, but with the end of my internship looming in the next 6 or so weeks, I switched gears. I had to start moving Mondrian from the MVP stage to something that’s ready to be used and maintained when I’m gone.

Vroom! Swiiisssh! Rummm! Dummmm! “Woooohooooo!” Andy exclaimed. This ride was a blast; a great symphony of tuns, loops, tunnels and dives. But over the horizon another hill looms. This one isn’t as scary, and Andy might even have fun as the cart climbs this one.

These several weeks had a very different feel than before. As I was already getting Mondrian ready for hosting and handoff, I really started to feel that I was developing for a team and not myself. I started researching hosting tools from the lens of how it would be for others to maintain, I started making design decisions on the webapp and hosting based on security and what other team members are already familiar with. The team was super informative and helpful in this process. I also had to get Mondrian ready for much larger datasets, which required completely rewriting it from D3 to THREE.js. This also involved some fun and clever backend changes to deal with tables of arbitrary size (like over ten times the sizes I used for testing). I started documenting Mondrian more as well (especially during the last two weeks); I documented the tools used and why they were used, and also the features that should be added next. This was a pretty heads-down period for me, but it was where I was probably having the most growth.

The cornerstone of this period is when I was able to give a one-hour explainer presentation on how Mondrian works to the team. This happened at the beginning of the penultimate week. It was really fun for everyone; I was able to show the team how graphics and WebGL works, and how Mondrian makes use of WebGL to scale to large datasets. I was also able to go into the tricks I used to handle a few gotchas of Timestream data, and how the backend also minimizes reads from Timestream servers for visualization.

Around the time of the presentation, things were winding down. I had done most of the hard work, all that was left was polish, final security changes, putting Mondrian up on Timestream’s cellular hosts, and handoff.

We had reached the top of the hill, and everyone was expecting another fast descent. Rather, the Amazon Twister had a surprise for us. It completed the last stretch slowly, giving us time to savor the last few moments of the ride in serenity.

The last two weeks felt very rewarding; I could see the culmination of all my work in a project that the team loved and a project I was genuinely proud of. As I was having my last series of security meetings to get Mondrian hosted on Timestream’s cells, writing my last documentation pages and wiki page, and listening to my manager tell me about what people were already thinking of for the future of Mondrian, I thought to myself “Wow.” My work was going to leave a mark.

The ride came to a soft halt in the same spot it has started just moments before. Just like that, the Amazon Twister was over as quickly as it started.

Mondrian was a very fun project to build. Apart from making something that my team members appreciated, I also got better at React hooks, learned to use THREE.js and D3js (finally got to use my 3D graphics knowledge in a non-game project!), and also learnt about AWS services like Lambda, S3, DynamoDB, Timestream, CloudWatch, IAM, Kinesis, API Gateway, CloudFormation and CDK. Coming from a Google Cloud background, it was interesting to see how AWS handles things differently and how complicated industry backends can get.

I enjoyed being able to document, explain, design, and defend my project amongst other engineers. The process of making and updating my design doc, and going through code-reviews and feedback iterations was a mix of frustration and enjoyment – it was clear I was working in a team for a team, rather than alone.

My team was very fun, very supportive and very knowledgeable; they were a great compliment to the cool interns I met and the amazing city of Seattle.

The riders disembark, exhausted but satisfied. As they all leave in different directions, Andy looks back at the slumbering cart, wondering who will take his seat next time it awakens.

[1] (can you guess why?).

Cover Image Credit: Meg Boulden

The post All aboard the Amazon Twister! <br /> <span style='color:#787878 ; font-size:16px;'><i>My experience at Amazon</i></span> appeared first on Loading Developer.

One of the things I did over the past few months was teach myself machine learning. I did this without a MOOC (massive open online course), like Coursera or edX, and without a book. I used only the magic of a few YouTube videos, several blog posts, GitHub, and hands-on experimentation.

It has been a rewarding experience, though in retrospect, some things could have been done better. Here I share some advice for those who choose to take this path, as well as some things they should expect to encounter. I’ll also help you decide whether or not this path is for you.

Indeed, the world of ML (machine learning) is very powerful and complex, but like most computer science fields, there’s always room for beginners.

It’s easy to think of ML as something too complex to teach yourself—after all, it is a type of artificial intelligence. But this is far from the case. It takes a little grit to get through it all, but it is definitely doable. Let’s get to it!

What Exactly Is Machine Learning?

Machine learning can look mystical if you only look at what it has been used to create. Although it is incredibly useful, the underlying concept behind ML is simple.

Machine learning involves training computers to recognize patterns and make meaning from them. We apply many different techniques to do this, but in the end, the magic comes from brute force: the computer simply looks at thousands of data samples and makes small adjustments to its understanding over time. Given enough time, its understanding of the world can become accurate enough to be useful.

ML is all really just math and brute force.

Paralyzed by Choice

The world of ML is not unlike the world of programming. They’re both comparable to a field full of deep burrows. Enter one burrow and you can just keep on going deeper and deeper.

If you want to enter another burrow, you have to leave your current one and start afresh in the new one. Sure, some of the things you’ve learnt in the old burrow could be of use in the new one, but there’s also so much in this new burrow, too!

In “vanilla” programming, these burrows are areas like game development, mobile development, front-end web development, and server-side development. In machine learning, these burrows are ML branches like reinforcement learning, regression, computer vision, unsupervised learning, and more.

If you’re like me, this large amount of choice can be paralyzing because each field has a lot of depth and potential. Learning takes time, and time is precious. How do you choose which one to invest your precious time in?

Of course, it really depends on you. Just like your choice of programming burrow, your choice of ML burrow is personal. Look into them and their applications, and make your choice.

But if you want to play it safe, I suggest choosing an ML field that applies to your current field. For example, reinforcement learning is useful in games, computer vision can be useful in mobile applications and cloud services, and regression is useful for data-centric fields.

Whatever your choice, I advise you not to spend too much time trying to decide what to learn instead of actually learning. If it sounds interesting, try it out. You can always leave your current ML field if you don’t like it—and you would have learned something potentially useful by the time you leave anyway.

There is a definite danger of choice paralysis here. It can be ever-present—even if you’ve chosen a field, you now have to choose what to do inside that field.

Of course, think before you choose, but eventually, just pick something and learn.

The Learning Process

The process that I used for teaching myself machine learning was actually dead simple. I started with a few YouTube videos (I recommend 3Blue1Brown’s series on neural networks, an important introductory ML concept) to get the underlying concepts down. ML seemed doable and fun, so I looked into the different types of machine learning.

After a bit of looking around, reinforcement learning caught my eye. There were a few reasons for this, some of which may also prove helpful to you:

1.   The uses: As I mentioned before, the applications of an ML field can be a large factor that influences your choice. I’m a game developer, so reinforcement learning definitely looked intriguing and exciting to me.

1.   The frameworks: In an ideal world, the tools made available to you shouldn’t shape what path of ML you choose. But alas, they do. A lot of the frameworks for other fields of machine learning weren’t attractive to me. I was trying to find a framework that had a relatively large and active community, looked user- and beginner-friendly, and used a language I was comfortable with (this constraint was specific to me, but it’s also not a bad idea to learn another language, too). Look into the frameworks and tools available when making your choice—they’ll be what you’ll be spending several hours with in the future.

After making my choice, I went ahead and learned how to use Unity’s machine learning module through their GitHub documentation and started looking into things I could try and experiment with.

One thing you should know is that many machine learning frameworks have fantastic tutorials. Provided that you have a bit of background information, they can definitely be enough to get your feet off the ground and into some meaningful experiments. If you supplement these tutorials with occasional Google searches for things that you don’t completely understand, you should be perfectly fine.

Some frameworks also have tons of sample code to help you break the ice. Most good frameworks should have these—they’re really helpful and can teach you some interesting things as well.

I used the exact same process to teach myself deep learning for computer vision (training computers to recognize images). The process is effortful and self-driven, but it surely works. However, like any process, it has its drawbacks.

The Three Main Problems

1. The Math

To put it frankly, the math behind ML can be terrifying. Machine learning involves a lot of advanced probability, calculus, and other dark mathematical voodoos. If you don’t have that mathematical knowledge, a lot of the math that appears in blog posts and discussion boards will look like complete gibberish.

This can be very intimidating, because even when you’re looking for an answer to a seemingly simple question, you could find answers with confusing math/mathematical terms. This can be especially confusing for someone who doesn’t have an undergraduate education in probability and calculus.

It’s important to not let this intimidate you. There are two reasons for this:

Firstly, most of this math is completely nonessential. Anything that ML resource writers explain using math can also be explained in plain English, and many of the mathematical explanations they provide are simply there to prove things already mentioned or to be mentioned.

Granted, some websites and posts expect you to understand the math and hence don’t explain it in layman’s terms, but plenty of other resources only treat the math as a supplement. Given that you have the tenacity to look for enough resources and the realization that it’s OK to only glance over the math with only the faintest idea of what’s going on, you should be relatively fine.

Secondly, some of this math looks more complex than it really is, because math has the tendency to look difficult. Let’s look at a trivial example from ML:

Take a second to look at that formula. Youmay not fully understand this, but you can see that there’s a summation of products, an addition of another unrelated value, and a function being operated on the resultant output.

Now, let me reveal to you the actual meaning of this equation, step by step:

• In ML, neural networks are data structures that contain layers of nodes. Let’s consider two consecutive layers: layer j and layer k.
• Both of these layers have y number of nodes, and each node is donated by LLPL, where LL stands for the letter of the node’s layer, and PL stands for its position in that layer.
• Each node in layer k is going to want to know the value (denoted by A) of all the nodes in the previous layer, layer j.
• When it is retrieving the value of each node, it is going to multiply it by something called a weight, denoted by w.
• It’s going to add all these products and then add a number called a bias (denoted by b) at the end.
• Then, finally, it will limit the result of this summation to a specified range using a function (denoted byθ()) and store it.

See? It looks hard to grasp, but if you had the right background information, and you saw this somewhere, it would make sense. There are other equations derived from this, and if you understand this one, others will simply make sense too.

As you learn more, your background information will generally increase, and a few more equations will begin to make more sense.

The point is, you should take the time to try and understand some of the math before you outright dismiss it—some of it will be understandable.

2. The Cliff

ML has what I call a cliff learning curve. The beginning is easy to understand and follow, but once you decide to dig a little deeper, all manner of things suddenly have significance, such as hyperparameters, learning rates, and regularization. All these things must be learned and require their own time to understand and master.

You may find yourself using some things in ML that you don’t completely understand because you don’t want to invest the time to fully understand them. That is completely fine—sometimes it’s just a bonus to understand certain things.

The cliff isn’t only present in the learning process but in the resources you find over the internet. It’s not uncommon to see a sudden jump in the complexity of the posts you find as you try to learn more and find answers to deeper questions. Honestly, this is can be hard to mitigate, but it’s also not too much of a challenge.

Of course, looking for more posts on websites such as Quora or Medium and using websites like Reddit and Data Science Stack Exchange definitely helps. But you can also benefit from trying to contact other data scientists. Some ML communities use places like Gitter to communicate. Don’t be shy! They can be really helpful.

It should be noted that these jumps usually exist because at some point, the ML community expects for you to have taken a formal class or MOOC on the topic or to have read an ML book. But this post is about learning ML without those, so we’ll have to manage.

3. The Reading

This is only a minor problem, really. One thing about being a self-taught programmer is that you often don’t find yourself having to read much. You might read some detailed documentation or posts every once in a while, but a lot of the learning is from videos, forums, Stack Overflow pages, and quick and short tutorials with self-explanatory code snippets. Hence, a form of reading laziness can develop over time.

ML isn’t like this. ML can require quite a bit of reading and patience—it’s not like other things where you can quickly Google something, get the gist of the information, and simply extrapolate the rest of the way. If you’re like me and are often too lazy to read a lot to understand something, be ready to shake that laziness off. Read.

As a side note, consider reading a few research papers (like the ones on arXiv.org) every once in a while in the ML field you choose. Some interesting things can come up.

The Benefit: Project-Based Learning

Though teaching yourself machine learning can have its challenges, it has two large benefits: freedom to explore (which is almost always fun) and project-based learning.

I truly believe that project-based learning is one of the best ways to learn programming. It gives you a perfect blend of theoretical and street knowledge and allows you to create beautiful things in the process. My method of learning ML somewhat depends on it. Having a project gives you a clear focus on the things you need to learn.

The internet is a deep sea, and if you simply dive in, you can easily get lost, overwhelmed, and confused. If you have a project, it’s immediately easier to filter out so much of the noise because you have a better idea of what you need and what you don’t.

Your project also acts as a source of encouragement. When things go awry, you can just look ahead and picture what you’re trying to do, and you can gain a new breath of energy. And by the time you’ve finished those introductory projects, you will have a good foundation in ML to decide what to do next with it or just to drop it for something else.

This Is Not a Substitute

Before I end, I’d like to mention something rather important: Please don’t use this method alone if you want to learn machine learning seriously.

ML is very different from some other computer science fields. It’ll be very hard to get anywhere significant enough for a professional environment if you don’t read a book and/or take a formal course. This type of self-teaching has some benefits, for sure, but after a certain limit, the benefits it provides are no longer worth the effort it demands.

If you only want to test the waters of ML, or only want to know ML for a specific project, go ahead and use only this method. Otherwise, do this type of self-tutorage in conjunction with a book or MOOC, or use this method alone for a while, and then transition to something heavier.

An Adventure Waiting for You

Machine learning was indeed an adventure for me, especially because I chose to create my own path. Whatever path you choose, you should try machine learning for yourself.

Remember:

• Avoid being paralyzed by the options in ML. You can always choose another field if you find out you don’t like your current one. Consider the applications and available tools in your choosing process.
• Don’t be intimidated by the math. You can do without a lot of it, and some of it looks harder than it really is.
• Get ready for the cliff difficulty curve—but remember that frameworks themselves provide great tutorials and sample code.
• Don’t be afraid of reading.
• Self-teach with projects in mind. Projects are amazing—they give you focus and encouragement.
• If you want to take ML very seriously, eventually read a book on ML, take a MOOC, or both.

There’s a massive amount of potential in machine learning. It has both the breadth and depth to have a place for almost any type of programmer. As developers and creators, we should never stop learning and experimenting. Machine learning is a chance to keep this philosophy alive for you, and you could potentially find something you’ll use for many years to come.

Since I’m also a writer for SimpleProgrammer.com, this post wast first published there.

Cover image credit: Alex Knight

The post Teaching Yourself Machine Learning Without a MOOC or a Book appeared first on Loading Developer.

Even as a game developer, I don’t often get the opportunity to play games. I mean, I’d love to if I had more time, but I don’t.

And that’s not necessarily an uncommon thing among game developers; we’re generally busy people. We have to deal with work or school, other hobbies, sleep, general life errands, and the list goes on. And when the list gets longer, playing games is usually pushed lower and lower down the priority ladder.

So it’s not surprising when some game developers like me don’t get to play games that often.

But should playing games ourselves be something we feel obligated to do in the first place?

I’m going to answer this question from the perspective of game design first (where the answer is a definite yes), then the game developer side (where the answer gets a bit more complicated).

What Is a Gamer?

This is just something I want to clear up before I write anything else. The truth is, the word “gamer” is an awfully vague term.

“Gamer” literally just means anyone who plays games of any type at any frequency. However, some people understand the word “gamer” to mean someone who lives and breathes games, playing almost whenever they have the opportunity.

To add to the confusion, there are also distinct communities of gamers based on the type of game they play, be it Minecraft, roguelikes such as Nuclear Throne, first-person shooter games like Overwatch, or indie titles like Oxenfree and Undertale.

So, in the context of this article, who qualifies to be a gamer?

Anyone who casually plays a variety of games at least a few times a month qualifies. I’m not looking for any die-hard, health-sacrificing, all-day gamers—just someone who plays often enough (and well enough) to have meaningful game conversations.

Why am I creating this definition? Well, it’s mainly to make the point that even if a game designer or developer decided to play more games, they don’t have to increase their game time by a huge margin. If they try and go for the vague goal of “becoming a gamer,” they may end up mistakenly going for the extreme end of the definition and play an unnecessary amount.

Sheer quantity is not too important, as long as you play with insight and attention to detail.

Developer versus Designer

Another thing that needs clearing up is the difference between a game developer and a game designer. These two terms will be popping up in this article, so I don’t want anybody confusing the two.

A game developer is anyone involved in materializing the game itself—from molding graphics to programming gameplay logic to recording sound. It’s a very general term, but it all boils down to anyone who is involved in actually making the game software in a direct and literal way.

A game designer, however, is the person who designs the game creatively. They think about the game mechanics and the flow of the game. They think about how the game should feel and the underlying pillars that define the game. They think about immersion tactics and how to guide the player’s brain through the experiences they want to craft. While game development is technical, game design is creative.

Many times, game designers have experience in programming or some other aspect of game development, and often play the role of both a game developer and a game designer at the same time.

In this article, I will mostly focus on why game designers need to play games, though the benefits are valid for developers too.

How Game Designers and Developers Benefit From Playing Games

Of course, we should try to play games when we can—it can do a lot for us as designers. As it is often said, writers who want to improve have to read, and chess players who want to get stronger have to study games. As a contributor of your industry, it can be beneficial to know how others are contributing.

Here are some specific benefits designers and developers can get from playing games:

• Gives you a well of experiences

The first thing that playing games does for us is give us our own palette of experiences and lessons we can draw from when making our own games.

The more games you play, the more you can get to know what works and what doesn’t, and the more you can see what people have tried often and what people haven’t tried enough. This is a very useful well of knowledge to have access to, and can allow for more means of guidance when making your own games.

Additionally, when you play more games, you’re more likely to be able to think as a player better when making your own games. This is important, of course, because that means your games have the potential to be more player-oriented, hence providing more enjoyable experiences.

• Trains your inner critic

Playing more games also gives you the opportunity to train your designer’s eye and inner critic (if you’re a developer, it also gives you some insight into how game design works, and strengthens the designer side of you, which can be useful when working with a team). The more you play games, the more mechanics you encounter, and more importantly, the more mechanic systems you’ll encounter.

Each game has a set of mechanics (a system) that form its backbone, and the interactions between those mechanics craft the game’s overall experience for the player. Some systems work better than others, and as a game designer, it’s good to have an idea of why they fail or succeed, which mechanics and systems work, and which ones don’t.

You should also be aware of the nuances behind the execution of mechanics in games. It’s great to have an idea about how some games got around limitations in design and technology as well, because you’re almost bound to face some of them, too. The devil is in the details here, and you can get to him only through playing games and honing your inner critic.

• Provides you with more reference points

Have you ever seen or heard game designers talk? Perhaps over Discord, Reddit, YouTube, or even at Game Developers Conferences? It always astounds me how many games they know.

To game designers, game titles are like a language on their own. They can reference so many different games to help communicate feelings, mechanics, or situations that it’s mind-boggling.

But it’s also very useful. It means that if they want to be able to know more about how well a concept can go (or how poorly it can be executed), they can easily just study some of the games they know, or ask a fellow designer about the concept and study the games that come up in the conversation.

I remember when I was planning a game called Daze (still in the works!) and I joined a Discord channel of game designers. I pitched the game to them, and was bombarded with questions and game titles as they tried to understand the pillars (i.e., the underlying concepts) of my game. The amount of stuff they knew blew me away, and was immensely helpful in my conceptualization of the game.

This kind of knowledge can come from many places, such as working with other game designers for a long period of time and keeping abreast of game news and trends—even as a developer. But it also comes from playing games themselves.

• Inspires your own creativity

Needless to say, if you play games, they can definitely inspire you when making your own game. They could inspire the whole game’s concept, or just a small part of it. Either way, game development can become a lot easier if you have more sources of “Eureka!” moments.

While designing one of my mobile games, I was working on a way to allow players to switch easily between weapons without disrupting game flow. I asked some questions online for help, and got some suggestions for a circular menu. So I took inspiration from how smooth The Witcher 3’s circular spell selection menu is; it was such a perfect solution that it became one of the defining aspects of my game.

Games are creative works, and by virtue of that fact, they have a great potential to inspire each other’s creation. A lot of interesting solutions can come up when you’re inspired by other games you know.

Is Playing Games Necessary for Game Developers?

So of course, it’s more than just a good idea for game designers to play games; it’s a bit more of a must.

But what about game developers? Let’s return to my initial question: Should playing games be something we feel obligated to do in the first place?

Now, adapting for a more specific audience: Should game developers feel obligated? In other words, does it absolutely need to be done if you’re a game developer?

The truth is, not really.

One of the main reasons is because of the value of team dynamics and secondary influence—something this Gamasutra article explains beautifully.

If you’re on a team, you’re working with loads of other people who have different backgrounds and skill sets, different strengths and weaknesses. All that variety is crucial to coming up with something special in a game studio.

So, if everyone on the team spends their free time only playing games, they’d have a ton of knowledge, sure, but knowledge from only one part of the human experience. Games are designed to engineer experiences, so those experiences could be richer if they’re derived from a larger spectrum of the human experience.

Some studios look for people who (apart from being good at what they do) can bring something called secondary influence. In the context of game development, this is the act of allowing different fields of interest separate from the gaming world to influence the games one makes.

Developers who spend their time doing hobbies like hiking, snorkeling, yodeling, modeling, and so on can bring knowledge from those fields into the studio’s games in very creative ways. Different forms and angles of thinking would be present in a studio with such a diverse staff, and that’s almost always good.

Of course, they’d still have a need for people who know plenty of games and have a good understanding of game systems and concepts (because they’re game studios, after all), but that doesn’t mean they’ll turn away other types of people. As long as you’re a good animator, programmer, sound designer, or whatever, you have a chance.

But if you’re specifically a game designer, then you gotta know a lot of games. Secondary influence alone will make a pretty poor designer.

Our Answer—Games Are Good, but With a Pinch of Salt

So, to round up, should game designers be gamers? I would still say yes, because:

• It gives designers a greater breadth and depth of knowledge about mechanics and game systems, showing them what works and what doesn’t. It also shows them what could work, if tried.
• It gives designers the chance to train their inner critic.
• It allows designers to use more games as reference points when making their own games and studying game concepts.
• The games could inspire parts of their own game, making it better.

But must all game developers be gamers? No, they don’t need to be, because the power of team dynamics saves them the trouble.

Hopefully, this has been as fulfilling to read as it has been to write. I’ll write to you all next month; in the meantime, keep designing, and start playing! Steam and PlayStation have been waiting for you.

Photo Credit: Harvard Business Review, Freepik, Tayntons Solicitors, Windows Central

The post Should Game Designers and Developers Be Gamers? appeared first on Loading Developer.

Note: Even though this article was written from the perspective of game development, the main concepts of idea maturity and knowing when to cut ideas are applicable anywhere and everywhere. I originally published this article on simpleprogrammer.com.

Great minds discuss ideas; average minds discuss events; small minds discuss people.

-Eleanor Roosevelt

For us indie developers, new ideas are like gold. We strive for them and cherish them. We feel like we’re on a roll with them and in a rut without them. We feel empowered when they’re abundant and powerless when they’re scarce, and there’s a good reason for this:

Behind every good game lies a good idea. Every game that exists has a central idea behind it, and everything else around it (including other ideas and mechanics in the game) just help communicate that idea as impressively as possible.

For Mario, it’s using jumping as a means of exploration and defense; for Darkest Dungeon, it’s allowing the player to see the darker sides of the lives of explorers. To some extent, an indie developer is only as good as the ideas they have (or use—ideas don’t always have to be original) and how they implement them.

But as anyone who works in any creative field undoubtedly knows, ideas never stay static. They come and go, transform, and mutate. They never just stay there—they’re too intangible.

This means they have to be handled in a specific manner. Due to their strange nature and utmost importance, we as artists have to understand how to make the most of the ideas we get. One of the most important things about treating an idea properly is letting that idea mature.

Idea Maturity

When dealing with ideas, it can be helpful to imagine them as living beings—beings that can grow and die.

So when an idea first comes into your head, it’s young and immature. To be more technical, it’s not developed. Idea maturity has to do with how to make your ideas develop into fully fleshed out ideas that are well-thought-out and can be used. This is important in game development, because well-thought-out ideas are the backbone of fantastic gameplay ideas, mechanics, and themes.

So what is the first step to mastering idea maturity?

Making Your Ideas Tangible

Remember how I said ideas are intangible? Well, that’s the first thing you have to tackle to get fully fleshed out ideas.

You have to write down your ideas!

The reason for this is simple—your brain easily forgets the new ideas it thinks of. New ideas are formed and stored in the brain’s very short-term memory, and are often forgotten in a few hours’/minutes’ time unless you use unnecessary effort to remember them. When they stay in your head, they tend to stay immature and don’t develop (I’ll talk more about this later in the post), which isn’t very good.

Another reason to write down your ideas is that good ideas don’t often come when you’re working on your games (or whatever you want to use that idea for). Of course, you can expect some to come in the form of those “Aha!” moments during development, but a lot of ideas will also come when you’re not behind the computer.

Often, you will come up with ideas when your brain is in what is called the diffuse mode—a mode the brain enters when it isn’t intensely focusing on anything. The brain is in the diffuse mode when you’re daydreaming or dozing off, exercising or showering, or even socializing. The brain is in the diffuse mode whenever it’s not too occupied and has some good legroom to think about other things in the subconscious background.

When your brain is able to enter the diffuse mode and lets the mind roam about, it takes the time to build connections between neurons that don’t usually communicate or associate themselves with each other—and that’s what generates new ideas.

But that also means unless those ideas are written down, they’ll be forgotten as the brain goes about building more new connections.

So, whenever a new idea for a game, update, mechanic, setting, character, concept, boss enemy, theme, or whatever else comes to mind, find a way to store it! Even if it’s a mechanic or concept you can’t add to your current game, but could be interesting in another. It doesn’t matter—as long as you like it, store it!

I recommend using some sort of cloud service for storing all these ideas—I use Trello. Whenever I don’t have my iPod around, I write the idea on a piece of paper and type it into Trello when I can. At the moment, I have more than a dozen game ideas there—all ready to be tapped when needed.

Letting Ideas Stew

In game development, both in indie and AAA development (professional game-studio game development), it’s common for an idea to change while it is being integrated into a game. It’s a natural thing—you start adding something into the game and halfway into the process, you realize you could change something or remove something to make it better. This sends you on some sort of zig-zag, back-and-forth pattern where you add and fix, and then realize that something could be better, and then you add that thing only to realize that what you just added should be changed or improved, or even removed.

These kinds of realizations can come just because you’re in the development flow, and that’s good and perfectly normal. They come about because the ideas that drive a game can evolve over time, transforming the game (slightly or majorly) in the process.

However, it can be harmful to your game’s progress if it becomes very frequent and it takes you way longer to implement an idea than you scheduled. If this happens, it could be a symptom of a developer using ideas that are too underdeveloped.

Earlier on, I mentioned that new ideas come about as immature and underdeveloped. At that early stage, it’s not very prudent to take the dive and start using such ideas right away. When you first get an idea, the brain usually isn’t really finished making the idea—it’s just started. It hasn’t finished materializing the underlying concept it wanted to bring about—the idea isn’t complete yet.

So, before implementing an idea, it can be helpful to let it stew for a little while—spend a few days letting the brain finish making its idea.

There are two ways to do this:

• Letting the relaxed brain do its work

One of the ways to let ideas develop is to go into that state of brain relaxation once again, but with a bit more purpose. For example: When I want to develop an idea, I first go over all its current details and aspects (it’s best to do this by reading what you’ve written down about it), and go for a walk. While I’m walking, I allow my mind to just roam free and think about whatever it wants to. Every once in awhile, I bring my attention back to the idea I want to develop and focus on it a little. I try to think about how it will be implemented, any problems that may arise, and so on. Then, afterward, I go back into diffuse mode.

You could do this with any relaxing activity, like exercising, staring at pictures, or perhaps reading (although I haven’t tried that, actually). I just wouldn’t recommend anything like watching television; I would think it’s more of a distraction for the brain than a time for it to do quality diffuse-brain work. It’s been observed by many psychologists, such as Dr. Barbara Oakley and Dr. Terrence Sejnowski, that exercise works really well.

It’s amazing, but by doing this, you allow the brain to make the new connections with a sense of purpose. In the background, it will be processing your idea and improving it, correcting mistakes, and bringing problems and overlooked aspects of it to your attention.

• Purposeful planning

It also helps to get your brain’s focused mode into the mix. Sit yourself down with a pen and paper, and actually plan out your idea—think about it on a deeper level than you did when you initially got it. Plan it out with details. Think about the idea’s use and why people would like it, and imagine cases where it could be used. When you do this, you’ll realize flaws and errors (as well as opportunities for improvement) that your brain overlooked when it first thought of the idea. The brain won’t think about all of these the moment the idea comes about—there are too many details to process all at once.

I’d also recommend the power of sleep! While working on developing an idea, the power of sleep can be really useful. Think about the idea right before you go to sleep for the night, and the brain will occupy itself with working on it during the night. You’ll wake up the next morning and the improved idea will surface in one way or another.

Also, learn how to harness to power of daydreaming. Great minds like Thomas Edison and Salvador Dalí used the power of daydreaming to generate new ideas. When you start to doze off and daydream, you enter this surreal state where your brain exhibits exceptional and unexpected creativity, and it is a great source of ideas to tap into.

Ideas can take a while to mature. But after a few days or weeks of thinking about the idea (especially in the diffuse mode—I’d recommend spending a bit more time in that mode than in the focused mode), you’ll come out with a more developed idea. Although it’d still go through changes, the iterations would be less frequent and changes would be less erratic. Consequently, the idea would take less time to be integrated into the game, and would be a better overall addition to the game.

Letting Ideas Go

A difficult part of game development is letting go of ideas. When we have ideas, we tend to treat them as our children, so it’s hard to just let them go when retrospection or testing reveals that they aren’t working for our game.

But it’s a necessary part of game development and artistic work in general—not all ideas make it through the mill. Of course, that doesn’t mean that every faulty idea should be completely thrown away and forgotten, but it does mean we have to know when we should cut ideas from our work.

So, when an idea has shown itself to be faulty, there are two things you can do:

• You can try to be tough as nails and hammer at the idea until it works.

This, honestly, isn’t a bad approach, as long as you do it smartly. If an idea isn’t working, don’t just start bashing at it with the same way of thinking that created it. Try and go at it from different angles. Or figure out specifically what the problem is, and dissect the idea to tackle that specific problem. Ask for online help on places like Reddit.com and Discord, too—those websites are very helpful.

• You can cut the idea out and save it for later.

John Ceraci of the Harvard Business Review once stated that it’s good to think of bad ideas as just good ideas done wrong.

So, if the idea isn’t working, leave it out of the game and save it where you store all your ideas, like Trello, for later. It could come in handy for another game.

It’s important to realize that it’s sometimes necessary to drop ideas for your current project, no matter how painful it is. It’s for the good of the project; keeping ideas that aren’t working is detrimental to it. I’m speaking from experience in other fields, not from just a game development perspective. For example, being a hobbyist poster maker, I’ve realized that it’s sometimes better to just scrap concepts and start over for the better of the artwork.

This concept applies to dropping entire game ideas, too. Some games need specific skills to complete, so if you really want to make a great game for your idea, but you don’t have the skills (such as artistic skills) or money to do it, consider waiting until you’re better equipped to do so. Tackle other more doable games in the meantime. Otherwise, you may end up communicating your idea poorly, and a game that could have been amazing could end up being average. I’ve had to do this for one of my own games because I didn’t have the money to get an artist to help me with it. But I still plan to complete that game one day.

A Round-Up

Ideas are crucial for any game developer, so knowing how to manage them properly can be instrumental in creating better games. Here’s a round-up of everything I’ve talked about in this post:

• When dealing with ideas, realize that they aren’t static. They live, grow, change, and sometimes die.
• Writing down your ideas is essential!
• Good ideas don’t always come while you’re working.
• Developed ideas are always better than rushed ones. Try to develop your ideas before using them.
• It’s helpful to think of bad ideas as just good ideas done wrong.
• Learn when to let go of ideas—at least temporarily—that just aren’t working.

Lastly, if you’d like to learn more about the amazing brain and how to utilize it to its fullest, take this Coursera course. It’s a great course that reveals some of the brain’s mechanics, and it could really improve your everyday life.

The post Ideas: Letting them Mature and Letting them Go appeared first on Loading Developer.

As a gamer who grew up with GameBoys, DSs and consoles from the 2005-2013 era, I’ve had my fair share of RPGs. I’ve played in the puzzling world of Zelda: the Minish Cap, the interconnected world of Chrono Trigger and the fantasy-filled worlds of retro Final Fantasy 4, 5 and 6.

While all those games are absolutely fabulous in their own right (which is why their names have stood the tests of time), none of them were quite like Undertale. Yes, Undertale definitely is an RPG, but it is one of the most unique RPGs I’ve ever played.

1. It’s Hilarious

Undertale is an absolutely hilarious game. While other RPGs make their adventures serious life-or-death situations only sprinkled with humour, it’s clear that Undertale was meant to be comical from the get-go. After the first 30 of getting through the introductory part of the game, you’ll immediately be bombarded with hilarious characters, cleverly written scripts and player conversations, endless jokes, trolls and an overall enjoyable comical experience.

And the trolls, while few, can be real. I remember I spent 30 minutes trying to solve a puzzle for some bonus game loot, only to be so brutally trolled by the game that it made my brother burst out laughing.

The atmosphere of comedy isn’t just superficial too. It’s present in almost every NPC’s script, whether important or not, and in every piece of text that appears when you decide to interact with something in the game. Every interesting or uninteresting object in Undertale can be interacted with or examined, and 99% of the time the aspect of comedy that helps define Undertale would be present when you interact with them.

I think this really helps make Undertale a much more enjoyable experience. While the backbone of Undertale is quite serious (as I’ll explain later on), the game simply wouldn’t be as memorable if it carried the same serious tone as Final Fantasy, for example.

2. The Music is Great

Yeah, this is another thing I just want to mention. Music is actually something that most great RPGs already have down, and Undertale is no exception. The music usually helps set the mood of wherever you are perfectly and with nuanced changes in the tunes as the game progresses, the music never gets old.

Here are some samples, the first one being a remix, the second an original:

3. You’re not a hero

I believe this (and number 4) is what really sets Undertale apart. In other RPGs, you’re usually a hero trying to save the world from completely evil enemies, or a commander leading your army through the realms of darkness, or “the one” who’s been sent to the world to fulfil some age-old prophesy.

In Undertale, it’s not that grandiose; you’re simply a young child trying to get home after falling into the Underground (a realm full of sentient monsters, separated from the human world after a human-monster war). You’re thrust into this alien world, and as you explore further, you learn of the bleak life the humans have imposed onto these innocent creatures, of why the monster king wants you dead, and you’ll begin to realize that this isn’t the typical black-and-white story that most RPGs have.

As the game progresses, you’ll begin to realize that nobody in this realm is actually evil (apart from this one particular sunflower you’ll get to know, but let’s forget him for now). The monsters deserve to have you killed –   in fact, if there’s any truly “evil” person in the game, it could arguably be you, the main character.

4. It’s Reflective

The YouTube channel Extra Creditz once did a video about the lack reflection in modern video games. Nowadays, most video games put focus on the moment, without prompting the players to reflect as to what they’re doing, why they’re doing it, and whether they’re really as admirable as they think they are.

Do you ever think about the families of the rows and rows of people you kill in Uncharted or Call of Duty? Or whether it’s morally okay to massacre those sentient monsters in Final Fantasy? What about the human collateral damage you just happen to incur in a session of Hitman?

Indeed, you can often find that the death and violence that happens in many games is really unnecessary, but we don’t realize because we’re never made to reflect.

This is where Undertale shines. In Undertale, like all retro RPGs, you will always get the chance to kill things. Combat situations pop up as you walk by, and bosses force you to put your combat cap on. But you never have to kill anything. The game is perfectly playable without levelling up and without killing anything—you’ll always find ways to avoid killing and negotiate.

But if you do decide to kill things, Undertale will make you realise how much of a jerk you are. You’ll be told face-to-face by NPCs in dialogue of how you never considered mercy, how unnecessary the deaths were; you’ll even meet friends and family of monsters you killed along the way. The guilt can really stack up.

Heck, the game even breaks the fourth wall and behaves differently when you restart the game because you killed someone you wanted to spare (or if you died).

Because remember, you aren’t a hero. You’re a stranger in a land that’s been brutally wronged by your species, and you have no justification to start killing everything you see. The game makes you aware of this.

This is made even more effective by the game’s limited amount of main characters and world size. In Undertale, you aren’t going to encounter 15-10 main characters in a story that takes place in a massive open-world environment (*cough* Final Fantasy VI *cough*).

No—there are only about 5 main characters. Couple this with the small game world and intimate game experience and you begin to fall in love with the world and the characters you encounter. You appreciate the characters and monsters not as random story-drivers and EXP bags, but as actual people.

Your actions won’t only effect how the characters perceive you, and how you perceive yourself, will affect how the game ends too.

Time’s up!

I’m going to have to end here. This is a game review after all; you should spend more time playing and less time reading. But Undertale truly is an amazing game. It’s a game that will make you laugh, a game that will make your head bob to the beats, and a game that will change your perspective of others in its genre.

Please do yourself a favour and try it out.

The post My Experience in Undertale’s Underground <br /> <span style='color:#787878 ; font-size:16px;'><i>My First Game Review (No Spoilers!)</i></span> appeared first on Loading Developer.

After a little deliberation, the traveller throws his hands in the air in surrender and guesses to go right. He makes the turn, and sees a clear path ahead – no problem!

Or so he thought.

A few hours later he hears rustling in the dark. Birds start to fly and he spots a moving figure dashing from behind. He starts to panic, but can’t move – he’s paralysed by surprise. Before he knows it, the monster he’s always heard about but never cared to think of was upon him, and it was too late.

That monster, my friends, is copyright – and this is exactly how it preys on unsuspecting developers.

I remember the first time I was attacked by the copyright monster, and boy did it get me good. I was making an Android application called Daily Hero, which was meant to teach its user about Marvel and DC characters. It was a good non-commercial idea intended just to help the comic book community, and after 2 weeks of browsing I managed to create a database of 207 characters and polished it into a respectable app in another 2 weeks. I sent it off to Google to be published on the Play Store, and two days later I got a mail saying Google rejected my app because of all the copyrighted pictures of copyrighted comic book characters in my app.

I’d just been bitten by the monster, and to this day that app has never been published.

The Moral of the Story

This experience was a great way to show the power of copyright in an indie developer’s life. Indie development isn’t easy, and sometimes as a result we, especially the new developers, overlook things in the process.

But copyright is something that should never be overlooked or taken for granted; otherwise it can come back and haunt you hard.

What is it in the first place?

In actual fact, I kinda expect you to already know that copyright is (because like…who doesn’t?), but I’m going to explain it anyway. Copyright refers to the legal rights that an artist has to the work he has created. That means that, through copyright, the artist determines who gets to modify, distribute, and display their work. Technically, every artist has some extent of copyright protection on their work, but the ones that have real potency (and the ones that game developers have to watch out for) are the ones that are officially registered through the government by the artist.

Since copyright dictates that only the author(s) of a creative piece can determine who gets to distribute, display and modify their work, that means that if they catch you doing any of those activities without their permission, they can sue you for literally thousands of dollars; breaking copyright laws (called copyright infringement) is no joke.

Oh yeah, and they can also completely pull down your game until you remove their work form it or comply with the artist’s terms.

Just an expression

It should be kept in mind, however, that copyright laws don’t protect ideas or concepts – they protect only specific expressions of ideas. For example, Clash Royale is an extremely successful online mobile game made by Supercell. It’s so successful, actually, that there are tons of copies of it across Google Play. However, even though those games took the main ideas behind Clash Royale, they didn’t take any real content from it. The other developers make their own characters and sounds and themes – they have the main ideas of Clash Royale in their game (like the mechanics and game feel), but they expressed them differently.  As long as the game isn’t really similar to the original, it’s a-okay in copyright’s books.

The expression vs idea aspect of copyright is an issue that confuses many people; there’s no cold-cut line to differentiate between a work that has copied an expression, or an idea. So I’ve put some links in my references to help clear that fog up, if you fancy a little extra reading.

Its relevance to Indies

Well I mean it’s no very hard to see why this is something that’s pretty important to anyone who makes indie games. Indie game developers are often scavenger hunters, and the top things on our scavenging diet are visual and audio assets.

But note: any developer who starts using assets that aren’t theirs basically becomes like the traveller at the crossroads – if they make the wrong choice or overlook a detail, they can end up a victim of the beast of copyright, especially if they got the assets for free.

With that said, allow me to enlighten you with some important things to know about copyright!

Preparing to face the Beast

1. Things that are copyrighted don’t have to be labelled copyrighted

This is an important thing to note, and something that shocked me when I found it out. It turns out that for work published after April 30^th, 1989 (so basically 90% of all assets you’ll find), the artists don’t need to explicitly mention whether their work is copyrighted or not. It can just be copyrighted, and chances are that most of the top assets you find will have some form of copyright on them.

Actually, even if they do mention that the work is copyrighted under some specific license (not every copyright licence is the same), it’s not always made so obvious. I don’t know why, but some mischievous web designers really don’t always make it so obvious.

Take a look at the varying levels of copyright obviousness that some asset sites have:

Before you use any asset, be sure that you are allowed use it and be sure that it can be used for commercial purposes. There are tons of cool assets out there, but if they aren’t available for commercial purposes, that means you can only use them if your game has absolutely no monetization associated with it.

2. Credit isn’t really enough

In actual fact, if you ever modify, reproduce or display someone’s content without permission, but you reference to them, it doesn’t make your case any better in the eyes of the law.

It’s somewhat the same as stealing Joe’s car and putting a sign on it saying “for Joe.” You still stole it – you putting the sign on the car won’t make the police decide to leave you alone or anything.

In the same vein, attribution won’t get you acquitted for copyright infringement. Of course, artists are people too, and if they catch you using their work without permission but with attribution, they might decide to just leave you alone. But not everyone’s that nice, and the chances of this happening will shrink if you are using those assets in a paid game or project.

So it’s best to get permission (if they say you need it, but more on that later), and then add those artists to your game’s credits.

It should also be noted that for some licences, attribution isn’t optional.

3. If you modify work that’s not yours, it’s still not yours

The fact that you’ve edited some parts of a copyrighted work doesn’t magically make it yours, and it doesn’t save you from any possible trouble you could get into of you use it in a manner that the artist doesn’t approve of (like in commercial work when the asset is non-commercial). In some cases, to can actually make matters worse too – you could have infringed not only on the artist’s right to determine who gets to distribute and display the work, but to edit & modify it too.

4. If you copyright your game and it has 3^rd party assets – the game isn’t completely yours

This is also something that you should take note of if you want to slap the shining badge of copyright onto your own your own game one day. Games are essentially just amalgamations (look it up) of lots of different artistic assets stitched up with code. So if any of those assets aren’t yours, and you copyright the game, those assets still aren’t yours. The game itself is yours, and its expression is yours, but the individual parts that make up the expression aren’t necessarily yours by default. That means that the original artists can come around anytime they want and ask you to remove the content from your game, and you just have to. It probably won’t happen, but just keep in mind that the original artists still have the ultimate say in what happens with those assets (unless you buying them gives you your own set of rights or something, which can happen too, I suppose).

The copyright will prevent people from making a total copy of your game, but someone could still use your main character’s sprite (for example) if the sprite isn’t actually yours and the original artist has allowed others to use it.

Is There any Good News?

Well, there is some good news in all this hullabaloo. The truth is, if you really pay attention when you search for assets, you won’t really have to worry about all of this. Now that you know that the monster is lurking, you can have your flashlight ready.

Besides, there are tons of free assets out there, and many of them don’t even require explicit permission from the author to be used. You just look for the licence, check whether it requires credit to the author or not and whether it can be used for commercial purposes.

Just a few licences won’t permit modification actually; they’re not that common.

If you like the license and can abide by it – you’re good to go! And if you’re lucky, you’ll come across a Creative Commons licence. These licences are generally easy to understand and tell you their regulations very explicitly.

It should also be kept in mind that some franchises (albeit few) don’t enforce their copyright laws as strictly as others. Some brands, like Sonic, encourage fans to make fan games, meaning if you use a few of their sprites or songs they wouldn’t particularly mind, unless the game is monetized. But don’t rely 100% on that trust though, they’ve failed people in the past pretty badly.

And besides, as I said, such franchises are probably rare.

Now off with ya!

The time will come, and you’ll face the crossroads yourself. However, unlike your unfortunate predecessor, you’ll have a flashlight in tow. The night will still be dark and gloomy, and the beast will still be lurking, but with your little source of light, hopefully you’ll make the right choice.

References:

More on Copyright 1

More on Copyright 2

Expression vs Idea

Photo Credits: Matthew Smith and For Honor by Ubisoft

The post Copyright: the Monster Lurking in the Dark appeared first on Loading Developer.

You can take pride in knowing that you wrote the rules for how absolutely everything in that world works, and you get to transform your ideas and dreams into tangible products for people to enjoy, which make their lives somewhat better.

However, being a hobbyist developer also means that you have to be able to take responsibility for every single aspect of development. This is especially true for solo indie developers because there will be nobody to hold your hand through the process and show you where you are going wrong.

This means mistakes should be avoided at all costs. Game development takes a lot of time (albeit it’s usually worth every second!), so you definitely don’t want to unknowingly make mistakes that will end up wasting your time and making the process longer.

So without further ado, here are some mistakes that any indie developer should try to avoid when making games. These are some very important and fundamental things to remember (…or avoid… I guess), some of which I learned from my own experiences (which I have included in this post free of charge!). While you’re reading the article, if you realize that you’re guilty of one of these mistakes, don’t fret! After all, experience is the best teacher—the fact that you know these mistakes on a personal level will make them easier to spot and avoid next time you start making a game.

Side note: I’ve also added a snazzy infographic at the bottom of the page that summarizes the post. Feel free to share it!

Mistake 1: Not Having a Plan

Indie game development takes a lot of time and effort. But because you might not have the time to work on your game regularly due to having a full-time job or being a full-time student, it can be easy to sweep the whole thing under the rug and not approach your undertaking seriously. Two things can help here:

First off, you’ll have to realize that indie game development takes sacrifices. You’ll have to make time for it. Force yourself to make time for development sessions (at least three hours of intense development every few days). And you have to be consistent with it. Frequently breaking your development pattern can often lead to many days passing without any development since other things will start stealing your attention away from your game. Without consistency, you’ll start missing development sessions and accumulate a lot of lost time. Naturally, you’ll sometimes have to give up development time for other pressing issues in your life; in such cases, try and make up for that lost time later.

Dimension Dash took me two months to make, and the 2.0 update took three months. I programmed while I had important exams to prepare for and skipped some social school events because I gave myself a deadline to meet and I had to keep going (also because my school can organize some pretty lame events). And it still took months. This is definitely not to scare you—it’s to show you that it’s a commitment.

Secondly, it helps to have a plan before you start. Have a good idea of what you want the game to be like (be modest though—if it’s your first game, it should be a relatively simple one). But leave room for improvement because your idea of what the game should be like will improve once you get into the thick of development.

Give yourself a rough deadline (like, “I want to finish by April”) and go for it. Set weekly talks to keep yourself focused and to ensure that progress is steady.

And lastly, list out all the things that the game will need before it can be deemed 100% complete. The results will surprise you (they still surprise me), as the list will be longer than you’d expect. Keep in mind that it’s acceptable (and somewhat expected) if you overshoot and miss your completion deadline by at most two months.

Mistake 2: Not Testing as Early as Possible

When making a game, it’s important to remember that you aren’t making the game for yourself. This is a fundamental rule in all areas of game development, not just indie. I mean, sure, we also make games for the fun of it and the pride associated with it, but most of the time, the game we are making is for others to play. That means we have to make sure that people apart from ourselves can enjoy the game.

When beginning to develop a game, don’t worry about the visuals or aesthetics. Get the core mechanics down first and then spruce up the aesthetics just a little bit (so that people aren’t completely put off when they first see the game). After that, immediately go out and ask people about the game. Ask them about any problems they faced and what they thought about the game in general, and take every suggestion seriously.

There’s no doubt that some suggestions will just be whack (at every stage of development, people will always bring us whack suggestions), but there’s a reason that person is suggesting that feature, no matter how lame it is. If the suggestion is bad, just look at why it was posed. Was it to make the game more engaging? Easier? Funnier? Scarier?

It should be noted that if you’re making a game that relies heavily on aesthetics to communicate and function (no problem with that), you’ll need to take aesthetics more seriously before the first testing session.

Once you’ve gotten your first testing exercise down, you’ll know how to integrate your initial direction for the game with what people actually want, and you can make a game that people are more likely to actually want to play.

And don’t forget to test your game frequently. Every time a new major element is added that works, perfect it and then send it out for testing. Not only does it help you gauge how much people will like this feature, but it also helps you discover bugs in your game that come about when players play the game differently from how you usually play. Heck, I even remember when one of my testers for Dimension Dash found a bug that allowed players to fly simply because when he played he jumped off platforms earlier than I did.

And don’t “test” it by just playing it yourself. One of the golden rules of game development is that the game developer is the worst tester. He’s played the game literally hundreds of times along the course of development, so he is inadvertently mastering the game. He knows all the gameplay values and how the game works to a T because he made that game’s world himself. It’s not intentional, but the game developer disqualifies himself as a legitimate tester since he has no learning curve with his game and can’t play the game as a new player would.

Mistake 3: Adding New Features on a Whim

“A good artist knows how to show restraint” — Marko Vale

As I’ve explained during the discussion of the first two mistakes, your game and the vision you have for it will evolve as you develop it. So that brings me to the issue of dealing with this evolution.

Whether they’re from tester suggestions or inspiration during development, new features will come into your mind for your game. Before you consider adding them, think them through properly to see if they’re necessary and good for the game.

Lemme say this straight: you shouldn’t try to add everything you want to your game all at once. This is the unfortunate truth. You have to stay on track and follow your schedule. You can deviate and go off track a bit to add smaller features, sure, but for larger undertakings, you have to consider more carefully.

Let me give a short, real story to illustrate this: when I was making Dimension Dash, I went to my friend for a routine testing run. He said it was “alright,” and passed a comment that it could use some sort of boss level.

At first, I was taken aback, but then I realized it was a great idea. I was reluctant to add it, but realized that if I forced myself, I could still meet my deadline (maybe a few weeks late). Did I make it? Yes.

But I could’ve waited, too. If the new feature you want to add will cause too much of a delay, finish the game first and add that feature as part of an update.

Once you launch the game, you’ll understand how the market likes it and can improve on it through that same update. Also, you could decide to work on other projects/games before you start development on the update, which would help diversify your portfolio instead of being bogged down by just one game.

Mistake 4: Not Looking Forward to Challenges

If you are an indie developer, you will inevitably face challenges. One day you will face issues with data persistence, or editing third-party assets, or creating a whole complex custom character creation system for your game, or whatever the game decides to throw at you.

You have to be excited when you face these problems!

Initially, that’s not an easy thing to do: some of the problems you’ll face can be real headaches. The idea of facing new problems can be daunting too, since it means that something new has to be learned and the path to the solution won’t necessarily be a straight one.

I used to have that same mindset when it came to new challenges; they would scare or discourage me. Then I realized that facing new uncomfortable problems is instrumental to becoming a better and more resilient programmer. Uncomfortable situations are precisely the situations that make people grow, and that couldn’t be more true for programmers. We’re problem solvers, after all, so we have to be able to solve more diverse and difficult problems if we ever want to be considered good.

Embrace new problems whenever you face them—take them as opportunities to get better because that’s precisely what they are. If you’re making a game and you aren’t facing at least a few problems, then you may have chosen something too easy for yourself. Give yourself the challenge of making that game bigger and better.

Don’t be afraid to use Google or Stackoverflow.com—those two resources are extraordinarily useful for finding solutions.

Signing Off for Now!

This post is getting long, so I’ll end it here. The things I’ve written about are very important to becoming a successful game developer, so please take them seriously (no pressure there)! And feel free to share this advice with anyone else who’s into game development. Here’s a quick round-up of everything I’ve brought up:

• Always have a plan and rough deadline before starting a new game. Be consistent with development sessions.
• Give your game to people to test as early as possible, and let others play it whenever you make major additions to the game. Frequent testing is important.
• Show restraint when adding new impromptu features and remember that you can always just update your game later.
• Be excited whenever you face new challenges—you’re gonna be a better programmer by the time you solve them.

And as a last piece of advice—make use of Reddit when making games, especially the IndieDev and Gamedev subreddits. Those guys are extremely helpful in evaluating your games and helping you think of creative solutions.

Photo credit: Unsplash

Note: even though this is my article, it was posted first on Simple Programmer – a great and respected programming blog. Give it a look!

The post Fundamental Mistakes that Every Indie Developer should Avoid appeared first on Loading Developer.

I also mentioned that making a value type variable null would affect the data it was storing directly, while making a reference type null would only make that variable stop pointing to the section of memory it was originally associated with, but it wouldn’t affect that data itself.

I also explained the concept with this diagram:

The Devil in the Details

If you were really paying attention to my first article, you might have noticed that throughout the whole masterpiece (just havin’ a little fun here) I never really mentioned the memory structures that actually formed the foundation behind value and reference types. I always said that value types and references are stored “in memory” while the stuff that reference types point to are stored “somewhere else.” Did you ever wonder where they were actually stored?

The Culprits

So in C#, there are two memory structures behind data storage during execution of threads. The first is called the stack and the second is called the heap.

 It can be pretty difficult to explain the stack and heap properly if start by explaining them separately, so I’ll have to explain them simultaneously for a little bit first.

A very beneficial way to understand the difference between the stack and the heap would be understanding scope. We all know that some variables are limited in scope to the methods in which they were created (local variables) while other variables are somewhat global variables to the class in which they were made (they can be accessed anywhere within the class and have a universal scope). These variables are called instance variables.

It’s useful to associate the heap with that universal scope property. Variables that can be accessed at any time within their parent class or struct, or externally by other classes or structs are variables stored in the heap. The heap has no dimension of scope to limit the accessibility of the variables it keeps.  Access modifiers like public and private may limit their accessibility form external objects, but the variables still have a global scope in their parents and hence are still stored in the heap. Static variables are also stored in the heap too—I’m sure you can understand why.

Local variables, however, are stored in the stack. Any variable or struct called within a method is stored in the stack. Why? You can tell because of its limited scope. Nothing outside that method can access those variables, because those variables only exist in that method’s little world. Once that method is terminated, all those variables are destroyed.

This principle holds true for reference type variables too.

For reference type variables, the information they point to is always stored in the heap. The references themselves though, can either be stored in the stack or the heap. The variable can be stored in the stack if it’s a local variable, or stored in the heap if it’s an instance or static variable.

The Nature of the Stack

So we’ve established that in the following code:

class exampleClass
{
    char a;
    int b;
    
    void aMethod()
    {
        int c;
    }
}

…variables a and b would be stored in the heap while variable c would be stored in the stack.

But what exactly is the stack?

The stack is the memory structure that threads use for execution. Every operating thread has its own stack. However, a program is only allocated one heap, a heap that each thread would have access to and shares with other threads. So do illustrate this, presume a programmer has a program with 4 independent threads working simultaneously. It’d look a little like this:

So where does the dimension of scope come into stacks?

From this diagram I think you can already see why different threads can’t access the local variables of other threads. There’s simply no link between the two. They only have a link to the heap, and that’s it.

But say you had a thread that was operating a method, and within that method another method is called. No variables within the parent method are accessible to the child method unless they are explicitly made available as parameters. Why?

To understand this, think of stack memory as a very busy accountant. All day he works away at this stack of paperwork he has on his desk. Now imagine he’s in the middle of working on a stack of paperwork called methodA. While he’s in the middle of working on that stack, his boss shows up and slams a fresh new stack called methodB right on top of the stack that this poor accountant wasn’t even finished working on. He now has to finish working on methodB before he can continue work on methodA. Any information he wants from methodA is blocked by the method (since methodA is underneath methodB).

This is why scope exists. It’s because of this top-to-bottom nature of the stack. As many other programmers would term it, stack is LIFO (last in, first out). Each method has a block where its data is stored, and they are layered on top of each other in a manner in which new blocks fall on top of older ones and blocks them out.

The Heap

The heap however, doesn’t have this order of organization. It’s just a disorganized hodgepodge repository of data. There’s no restriction that new data puts on the accessibility of older data. That’s why at any point, data from the heap is accessible and the scope is somewhat universal. Every stack has access to the heap and there’s no blockage of data.

Time to clean up

An interesting concept comes into existence due to this disorganized nature of the heap.

Have you ever heard the term garbage collection before? It’s a term used all the time over sites like StackOverflow.com.

Garbage collection actually has to do with heap data.

You see, in the stack, data is destroyed when the memory block currently being operated on is terminated. Upon termination, the block and all its associated variables are deleted.

But something like that can’t happen in the heap. There’s little organization in the heap, so the computer doesn’t really know for sure when to delete data from it.

So computers that run languages like C# have something called the garbage collector. What the garbage collector does is periodically search the heap for data that no longer has variables or references pointing to it. Such data is permanently inaccessible to any program and is, in a sense, just lost in heap; so the garbage collector goes ahead and deletes it.

Signing off!

Phew! That wasn’t an easy post!

This thing took my over 5 different articles and StackOverflow pages (plus a video) to understand. Interestingly, none of them explained it in terms of scope, yet I find that by far the easiest way to conceptualize this.

But the video I watched was pretty cool too, so here it is as a bonus:

https://www.youtube.com/watch?v=_8-ht2AKyH4

So I suppose that’s it! I hope you’ve taken something new from this as I have.

See you next fortnight.

Image credit: Freepik.com among others

The post Heaps and Stacks in C# <br /> <span style='color:#787878 ; font-size:16px;'><i>The two memory structures behind code execution</i></span> appeared first on Loading Developer.