Catalin Avram

A buzzword when releasing a game or when trying to raise revenue to develop your casual game is “competition”. Usually when releasing a game, you might think the competition is another game of the same type. Or other games in general. But the reality is that your game will be in direct competition with Facebook, YouTube, Netflix and other content consumption service. So when you think about releasing that “match-3” type of game, you’re not only competing with another 10,000 existing titles of the same type, but you are also competing with people scrolling on the Facebook newsfeed. yayks!

 

Imagine a regular 30-something year old person, who has a job. If you think about their typical day schedule, you realize that most of the day is taken up by activities such as work, sleep, eat, talk to friends, etc.

A regular person who works 9-5, commutes 1 hour and sleeps the regular 8 hours  a day, will be left with only XX hours of entertainment a day.

Suppose the person wakes up at 7am and it’s at work from 9 until 5pm. This really means that she’ll be home around 6:30, have dinner and/or meet with friends and by the time she gets to unwind, it’s already 9pm. Suppose that our person lives a sort of healthy life and they want to be in bed by 11. This leaves them with only 2 hours for entertainment. Everybody is fighting to capture those 2 hours – Facebook, popular shows such as Walking Dead, Game of Thrones, Suites – yes – when you release a little free game, you are directly competing with Game of Thrones! Good luck with that!

So here are some things you can do as a game designer to maximize your chances that someone will play your game:

Don’t make it free!

When you make a game free, you are automatically undervaluing your work. Although it works in some cases, I am a strong advocate against free and freemium games. You can release a demo, or a video or a level, but making in-game purchases will take away from the value of the game and turn it into a casino game.

Provide quality content, puzzles and a story

Tapping the screen to keep the bird flying is not very smart. It’s not even hand-eye coordination. It’s just mindless time wasting and it’s the same type activity one does when scrolling on facebook. And guess what, someone’s facebook feed is more interesting than your flappy bird clone!

Avoid “infinite” type of games.

When you create a game that never ends you give your player a reason not to play it. The reason we have games is because we want to start something, get challenged and finish. There has to be a clear way to end the game, otherwise the player will think “ah, I can stop playing now, this never ends anyway”

Don’t release clones

Just don’t! Use your imagination and create something new, don’t re-invent something that’s already invented.

Creating a successful game is a hard task, but by following the above steps you can at least eliminate or minimize the chances that your game will directly compete with established websites.

Thanks for reading!

To begin the understanding of what a full stack developer is, let us first step back and define what the opposite is. Someone who is not a full stack developer, is then, a specialist in a particular area. The specialists are, in general, categorized based on work areas which are familiar to everybody. The categorization usually starts at “front end” and “back end”.  This is by default misleading, because even if you have a the “front end” and the “back end”, you are still missing 3 core components from the equation: database, deployment and devops.

Let’s look at the scenario from another angle. You are building a web app. A web app has the following basic criteria, which makes it a web app:

1. It’s accessed through a web browser, by going to a URL.
2. It has front end presentation – this is what the user sees – the buttons, text and input fields.
3. The user creates, retrieves, modifies or saves data, so it must need:
4. A web application server to handle the connections.
5. A database to store all the information.
6. The server needs a physical space to exist, so you deploy it to the cloud (see what I did there?).
7. It needs to run, be stable, be updated.
8. The stake holders need to understand its value.

Each of these points can be further broken up into more steps, depending on how complex the system is or how fast it needs to get developed. So here are the general skills necessary for each of the above points:

1. Web URL

This one is easy – register a domain and map it to your hosting plan. So far so good.

2. Front-end

Although self explanatory, there are a lot of details to this point. To develop a beautiful front end, you must know about UX (User Experience), UI (user interface), user flow, user stories, SEO, graphics, some basic color theory, latest trends in design, design patterns for the programming part, UI testing, A/B testing, responsiveness to mobile devices (and probably more). And for most of these points, there are hundreds of different ways to achieve the same thing. Notice how I did not mention any actual programming skills; that is because I believe the programming languages/technologies can be picked up easily, it’s the concepts that are harder to master.

3 and 4. Web Application Server

This is the other major known part of an application. The developer must know best practices for server applications. How is the communication handled? Is it secure? Is it encrypted? Is it as safe as possible from attacks? If the application supports real time messaging, how is it handled? What kind of design pattern should be used and how will the app architecture look like including load balancers, firewalls and databases? What happens if a node goes down? What happens if the connection is lost half way in a transaction? These are only some of the questions to be asked when developing the Web Application Server side of things

5. A database

This is yet another big chunk of the system. Which type of database to use? And why? When considering this, a lot of factors must be taken into account, including cost, performance, future expansions and so on. The developer must be at least familiar with the difference between relational and non-relational databases, store procedures and db locks.

6. Hosting

This is another skill our full stack developer needs to have. In very large projects, this is usually handled by a completely different team, but in today’s world, the full stack developer needs to know how to set up servers in the cloud or in house such that the application will run smoothly.

7. Deploying, Testing, Availability

