Seriously... Fuck. Tunnel. Vision. & Why You Need Other Devs!

Fuck this shit.

Here, let me explain. One of the biggest recurring problems among programmers, not only programmers but those who work solo on problems with an extensive width and a breadth, is that we get tunnel fucking vision.

Perhaps Dave Chappelle puts it best. He calls it something along the lines of 'standing too close to an elephant'. When you're standing just mere inches away from an Elephant all you see is its ruggedy rubbery skin. You won't know what you're looking at. Only when you step back and put the entirety of this animal in your view you can identify that in fact it was a big ass elephant and not a close-up of Mike Tyson's dick. Without a doubt the same goes for programming.

Too many times have I been in a similar situation where I had an issue that drained several precious hours only to have a quick conversation with a fellow programmer to find out that it was some checkbox I forgot to tick or some lonely line of code which I took for granted. If you ever did some programming you know how shitty and great it feels at the same time when you solve issues such as this. You are happy because you've found the cause that squeezed the life out of you, and you feel like shit because, well... your life was squeezed out of you trying to figure out whadup. As a pragmatic man your next thought is this: "Okay. I made shit mistake. I don't want repeat this mistake ever again because it cost me a lot of time, made me feel stupid and tired me the hell out. So how do I not fall in this predicament again?"

This elephant photo belongs to Jim.

I've got the remedy. You have two options.

1. You get a rubber duck and you talk and walk him/her through the situation. Every time I tell an inexperienced developer about this they laugh at the mere idea of talking to an inanimate object... Seriously, rubber ducks are very very very helpful. When you are speaking in contrast to the act of silently thinking your brain works things out in a a whole different manner. This is an actual life-hack, yo. Use it and thank me later. We've tested this in real life situations so I can personally vouch for how good it is.
2. You keep fellow developers and friends around and always have a couple of buds you can contact when you're stuck. When you tell them your problem they will ask you the most basic stupid questions and you'll cry out to them "No, man that's not where the problem is. Let me tell you..." Well you shut your whore mouth that instant and humor your friend and walk him through that code. He doesn't need to listen to your shitty ass theories about why your code isn't working because none of that got you nowhere. He is listening and doing you a favor, walk him through and you'll hit that snag in no time where you done goofed. This works because when someone who doesn't know your code enters the game they need baby-steps instructions on how things work and most often we make mistakes on these levels. After your friends solves your problem for you, you should buy him a drink later or suck his dick I don't care.

Finally, thank you @AurinRed for helping me out solve this problem! Your box of chocolate is on its way.

Screen-flow or the types of screens, layouts and how they connect to one another in Wasco.

Before we start making background visuals and/or button art and wiring all that jazz into a functional UI we got to hold them horses. Stand back and think about the big picture. Stop doing art. Stop setting up the code-flow for your game. Just... stop.

When you're developing a game, or any project that requires UI for that matter, it helps to plan ahead. You need to think about your screen-flow or in other words how one screen leads to another and how many of these things there are and finally how all of this comes together.

This process will help you figure out some of the repeating screens and will force you to keep things simple if you want to finish your game faster and avoid frustrating your players with redundant functionalities and screens. You will end up KISSing your UI elements. (K.I.S.S stands for Keep It Simple Stupid). In the process you need to kiss 'em goodbye, the non-MVP stuff that is. (MVP stands for Minimum Viable Product).

For example, I wanted the player to be able to name their character and this requires me to come up with a layout for a character naming screen but then I realized this isn't necessarily in the MVP and decided to scrap it at an early phase. Another thing is I needed a menu that could be overlaid onto the in-game screen and realized I could use the same UI schema for the title screen which saves me time. This approach also saves the players some time as well since they don't have to learn two different types of menus

Having such a flowchart also comes in handy as something you can hand to your team mates if you have any. It will help them setup the code much faster knowing every screen there is and what navigates to what. Also for the person who needs to come up with the UI drawings it helps to see the whole picture and administer the best matching visual response. The flow-chart may change over time but it's still good to have a plan and see the big picture.

What platform will Wasco be released on and why?

This is an answer that I thought and decided on early in the development cycle. I back up the reasoning for the platform of choice by considering a couple of questions that guide me towards the answer itself. First and foremost I should add that this is a good thing to decide on before you embark on any sort of production because it helps narrow down your target audience, calculate plausible sales projections, prepare UI mockups that fit the resolutions and the aspect ratio of your game as well as a zillion other platform specific issues. If you take care of this problem early on you will save yourself a heck load of trouble.

Just to spell it out for every reader let me give a quick example here. If you're developing for PC then you can let your game handle controls through a keyboard or a game-pad. In the other hand if you are preparing your title for a mobile device then you have to think about how to integrate controls onto your screen and without disabling valuable screen space at that. You get the idea.

There are a couple of things to consider when you're deciding what platform to aim for if it isn't absolutely clear for you from the get go. I turned these into questions you can ask yourself so let's go through them:

1. Which platforms provide you with the in-game controls you want for your game?
1. For Wasco this would be NintendoDS or Nintendo Switch however PC devices do not stifle the control issue since we require a D-Pad and A-B buttons for our game. On mobile this requires an added control scheme that is superimposed over the game screen.
2. Which platform provides you the easiest access to those who want to play your game?
1. For Wasco I assume we'll get the biggest number of players on mobile devices. I will have to do a research and find out which market houses the greatest amount of old school rpg players. Until then I don't know the answer for this question so it's a guesstimation of sorts.
3. Which platforms have you had experience developing for before?
1. For Gray Lake Studios this is mobile and especially Android at that since we've released multiple applications here already. iTuens AppStore on the other hand has only one port from us. Since we haven't released on any other platform than the ones mentioned before releasing something on Nintendo Switch for the first time strikes us as a daunting task. Perhaps a port would be more fitting having proved the game is lacking in bugs after it's out on Android.
4. Which platform does the experience suit the best?
1. From one angle this would probably be NintendoDS or Nintendo Switch for Wasco. Wasco has rpg elements that resemble early Final Fantasy V, Secret of Mana and Pokemon and these sort of rpg games are associated with such platforms the most.

I've found this image here which is made with data from GDC 2017.

Now these questions are pretty generic but if you follow where they lead you you will end up asking yourself questions like the ones below:

1. Have you decided on the genre of the game? For example helping know what genre of game your title falls under will help you research what platforms provide games with such genre the most. For example Nintendo Switch may introduce more party games than PC does and since NS comes with 2 controllers it's easier for NS owners to quickly band their guests and get a quick game of Mariokart rolling. For PC you'll most likely have to hook up your laptop or PC to your TV and then consider buying gamepads to actually prepare such a setup which lowers the number of people who has such a setup already.
2. Do you know which platform you'll have the most competition on? This question may help you figure out who you're competing against and whether if you have a chance beating your competition. It can also help you notice if there's a gap in one of the platforms and if there are people thirsty for the type of game you're making.

I'm keeping this post a bit short because it's already getting out of hand and I think maybe it's better to expand on it in the future if I ever do. The TL;DR version of it is as follows: We are preparing Wasco for Android before any other platform after consideration of the aforementioned questions.

I'm back and Wasco dev continues.

Hi everyone,

I had a three month break due to various issues. I see these problems as part of the independent developer as well as the human condition. I'd like to dissect them in a future blog post. On a positive note I'm getting back to developing Wasco and will spend approximately a week updating my roadmap and catching up with other things surrounding the development.

I'll update you again once I do those things and event hough it's optimistic I'll be aiming for weekly posts again.

Tunc