I’m thankful WeirdBeardDev introduced me to Fiddle. It even works on mobile so I can create small challenges and practice on my work breaks.
The Rule of the Loop (the more times you test and improve your design, the better your game will be) applies to creating games too – the more I practice, the better I will become.
I was getting too comfortable following tutorials without challenging myself. Once I complete John Lemon’s Haunted Jaunt: 3D Beginner I will begin my own projects. Afterall, I have at least ten sucky games to get out of the way!
If I were a freelance developer, I recon I’d have an upset client on my hands.
The task WeirdBeardDev posed in a comment earlier today was:
Take a number, 1742 and reverse it, 2471. Sum them together, 4213. See if the sum is a palindrome (read the same forward and backward, i.e., 1221). If yes then great. If not, repeat until 1000 iterations or until it is.
So after work this evening I merrily hobbled together a progam using just syntax I remembered. (I’m too ashamed to post the code without completely refactoring it – I know I can clean it up) Below is the output after running it four different times:
(User enters 4 digits. The program concatinates the digits, displays the reverse and sum, and checks whether the 4 or 5 digit sum is a palindrome)
But then I stared at the last part of the task to work on next: “If not, repeat until 1000 iterations or until it is” and realized I hadn’t understood the request properly and based it off several assumptions.
“Virtual keyword is used for generating a virtual path for its derived classes on implementing method overriding” was how one article explained it…which helped not even the slightest. Onto a different article:
“A virtual method is a method that can be redefined in derived classes. It is used when a method’s basic functionality is the same but sometimes more functionality is needed in the derived class. A virtual method is created in the base class that can be overriden in the derived class.”
Okay, that makes more sense. But now I need to look into how a virtual method differs from an abstract one. On the surface they both look like they function similarly with one main difference: an abstract method has to be overriden in it’s derived class whereas a virtual method can remain as-is or be overriden. I think.
I’ll need to do more reading on this topic tomorrow.
The Art of Game Design: A Book of Lenses by Jesse Schell was a remarkable read with eye-opening revelations into how I view games I want to make and those I’ve already played.
It’s one of those books that can be reread and appreciated again and again with each new game project you embark on.
It was entertaining and insightful and I’ll definitely be reading the 3rd edition when it comes out later this year.
“The Art of Game Design is one of a handful of books I continuously reference during production. Whether you’re just starting out or looking for ways to approach your design from a fresh perspective, this book is a must for your library.”
Neil Druckmann, Creative Director on The Last of Us at Naughty Dog
There is also a Game Design: A Deck of Lenses app, however without the accompanying chapter to flesh out each lens or question, it’s more of a reminder than a summary and certainly not a replacement for the book.
As I mentioned yesterday, something else ‘clicks’ with every iteration of a different C# tutorial. That’s my programming learning style: I need to read various definitions and type out different examples for it to sink in (or maybe I’m just a slow learner…)
Although it hasn’t quite ‘clicked’ yet, the fuzzy picture surrounding the static keyword is beginning to sharpen:
There are static classes and members
A static member is a member of the class, not a member of an instance of the class
Static does not mean “cannot be changed”
A static class is directly accessible by its name, can’t be instantiated, can’t be inherited (sealed)
Just a couple quotes I found interesting from the introduction to The Art of Game Design by Jesse Schell:
Please do not think that reading this book, or any book, will make you into a game designer, much less a great game designer. Game design is not a set of principles, it is an activity. You could no sooner become a singer, pilot, or basketballplayer by reading a book than you could become a game designer.
There’s an saying among game designers: “Your first ten games will suck — so get them out of the way fast.