I'm currently active and blogging on Medium, please don't hesitate to follow me there.
The Journal of a Game Developer
A game developer's journal by David Baron.
Saturday, 19 December 2020
Monday, 20 April 2020
Super Ultra Turbo
During the writing of the 2nd edition of Hands-On Game Development Patterns with Unity 2019, I'm taking into consideration all the feedback I'm receiving from readers, including the negative reviews. And so I'm structuring the content of this new edition based on the input that I'm getting.
For example, for this new edition, each of the code examples presented in the book will be sampled from a complete code-base of a fully playable prototype of a racing game. The game in question is named "Super Ultra Turbo", and you can see screenshots of a very early demo here.
The end goal of this approach is to give the reader as much context to each code example presented and showcase how we can use individual software design patterns to structure the code-base of an entire game. This strategy will hopefully make the content of the book more practical and useful to developers that are building their games in Unity.
For example, for this new edition, each of the code examples presented in the book will be sampled from a complete code-base of a fully playable prototype of a racing game. The game in question is named "Super Ultra Turbo", and you can see screenshots of a very early demo here.
The end goal of this approach is to give the reader as much context to each code example presented and showcase how we can use individual software design patterns to structure the code-base of an entire game. This strategy will hopefully make the content of the book more practical and useful to developers that are building their games in Unity.
Friday, 17 April 2020
Game Design Patterns
One issue with the first edition of "Hands-On Game Development Patterns with Unity 2019: Create engaging games by using industry-standard design patterns with C#" that readers often mention in their reviews is that the code examples presented are not "practical." This feedback is very valid, and I will be addressing it in the 2nd edition.
I want to state that I wrote the 1st edition intending to simplify the subject matter to its essential elements with the goal that my readers could use the code examples as "templates." But I admit I might have gone too far with this approach, even if some beginner developers appreciated it.
So in the 2nd edition, I will attempt to go deeper with the subject matter by mapping some "classical" software design patterns to specific game design patterns. In other words, I will make sure that every code example presented in the book will offer a solution to the implementation of a specific game system. It's a challenging approach because I must find the right balance between explaining software design patterns but showcases how to use them in very concrete examples without losing the reader with wordiness.
It's a challenge that I'm enjoying facing, in the meanwhile, I'm reading all the reviews of the 1st edition, and I appreciate them all, even the negative ones. And I hope that the 2nd edition of "Hands-On Game Development Patterns with Unity" will be useful to the Unity game development community. I promised that I'm working hard to make this edition the best one.
I want to state that I wrote the 1st edition intending to simplify the subject matter to its essential elements with the goal that my readers could use the code examples as "templates." But I admit I might have gone too far with this approach, even if some beginner developers appreciated it.
So in the 2nd edition, I will attempt to go deeper with the subject matter by mapping some "classical" software design patterns to specific game design patterns. In other words, I will make sure that every code example presented in the book will offer a solution to the implementation of a specific game system. It's a challenging approach because I must find the right balance between explaining software design patterns but showcases how to use them in very concrete examples without losing the reader with wordiness.
It's a challenge that I'm enjoying facing, in the meanwhile, I'm reading all the reviews of the 1st edition, and I appreciate them all, even the negative ones. And I hope that the 2nd edition of "Hands-On Game Development Patterns with Unity" will be useful to the Unity game development community. I promised that I'm working hard to make this edition the best one.
Sunday, 2 February 2020
Writing a 2nd Edition
I want to announce that I'm currently writing the 2nd edition of my first book Hands-On Game Development Patterns with Unity 2019. I'm redesigning this edition based on reader feedback from the previous version. Please don't hesitate to contact me with suggestions; I always take the time to read my reader's comments.
I can confirm the 2nd edition will be focused on building concrete systems of a fully playable prototype of a game. This approach will permit you to have a genuinely contextual understanding of how you can use standard software design patterns to implement game systems in Unity. In other words, in this edition, we will focus on the 'hands-on' approach to programming games in Unity while working on an actual game project.
I can confirm the 2nd edition will be focused on building concrete systems of a fully playable prototype of a game. This approach will permit you to have a genuinely contextual understanding of how you can use standard software design patterns to implement game systems in Unity. In other words, in this edition, we will focus on the 'hands-on' approach to programming games in Unity while working on an actual game project.
Saturday, 23 November 2019
GameDev Tips - Commit Early and Often
One of the worst habits you can have as a game developer is not committing your data or code changes to your main development branch early and often. I have witnessed so many production blottlnecks induced by artists, designers, and even programmers waiting for the last minute to submit their work. And in consequence, causing builds to fail and projects unable to reload after syncing to the latest changes.
In the context of modern CI/CD production processes, this bad habit can be very costly for the entire team. A typical game development team generates a massive amount of highly coupled data, and code changes. So, in consequence, code, as well as data, can break your builds in very subtle ways. The best way to reduce the impact on your deliveries is to test your builds and report regressions as early as possible.
Thus, you must have changes submitted, built, and delivered to your QA several times a day. Especially during the day, when the core team is present and can provide fixes before EOD (end of the day).
My main recommendation to new game developers is to get the habit of submitting your changes to your repo at minimum two times a day. Once before lunchtime and at the latest one hour before leaving the office so you can confirm your changes are building correctly on the build system.
In other words, never leave the office without making sure your changes are building correctly and never wait to submit completed work during the day. It's always better to fail early than too late.
In the context of modern CI/CD production processes, this bad habit can be very costly for the entire team. A typical game development team generates a massive amount of highly coupled data, and code changes. So, in consequence, code, as well as data, can break your builds in very subtle ways. The best way to reduce the impact on your deliveries is to test your builds and report regressions as early as possible.
Thus, you must have changes submitted, built, and delivered to your QA several times a day. Especially during the day, when the core team is present and can provide fixes before EOD (end of the day).
My main recommendation to new game developers is to get the habit of submitting your changes to your repo at minimum two times a day. Once before lunchtime and at the latest one hour before leaving the office so you can confirm your changes are building correctly on the build system.
In other words, never leave the office without making sure your changes are building correctly and never wait to submit completed work during the day. It's always better to fail early than too late.
Thursday, 6 December 2018
Why Busy People Fail?
From experience, the biggest sign you are on the path to failure is that you are feeling “busy” all the time. For a long time, it was taught to us that successful people are very “busy”, hard working individuals and so, we assumed if we are also “busy”, we will be equally successful.
But the truth of the matter, really successful individuals are not actually busy but instead very focus. And there’s a huge difference between “busyness” and being focus.
Here’s my list of reasons that this statement is true.
It’s not about how much you do in a day but about what exactly that needs to be done and when it needs to be done.Successful people know exactly what they need to do and understand the importance of timing.
If you don’t feel in control, then you have already lost, whatever you are an employee or an entrepreneur. Successful people always seek a certain level of control on themselves & they surroundings.
If you don’t seek the minimum effort for the maximum returns then you will burn out and also the people around you. Successful people understand that it’s about constantly reducing the effort needed to accomplish specific goals for themselves & the people around them.
If you are driven by fear of missing an opportunity and pursuing each one in full force, you will probably miss the best ones. Successful people don’t chase after opportunities, they set them up for themselves and wisely chooses which one to actually pursue.
There’s still a persistent myth, especially in the tech entrepreneurship culture, that late nights and 7-day a week work schedules will actually bring about more success. But in reality, it’s a just a recipe for disaster that will end up burning-out your resources, whatever it's your employees, customers, business partners and especially yourself.
But the truth of the matter, really successful individuals are not actually busy but instead very focus. And there’s a huge difference between “busyness” and being focus.
Here’s my list of reasons that this statement is true.
It’s not about how much you do in a day but about what exactly that needs to be done and when it needs to be done.Successful people know exactly what they need to do and understand the importance of timing.
If you don’t feel in control, then you have already lost, whatever you are an employee or an entrepreneur. Successful people always seek a certain level of control on themselves & they surroundings.
If you don’t seek the minimum effort for the maximum returns then you will burn out and also the people around you. Successful people understand that it’s about constantly reducing the effort needed to accomplish specific goals for themselves & the people around them.
If you are driven by fear of missing an opportunity and pursuing each one in full force, you will probably miss the best ones. Successful people don’t chase after opportunities, they set them up for themselves and wisely chooses which one to actually pursue.
There’s still a persistent myth, especially in the tech entrepreneurship culture, that late nights and 7-day a week work schedules will actually bring about more success. But in reality, it’s a just a recipe for disaster that will end up burning-out your resources, whatever it's your employees, customers, business partners and especially yourself.
Sunday, 18 November 2018
Game Industry - Stop hiring designers, start hiring more programmers!
I use to believe the
main bottleneck in the game industry was caused by the fact that they're
was too many designers that were unable to boil down complex systems
into their essential components. This was caused by a lack of
industry-wide standard design methodologies and practices.
The famous Ubisoft's Rational Design school of thought is the closest that we have to an actual universal design process for game development. But I've recently changed my opinion and observed evidences that I was wrong.
After analyzing the recent bug-ridden AAA game releases that's slowly causing a growing customer-revolt and damaging the relationship between the customers and the creators, I've come to the conclusion that the core issue within the game industry is not the lack of good design ideas but a lack of people that actually knows how to implement them correctly.
We have an industry filled to the brim with creative people but of few that can actually implement their ideas in code. And this is caused by the fact that the video-game industry has shifted from a software into a creative-driven field. But the truth of the matter, video-games are SOFTWARE not paintings, not films and not work of arts that need to be displayed in a museum but programs that run on computers.
The industry has forgotten it's roots his in the Silicon Valley hacking culture and not in the Hollywood system. At the end of the day, video-games are a 80% technical endeavor and 20% creative process. The current tropes and core design ideas were not invented by designers but programmers. Not even 40 years ago, games were made by one person, a programmer. But as the "cool" factor of the industry started going mainstream, it attracted people from other fields that didn't understood the software development process.
The current panoply of game studios have pivoted towards such a creative focus organization structure that programmers are being left behind when in fact they're the actual people that make video-games even possible. And that's the root cause why there's so many bug-ridden AAA games coming out with incomplete features and patches that are bigger in-size than the actual original version of the released game.
The famous Ubisoft's Rational Design school of thought is the closest that we have to an actual universal design process for game development. But I've recently changed my opinion and observed evidences that I was wrong.
After analyzing the recent bug-ridden AAA game releases that's slowly causing a growing customer-revolt and damaging the relationship between the customers and the creators, I've come to the conclusion that the core issue within the game industry is not the lack of good design ideas but a lack of people that actually knows how to implement them correctly.
We have an industry filled to the brim with creative people but of few that can actually implement their ideas in code. And this is caused by the fact that the video-game industry has shifted from a software into a creative-driven field. But the truth of the matter, video-games are SOFTWARE not paintings, not films and not work of arts that need to be displayed in a museum but programs that run on computers.
The industry has forgotten it's roots his in the Silicon Valley hacking culture and not in the Hollywood system. At the end of the day, video-games are a 80% technical endeavor and 20% creative process. The current tropes and core design ideas were not invented by designers but programmers. Not even 40 years ago, games were made by one person, a programmer. But as the "cool" factor of the industry started going mainstream, it attracted people from other fields that didn't understood the software development process.
The current panoply of game studios have pivoted towards such a creative focus organization structure that programmers are being left behind when in fact they're the actual people that make video-games even possible. And that's the root cause why there's so many bug-ridden AAA games coming out with incomplete features and patches that are bigger in-size than the actual original version of the released game.
Saturday, 2 June 2018
17 Tricks to Win in Politics
Everything has become political if it's a good or a bad thing, it's a subject for debate but as a game designer, I've started observing this modern phenomenon with the goals of extracting some potential knowledge that could be used to design new mechanics or gameplay around the experience of political debating.
This last year, I've been creating various online personas and "infiltrating" different political groups while provoking debates on social media in hopes to see if I could "play" the political sphere like a game. I accumulated a wealth of knowledge during the process but the following are easy to follow techniques that I have observed that make or break great politicians and debaters.
These tricks can also be used when playing games with no political dynamics like Poker, they are universal in their application but very dangerous when effective, so you have to be careful in what context you use them.
In resume, in politics, you should never try to destroy your enemy with frontal assaults but instead set up mental traps and maneuver them towards them and while they think they're running towards victory, you watch them destroy themselves.
Which is always the best way to win a war or a game!
This last year, I've been creating various online personas and "infiltrating" different political groups while provoking debates on social media in hopes to see if I could "play" the political sphere like a game. I accumulated a wealth of knowledge during the process but the following are easy to follow techniques that I have observed that make or break great politicians and debaters.
These tricks can also be used when playing games with no political dynamics like Poker, they are universal in their application but very dangerous when effective, so you have to be careful in what context you use them.
- You fight bad ideas with better ones.
- The goal while debating is not to convince your opposition but those that stand in the middle. True power is not at the extremes of the political spectrum but in the center.
- Provoke your opponent to the point he his perceived by others as being irrational.
- During a turmoil, people will always seek a strong but reasonable leader, be that person.
- Before arguing ask questions.
- When dealing with an emotional and unreasonable opponent, disarm them with kindness, destroy them with reason.
- Let your opponent fail, especially when their believe their winning. Their confidence will blind them while their dig their own grave.
- If you win then get prepared to lose. Politics is cyclic.
- Always let your opponent talk, each word has the potential of being a weapon that can be used against them.
- Fear is your ally. If they fight you then there are afraid of you. Provoke them until their fears drive them to irrational thoughts and actions. (Check Darth Maul's tone poem.)
- Be interested in your opponent's political views, study them and master them. Then use that knowledge to break them apart into weapons.
- When your opponent has a new ideological weapon, mirror it. Invert their attacks so they reflect back on them. (Trump uses this tactic, just look how he took ownership of the concept of fake news from the left.)
- Infiltrate your opponent's party and provoke chaos from within.
- Politics can be a destructive process, accept it. (Don't worry about losing friends to gain allies.)
- Pick your battles, don't let them choose you.
- Let them see you bleed, show weakness because then you know where and when they will attack you. (Putin uses this tactic all the time.)
- Politics is not about truth, it's about opinions, the strongest ones become law.
In resume, in politics, you should never try to destroy your enemy with frontal assaults but instead set up mental traps and maneuver them towards them and while they think they're running towards victory, you watch them destroy themselves.
Which is always the best way to win a war or a game!
Subscribe to:
Comments (Atom)