Other key role in the lifecycle of an application are deployment, continous testing and availability. This require skills such as creating VMs or Doker containers, testing frameworks for continous integration and knowledge about distributed systems and availability. Another criteria which falls under this category is data consistency. I watched a speech about availability vs consistency of data, and in the speech there was an example about hotel booking systems and how in their business model availability trumps data consistency. For example, they allow the possibility of 2 people booking the same hotel room at the same time at the cost of the service being available. This is due to their business model – they’d rather overbook the hotel and deal with this at the counter (they all have a few rooms always available for these scenarios) than have you book a room in another hotel.

8. Relaying value to the stake holders

This, to me, is by far the most important skill to have. For everything I wrote above there are books. Hundreds of books, forums, stack exchange answers, Quora questions, university classes and so on. But for explaining the value to a business owner, for that there are no books. It’s all about the experience. And the only way to gather experience is by doing. And the best way to gather experience on this subject is to create, from scratch, your own social network application. This is the real “hello world” application.

So that’s what a full stack developer should do. But specialization has their own merit and it exists for a reason, so where do they [full stack developers] fit?

The most common answer is: start-ups!  This is true for multiple reasons. A full stack developer is a very good asset in a startup – given the skills above. They can pretty much create a system from scratch, get it up and running and maintain it until it takes off.

And you don’t need to be a database expert to do this (and you shouldn’t). It is pretty self explanatory that you shouldn’t use an Oracle set up for your database before you have a prototype to your product. And if the prototype can be done using a free open source db (such as MongoDB) then just do it!

There is however, another place where full stack developers will be used a lot in the future: in big corporations, especially in traditional ones such as banking and finance. More on this another time 🙂

So in other words, a full stack developer should be able to put together a social network type of site (in terms of complexity), including mockups, layout, choosing color schemes, do all the development up to a working beta, and explain to the stakeholders, in plain english, the advantages of using the technologies of choice.

I learn by reading and having conversations with people about different subjects. This is a hot topic in the tech world right now and I would like to get your opinion on this so don’t hesitate to comment!

 

When I started thinking about this subject I thought maybe it was just me, in my particular situation and work experience, who got left behind web technologies.  But after conversations with many senior developers, I concluded this is a pretty common theme among us and a problem worth tackling.

The purpose of this article is to shed some light onto web technologies from a principles point of view.  This is targeted to senior developers who have experience in more formal languages such as as3, C++, Java, Assembly(!!).  It is also targeted for CTOs, Business Managers, Project Managers and any other decision making personnel who is having a tough time with the terminology.  Since I’ve been coding mostly in ActionScript for the past years, I will use it as a reference in this article, but the general concepts apply to other programming languages as well. And although there are many technology stacks used today to create web applications, I will focus on JavaScript related ones because those are the ones I am currently learning. Of course, the concepts can be extrapolated to other technologies (such as PHP, .NET, Ruby, etc). Please be aware, this is not a technical article. You will not learn how to migrate your code from as3 to JavaScript. This is one level of abstraction higher

When someone is looking to start working on a web-app, they will quickly be bombarded with the following terminology: JavaScript, HTML, css, css3, DOM, jQuery, Ember, Angular, Angular2, React, Node, MEAN Stack, Full-Stack, MongoDB, Bootstrap, Responsive, Mobile-Ready, ES6, ES7, TypeScript, Redux, DevOps, JSON, XML, Webpack, Stringify.  Enough terminology to fill out a resume! Someone who wrote physics engines for AAA games might get completely overwhelmed by this.

But don’t be afraid, you are not alone, and it’s perfectly normal to be able to write a full blow car physics algorithm and not to have a clue how to write a “hello world” web page.  For those who started the proper way (from basic HTML to older AJAX techniques and then dived into exotic new frameworks such as AngularJS), I ask you this: Imagine learning Angular without knowing what a <div> is.  How would you feel?

The reverse is also true: imagine doing a physics engine in C++ without understanding pointers and recursion.

Before we move forward into web application structure, let’s point out one of the biggest differences: there’s no compile!

We are used to the following flow:

1. Write Code
2. Compile
3. Run
4. Debug

With web apps, you simply write code, then you refresh the webpage. The latter step being sometimes a combination of running and debugging. And depending on which technologies you use, the refreshing is also optional.  So you end up writing code and seeing the changes live.  How cool is that?

So here is a list of important key concepts which helped me jump ship from as3 to web apps:

1. You are building HTML.  Always!

This is one thing which, although it seems extremely trivial now, it wasn’t easy to grasp in the beginning.  When using ANY web technologies  your end result is HTML.  Everything you do involves creating, manipulating and styling HTML components, also called DOM nodes.

You might be somewhat familiar with <head>, <body> of an html site, but the building blocks of the layout are really divs, tables, lists, buttons and input fields.

There is a ton of documentation on the ins and outs of this, but the basic principle is this: your end result is a web page, made up of HTML tags. You simply use Javascript and other frameworks to manipulate those tags.  That’s all.

2. JavaScript is your best friend

So you are building HTML and you need something to manipulate it with – enter JavaScript.  If you come from a more traditional language such as C++, you will probably feel like puking at this thought.  But have no fear, it’s just how things work. (Why C++ developers should not be scared of JavaScript)

