Obscure Games https://www.obscuregames.com Games With Heart Wed, 12 Aug 2020 13:23:05 +0000 en-US hourly 1 https://wordpress.org/?v=5.5.2 https://www.obscuregames.com/wp-content/uploads/2020/07/cropped-61441367_1030948680627982_4484256971570020352_n-32x32.png Obscure Games https://www.obscuregames.com 32 32 Quick tips before you get started on your first game https://www.obscuregames.com/quick-tips-before-you-get-started-on-your-first-game/ Fri, 10 Jul 2020 10:39:43 +0000 https://www.obscuregames.com/?p=6693 “I love games and I want to make them for a living, but I don’t know where to start. How can I become a game developer?”

I’ve been asked the above question (or a variant of it) several times. So after replying to a bunch of them, I decided to write a small blog post on the subject.


Below are lessons I learned the hard way making games as an indie developer:

  1. Get started: The gaming industry is very diverse with a lot of genres, platforms, business models (etc…), and it’s easy to get overwhelmed. Don’t worry about not knowing all the answers. Pick a project that you think you can complete (it can even be a clone) and dive into it. If you make mistakes along the way then start over. Your priority right now is to learn as much as you can about game development, and the best way to grow is by learning from your mistakes.
  2. Start small & ship: Once you decide on a concept, make it smaller, make it even smaller, make it EVEN smaller, and then ship it. One shipped average game is worth more than ten amazing games that never see the light of day. To be clear, I am not advocating releasing bad games and shovelware (see point #9). But actually completing projects and covering the whole development cycle from A to Z.
  3. Keep your special project for later: You might have that special game brewing in your head that you always wanted to make. Don’t work on that project until you ship a few games and gain more experience.
  4. Attend game jams and other meet-ups:  Global Game Jam is an international event that is also a great place to network with other developers and designers. Go outside your confront zone and be part of the global gaming community. Trust me, it’s worth it.
  5. Don’t quit your day job: I advise you not to quit your day job if you are just starting out. Chances that you won’t earn a lot of revenues from the first few titles you release. Once you feel ready to commit and the risks are well calculated and taken into account, then take a deep breath and take the plunge.
  6. Learn the ins and outs of the gaming industry: Follow the news, listen to podcasts, read blogs, know the major players (etc…). You are not working in a vacuum so understand the market well.
  7. Pay attention to game design: Gameplay comes first. It doesn’t matter if you use the latest cutting-edge technology or have the prettiest art style. If your game is not fun then no one will care enough to play it. Learn about game design (I recommend reading “The Art of Game Design: A book of lenses“), get versed on UX, and play games and try to analyze what makes them tick.
  8. Find a couple of peers: There will be times that you will be so burned out from crunching (especially if you are doing this as a side job), that you just want to quit. Working with a team helps you stay motivated and focused on your goal. Not to mention that the more you are exposed to people from different disciplines (art, design, production, marketing, etc…), the broader your vision will be.
  9. Don’t be afraid to kill projects/features: Sometimes a concept is good and worth investing in and sometimes it’s not. Don’t get too attached to any mechanic or project and know when to sunset.
  10. Keep iterating: Game development is all about iteration and balancing. Heads up that a good chunk of your development time will be playtesting and talking to players to find the “fun”.

Games will always have a special place in my heart. Hope this post proves useful to you guys 🙂

Tips to help you manage your tasks https://www.obscuregames.com/tips-to-help-you-manage-your-tasks/ https://www.obscuregames.com/tips-to-help-you-manage-your-tasks/#comments Fri, 10 Jul 2020 10:38:27 +0000 https://www.obscuregames.com/?p=6688 Regardless of which field or position you currently occupy, time management is an important skill to have. Without properly managing your time, day to day activities will become a series of fires you need to put out, while you slowly burn out.

In this post we will list some tips that might help you better manage your daily tasks and increase your productivity:

  1. Set both short-term and long-term goals: Setting weekly/monthly goals to focus on, and yearly goals to strive for. This will help you track your achievements and progress over a period of time.
  2. Organize your tasks in one place: Organizing your tasks in one place reduces the risk of you losing track of important ones, and increases their accessibility.
  3. Prioritize: Important and urgent tasks should take precedence over unimportant or non-urgent ones.
  4. Divide complex assignments into smaller ones: It’s hard to estimate the cost of complex tasks. As a rule of thumb (and whenever possible), try to divide big tasks into 0.5-1 hour action items.
  5. Start your day with the most urgent assignments: This will give you a buffer in case unexpected mattes pop up, and will reduce the risk of you getting sidetracked with other less important affairs.
  6. Assign due-dates to assignments: Even if an assignment has no official due-date, assigning it a due-date and periodically reviewing it will ensure that it is not overlooked.
  7. Reduce context switching: The overhead of switching between tasks (especially radically different ones) can be expensive. Context switching might be necessary from time to time (for example when a critical bug is discovered in production), but it is best used as a last resort.
  8. Take notes and record your ideas: Your memory can betray you and it will get worse with time and with stress. Try not to invest too much mental energy remembering ideas, and instead take notes.
  9. Take a break every few hours: Your productivity decreases as you get tired. Think of work days as marathons and not sprints. So take a step back every once a while, make a cup of coffee, and chat with some coworkers or friends. It’s also a great way to socialize (just try not to over do it otherwise you won’t get any work done 🙂 ).
  10. Track the amount of time it takes you to complete assignments: Tasks tend to repeat themselves. It will be easier to plan out your workday if you know in advance how much effort is required for each assignment.
  11. Don’t be afraid to say no: Understand that there’s a limit on the number of assignments one can handle per day. It’s better to say no than to fail to deliver.
  12. Use your downtime wisely: If you know in advance that you will have a busy few days up ahead, then preparing for the upcoming storm might not be too bad of an idea. Another example: if you notice that you spend a lot of time in traffic or commuting, then try to use this time more efficiently by listening to podcasts and audio-books.
  13. Watch your health: It is vital that you watch your health by eating well-rounded meals, sleeping well (etc…). If you feel that your health is deteriorating or that you are constantly under stress then STOP working and take a vacation.

I hope the above tips can assist you better to manage your workday.

Always remember to stay focused, while at the same time try to be flexible towards change and embrace the uncertainty of life.

https://www.obscuregames.com/tips-to-help-you-manage-your-tasks/feed/ 2
Drunk UX https://www.obscuregames.com/drunk-ux/ Fri, 10 Jul 2020 10:36:20 +0000 https://www.obscuregames.com/?p=6683 When designing a product, it might be helpful to imagine what would happen if a drunk tried to use it. Will he be able to complete a flow without any issues? How much time will it take him?
This is important not because drunks are your main target audience (unless you are selling smart beer mugs). But because you should strive to create products that are straightforward and with great UX, that even drunks can easily use.


Below are 10 points that will help you test for UX by entering into the mindset of a drunk user:

  1. Drunks have impaired vision: Make sure your product has a clear color palette, is color-blind friendly, and all the UI elements are obvious
  2. Drunks have a poor attention span: Focus your product and avoid pages with a lot of redundant texts, images, and animations
  3. Drunks make mistakes: Use confirmation messages and make it easy for users to cancel operations, or roll back on some actions
  4. Drunks need help to perform tasks: It should be easy for users to learn your product. Always onboard your first-time users and teach them how to complete important flows
  5. Drunks behave unexpectedly: Take into account edge cases. Untested edge cases can lead to crashes and other inconsistent behavior. Which might lead to churn
  6. Drunks can be brutally honest: If your product has social elements, then make sure they’re moderated. Nothing scares new users more than a message board with a lot of negative posts or bad reviews. A well-respected brand name is worth preserving
  7. Drunks are impatient: Make sure your product’s performance is up to par. A slow loading page can really harm your UX
  8. Drunks are bad with directions: Make it easy for users to navigate your product. Eg: Add search functionality and breadcrumbs. The easier it is for users to find information in your product, the better
  9. Drunks need supervision: Leaving a drunk to his own devices is not a sound idea. Similarly, always track your users’ behaviors and understand how they use your product
  10. Drunks are not idiots: Give your users the benefit of the doubt and communicate with them important changes such as price increases or new updates

Drink responsibly 😀

WTF is SCRUM https://www.obscuregames.com/wtf-is-scrum/ Wed, 03 Jun 2020 14:44:35 +0000 https://www.obscuregames.com/?p=5928 There is a never-ending debate in Software/Product Development circles on which agile methodology is better. Some defend SCRUM to their last breath. Others vouch that Kanban is the way to go. Some claim that a mixture of both, ScrumBan, is a perfect middle ground. While a bunch of people think that all these are just fads, and in practice are just extra fluff to traditional Waterfall.

During my career, I was in charge of implementing both SCRUM and Kanban into my development teams’ workflows, for two distinct organizations. Both initiatives were a success (though very challenging at first). In my opinion, there is no right answer to the above question. It all depends on the team you are working with. The type of project. Deadlines. And honestly, as long as you have short release cycles so that you can learn fast and improve your processes, then you are on the right track.

That said, here is a short overview of SCRUM alongside some of its pros and cons that I learned from my hands-on experience:



Without going into the history of SCRUM, basically, the product development process is divided into a set of small releases, usually every 1, 2 or 3 weeks. The idea is that every release the team should deliver a shippable version of their product. I.E. a polished and usable version that you can (but do not have to) go live with, or show to stakeholders/clients/users.
This is important because the core idea of SCRUM is to get real and fast feedback about your product (eg: does it solve a real need?) and internal processes (eg: is the team’s velocity high enough to meet the deadlines), throughout your development cycle.

It sounds simple, but in practice it requires a lot of discipline from all teams involved in the process. And it works best when the organization is laid out around SCRUM teams; a matrix team made of all the necessary personnel needed to release a version end-to-end. Usually, the SCRUM team is made of a Product Owner (PO). A SCRUM Master (SM). A development team lead (DevTL). A designer (UI/UX). 2-4 developers (devs). And a software tester (QA).

There are a lot of resources online and books that teach you the nitty-gritty about SCRUM. And also check out the below video from Spotify about its Agile engineering culture.

Now that we did a short overview of SCRUM and got that out of the way. Below is what I usually do with my teams at the start of each sprint (our ”Sprint Ceremonies”):

  1. The SCRUM Master (or the PO or DevTL if there is none) initiates a Storytelling meeting with his SCRUM team
  2. In this meeting, the SM goes over the Stories (features) that are scheduled for the sprint one by one. And basically, aligns the team about the goal of the sprint. Eg: Release feature X, or reduce the number of crashes.
  3. The team takes a few hours to read the PRDs/GDDs. Add their comments. Estimate the stories (in SCRUM we use Story Points. A metric of complexity, and not actual hours. And the estimation process is called Poker Planning). And then reconvene for a follow-up meeting.
  4. In the follow up meeting the SM and PO:
    1. Answer the team’s questions and go over their feedback
    2. Resolve any inconsistencies or risks raised by the SCRUM team (for example missing UI assets. Inconsistencies in the PRD. Etc…)
    3. Sets a scope for the sprint (usually by dragging stories from the backlog to an empty sprint board), until the SCRUM team reach their full capacity.
      Note that the team’s capacity is determined after a few of sprints based on how many stories they can usually deliver.
    4. Gets the final approval from all the stakeholders (management and clients)
    5. And officially kick-off the sprint
  5. The team then do a retrospective on the previous sprint (can also be scheduled before the Storytelling meeting) to understand:
    1. What went right, and what should the team keep doing?
    2. What went wrong, and what should the team not repeat in future sprints?
    3. What should the team start doing in future sprints?
  6. The SM then sends a summary report on the retrospective. Assigns action-items to the relevant parties. And makes sure that future sprints go smoother.
  7. And with that, the sprint ceremonies are done (it usually takes a whole day). And the SCRUM Team can work uninterrupted and focused during the sprint. Their objective is to finish 100% of the stories (and by extension complete the sprint’s goal) before a code-freeze.
    Stories that are not done in the sprint will be pushed back to the backlog. However, there should not be many of them (if at all). Otherwise the estimates are inaccurate, or there’s a major issue with the process that should be identified in the retrospective .

As you can see, SCRUM can be a bit intimidating. And some teams sometimes choose to simplify it a bit, for example by skipping the Story Points and using hours to estimate their tasks. That said, it still requires a bit of a learning curve. Which brings us to its Pros and Cons.


  1. The whole team have one goal “Finish the sprint and complete the sprint’s goals”
  2. Highly focused on improving the team’s velocity. Improving the development processes. And improving the overall product.
  3. Gives a feeling of accomplishment and builds comradery. I usually go out for drinks with my team every time we close a sprint, and also let the team vote on sprint names to instill ownership.
  4. If the sprint is not closed on time, then it’s the whole team’s fault (not R&D, Product, QA, etc…). The whole team both share the successes and the failures, which enforces accountability.


  1. Breaks down if tasks keep getting added to a sprint midway through development. It’s the job of the SM, PO and DevTL to be the bodyguards of the team. And shoot down requests to do any changes during a sprint unless absolutely critical (eg: hotfixes to critical bugs).
  2. The first few sprints are a pain, and SCRUM requires a disciplined team that is committed to making the process work.
  3. Less flexible and hard to add/remove resources to a team. That means the team’s composition (size, people, etc…) should remain consistent, otherwise it will be difficult to estimate their true velocity.

And that’s it for this post. It turned out a lot longer than expected…

As mentioned in the intro, whatever methodology you end up using is meant to improve your development processes and help you ship better products faster. If you find yourself having to work harder to use SCRUM for an extended period of time, then you might need to rethink things. That said, when SCRUM works it’s very accurate and highly efficient.

Next post we will do a similar breakdown on Kanban.

Cheers 😀

Task prioritization 101: Urgent vs Important https://www.obscuregames.com/task-prioritization-101-urgent-vs-important/ Wed, 03 Jun 2020 14:41:57 +0000 https://www.obscuregames.com/?p=5924 There is no way around it, we live in an era where we are bombarded with information on a daily basis. And as one climbs up the chain of command, the more responsibility and decisions he/she has to take into account. Which this brings with it even more information to process.

Learning how to prioritize and remaining focused (especially in chaos and when the team needs you to keep your head) is a very important skill to have. And will be the difference of you having a proper work/life balance. Or working overtime and weekends and having an endless series of fires to put out.


One method that I’ve been using throughout my career to great success is “Eisenhower’s Urgent vs Important principle“. It’s fairly straight forward. Every task you have on your to-do list is categorized into:

  • Urgent / Not Urgent: Tasks that need immediate action, or there will be tangible consequences (and vice versa)
  • And Important / Not Important: Tasks that contribute to the studio’s long term vision or goals, but are not necessarily urgent and can wait (and vice versa)

Combining those categories together will result in 4 (2×2) priorities to manage:

  1. Urgent and Important are tasksthat should be handled first, for example a blocker in the production pipeline that is preventing the development team from progressing. Or a critical bug in a live game that is causing a high churn in the player-base.
  2. Followed by Urgent but not Important tasks, for example replying to a minor support ticket that is past its SLA.
  3. Then Important and not Urgent. Eg documenting your game’s systems. This task is very important (especially when multiple teams work on the same game), but can be pushed back a bit.
  4. And finally Not Important and not Urgent. Those tasks you should eliminate from your to-do list. If you have a lot of those tasks, then there is probably something wrong with your workflow and you might be spending too much time on busy work or doing unproductive chores.

Sounds simple, and it is. The difficulty with this method lies in the execution and being consistent with which task you mark as Urgent and which as Important.

When I taught this method to some of my junior team members, most of them just shoved all their tasks under Urgent, which defeats the purpose of this exercise, so try to avoid doing that. And a general advise, your tasks’ priorities should be updated regularly. As you near deadlines a task that might be marked as Important and not Urgent, will be pushed up to Important and Urgent. So make it a habit to update your to-do list at the start or end of each day. Or if that is not possible for some reason, then at least the start or end of each week.

And that’s it. Time and task management, they are awesome. 😀

Game on!

An open letter to testers and managers https://www.obscuregames.com/an-open-letter-to-testers-and-managers/ Wed, 03 Jun 2020 14:35:31 +0000 https://www.obscuregames.com/?p=5902 I was going over my old blog posts and I came across one I wrote early in my career when I was a QA (see below).

As the saying goes, “Life Is What Happens to You While You’re Busy Making Other Plans“.

Sometimes it’s easy to focus on the short term to make ends meet. And before you know it you are stuck in working in an industry you don’t care about. In a job that no longer interests you. In a low risk/low reward golden cage. When that happens remember that everyone is born for greatness, and that each is truly unique in his/her own way.

So keep learning and growing, never settle, and keep pushing yourself to the limits. And above all, find your passion. Life is too short to waste implementing someone else’s dreams/vision.

(originally posted on October 7, 2014)

During my studies and career, I was recommended by friends and coworkers to switch from Q.A. to development, citing better pay and better career paths.

As tempting as it was, in the end I stuck with what I love and what I am truly passionate about; exploiting and breaking software.

This got me thinking about the state of the testing industry, and how many talented testers switch (or get switched) to other positions. And although I am noticing more awareness about the importance of good testing teams in organisations, there are still those who view testing as an afterthought.

For all you testers and managers reading my blog, we need to have a heart to heart.


To managers

Looking through the organisational hierarchy it can be easy to lose track and see testing as grudge work, but this should not be the case. Testers (as with all other employees) invest more in an organisation the more an organisation invests in them.

As the software industry matures, the boundaries between developers and testers are getting blurred. Good developers and testers are those who can test and code (respectively).

Don’t settle for less, and always seek out and hire top-tier testers.

Keep the testing-team engaged. As a rule of thumb: if that team spends 75% (or more) of their time clicking on buttons, then you’re not going to attract a lot of talent and the testers you already attracted won’t stick for long.

Stand by the testing-team as a whole, and by each individual tester. Provide them with the optimal working conditions they need to flourish. Support them, challenge them, invest in them, and give them opportunities to grow and advance.

A good team is always greater than the sum of its parts.

To testers

Dominate your craft and to push the industry forward.

Don’t be afraid of failing. You will never know what you are capable of without pushing yourselves to the limits, and making mistakes along the way.

Be the users’ advocates. Protect them by unearthing defects, and by ensuring their points of view are not overlooked in the development cycles.

Be close to developers, product managers, designers, and whoever is involved in projects. Your job is to supply them with feedback (in the form of bugs, risks, feature requests, etc…), and enable them to be more proficient at their tasks.

Lastly, work occupies a large portion of your lives, and it’s hard to remain excited and engaged without loving what you do and the people around you. If you consider Q.A. as a stepping stone, then it might be best to invest your time into a more suitable career. However, if you are passionate about testing then never get deterred and keep doing what you do best.