The above link is an exemplar of blog as recruiting tool and company culture branding. Reading through it, we find out about a smart, self-motivated engineer who works at Riot’s Hong Kong location. What is particularly effective about this blog is the way in which the man’s day is scheduled and how it reflects both his personality and the company culture, the two things that prospective employee are going to want to understand before working at Riot.
On the train to work, he spends time doing a little extra programming OR plays some mobile games. This shows that he is both disciplined but understands how to relax in smart ways that boost his knowledge in the games space: he is a go-getter. At work by 8am, we see that his morning is not too overwhelming, he gets communication and a bit of work in before the 10am meeting, programs hard until noon at which point he goes out to eat with his friends. When he gets back, he plays LoL against his co-workers until around two, he then goes into a deep focused programming session until around 5 at which point he works on his personal growth by researching tech or playing with Unity3D for his side project. Before heading home to his WIFE, he stops by a yoga studio to meditate.
Chalking up his day, this man only programs for two intense 2-hour sessions. The rest is communication, meetings, and leisure. You can tell that every day is extraordinarily well balanced and not oppressive in the slightest, and that this man is a highly productive, top talent, major value add who loves his job and lives an ideal life. Riot is a billion dollar leader in today’s game industry and a forerunner of “zen” tech culture replacing the “crunch” video game culture of the past. Riot seeks to enrich the lives of its employees rather than oppress them, but the more important fact is that this could be a myth and perhaps there are many overworked employees at Riot. Nonetheless, the best game developers on earth are going to want to work at Riot simply because they heard the myth in the first place, a myth that is generated by word of mouth and blogs like this.
Book Recommendation: “The Power Elite” by C Wright Mills, for anyone interested in a fascinating look into the origin of neo-conservative beliefs.
I recently developed a standardized design process for my team at BrainRush because we had so much design work that it needed to start being distributed to members that were not previously ordained as “designers”.
If you do not create a Design Document before implementing a design, you will find yourself conceptualizing solutions to problems while working rather than just quickly implementing items off of an already solved list. Determining development solutions on the fly can lead to lulls in attention of “what to do next” and make for a slower development process. Of course, a Design Document does not need to be followed in extreme detail, but it certainly serves to expedite the process of implementation and keep a nice record of work progress.
At BrainRush, we follow the Design Document template below to complete a design task: a creative task that a developer must complete before implementing a substantial feature into a game. Design Documents do not work for everyone, but in order for teams to share responsibility, trust one another’s design sensibilities, and maintain transparency of intention, it is always best to have a preconceived set of solutions and tasks before programming, modeling, and developing a feature.
Design Document Requirements:
Written List of Core Design Elements
All of the core pieces of programming functionality required for a design to work from start to finish
All of the art assets that will be required for the design to be visually complete from start to finish
All of the audio assets that will be required for the design to be aurally engaging from start to finish
A paragraph about how all of the programming, art, and audio will work together in the completed state of the design.
A paragraph about major challenges or unknowns that will need to be confronted during the design process
A paragraph about the goals behind the design and what the user will ideally experience with the completed version of the design
Technical Design / Drawings / Flow Charts
A technical design for a strictly programmatic design can be
A highly detailed pseudo code word documents that outlines the functions and variables of each class
A flowchart or diagram for the flow of input data, classes and their relationship to one another, and changes of state that may occur in the application.
A level design, UI design, or 3D Art Design can be
A hand or computer drawn sketch organizing the visual elements with text description of each element
A series of images that represent the different visual states in which a design may appear and how they transition between one another
NOTE: Hand drawn/written documents are encouraged and are to be photographed and uploaded to the design document in addition to written text of sections 1 and 2
Submit the document for manager/peer review
Book Recommendation: “Drawing on the Right Side of the Brain” by Betty Edwards for anyone looking to improve their drawing and perception skills. This book provides foundational insight into how to interpret images you want to draw such that you can break them down into elements and procedures rather than feel overwhelmed by their complexity.