JavaScript is a lot more powerful than people give it credit.  JavaScript can be Procedural, Structured, Object-Oriented, Functional, Event-Driven and Interpreted. It all depends on how you use it.  Also, passing functions as arguments is an awesome way to do some really crazy things! Also, JavaScript is fast!

3. Goolge Chrome is your other best friend

One of the most difficult things to wrap your head around web application development is the dev environment.  You might be used to Eclipse, Flash Builder, Visual Studio – and all of the sudden all the examples you see are done in Notepad++ at best, no compile, and just browser refresh.

This will take some getting used to, so I highly recommend trying out different setups.  The two most common editors are Sublime Text and Webstorm.  Bonus points if you write a full stack app using vi only 🙂

I also recommend getting very familiar with Google Chrome’s developer tools, as they will provide tremendous help when developing and debugging.

4. Social Network is the new “Hello World” app.

It is widely acceptable to jump into a new programming language or technology by writing a “hello world” program.  This is not good enough anymore.  The new “hello world” should be a fully functional social network (including deployment to a cloud based service Amazon Web Services or MS Azure).  I did mine in 30 hours, so if you skip on endless Facebook scrolling, you can do too during a long weekend!

The social network should have at a minimum the following:

Stage 1:

• Landing page for sign-in or sign up
• Create/Edit profile
• Make friends

Stage 2:

• live, real time encrypted chat module

Stage 3:

• Native iPhone, Android and Windows Mobile apps.

Stage 4:

• backoffice / admin tool for the social network.
  • This tool should have the capability to see stats of the system, ban users, send mass messages, remove accounts, etc.

Although you are not expected to be a designer, the app should not look like it was put together by a developer.  There are many  styles of UI components which look very nice and could be used. If you are a developer, it doesn’t mean you can’t create good looking apps without the input of a designer.

Creating and deploying a Social Network app will make you understand all aspects of the technologies used.  And although you will not become a database guru, you will at least have an idea of what it means to persist data to a database and how to retrieve it and what technologies to use.

I always believed that great products are built by great teams, not by great skills.  Anybody has the ability to improve their technical skills and there will ALWAYS be a better solution and room for improvement.  What differentiates good products from mediocre ones is how well the team works together.  A team of average coders that get along very well will put together a much better product than a team of elite coders that don’t get along.

5. Choosing the right technologies – chose all!

One of the most daunting tasks for a CTO or software developer when starting a new project is to chose which web technology to use.  There are so many!  And so many combinations!  The best way to decide is to create a series of small pet projects and use different technologies for different ones.

For example, we can take our social network example and first build the backend in Node.js and then build the same functionality in Ruby.  This would be an excellent exercise to compare multiple technologies.  You can then dump the code in github and show to potential employers that you wrote open source software 🙂

6. Understanding the lingo

Above, I listed most of the key words which are currently hot in the web development world.  I will explain to them in simple, plain english, so that you understand how they all fit together:

JavaScript, HTML, css, css3, DOM, jQuery, Ember, Angular, Angular2, React, Node, MongoDB, MEAN Stack, Full-Stack, MongoDB, Bootstrap, Responsive, Mobile-Ready, ES6, ES7, TypeScript, Redux, DevOps, JSON, XML, Webpack, Stringif

You are building web applications.  The end result is HTML.  You use the JavaScript to manipulate the DOM (HTML) and to write your business logic.  The application can be broken down into 2 distinct areas: the UI and the logic.

The UI is how the app looks – colors, styles, fonts and animations.  These are controled by css (css3) bootstrap and jQuery.

The logic is written in JavaScript, but it can’t all be dumped in one file.  So we use frameworks.  Frameworks include: Angular/Angular2, React/Redux. Ember.

7. Bring value to the customer!

The most important lesson is by far bringing value to the customer.  This goes beyond programming and software engineering.  This is the thing that should pop in everyone’s head when thinking about a new product.  Why are we migrating from Flex to html5? or Why are so many companies re-writing their software? Because the end-user requirements change constantly.

When making the decision of which framework to use, besides the technical details or requirements, a CTO should also keep in mind the available work force for hire. At the time I’m writing this article, React / Redux is a very cool and funky new framework for developing web apps created and backed by Facebook, but it would be a pretty dumb idea to create a product using it if you expect to hire 10 more programmers next year.  The reason is you won’t have anybody to choose from!

Another value you can bring to the customer using web technologies is the long term maintainability of the code.  Since all these technologies work interchangeably with one another, it is very important to ask the following questions:

1. How easy is it to re-write part of the app in the future? (the UI, the back-end, the database)
2. Can I easily find programmers to maintain my code in 2 years from now?

 

Conclusions

I hope I shined some light on some of the questions regarding HTML5 migration and web applications in general. As you can see, switching from classic application development to web applications goes way beyond learning JavaScript and HTML. Those are just simple, implementation details which can be picked up in a few weeks by a seasoned developer. The real value is understanding well the above points, and I hope this article will open many doors to many developers which are in doubt about jumping ship to web application development.