• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
  • entries
    33
  • comments
    37
  • views
    38390

[Structure] Stop The Catch All's!

Sign in to follow this  
Followers 0
superman3275

750 views

How do you write your classes? Are they neatly divided into different member functions, each one handling a small responsibility that plays into the larger responsibility of the class? If they are, good for you! You're following one of the main Principles of clean code, the single responsibility principle. However you're taking it a step further. Instead of only applying it to your class, you're applying it to your functions too.

Wait, do you have the common Update() function? Or how about the Logic() function? You might have your classes neatly divided up, however this will ruin your whole class. The point of the single responsibility principle is to make your code easy to read and to make it easy to understand why you're doing what you're doing. Calling Collision.Physics().CheckCollision(Collision.GetNextTile(), Collision.GetNextTile()) would be almost impossible to understand, that's why you divide you Tile Manager, Physics Manager, and Collision Manager into separate classes. So calling Collision.Logic() or Collision.Update() ruins the harmony. What does Logic() do, what does Update() do? Wouldn't it be far easier to read if your code was calling if it was structured like this:

for (int CurrentTile = 0; CurrentTile < Collision.NumberOfTiles(); ++CurrentTile)
{
Collision.CheckTile(CurrentTile);
}
if (Collision.ThereWasCollision())
{
Physics.AcceptCollisionPoints(Collision.GetCollisionPoints);
}

It would be. That's why calling an Update() or Logic() function is bad. No-one will have any idea the sum of what that function does. Imagine going back to your code in a month (Wait, do I still have to give my Physics object the collision points, no Update() does that, what about testing Collision on slopes?....). You'll have no idea what functions you need to call, and it would probably result in you searching through your Physics and Collision classes trying to figure out what's doing what.

This often becomes and issue of coding the right way or going the lazy path. A lot of times you just want to write the "catch-all" Logic() or Update() function because you're lazy or don't want to write down the extra code. Now, if you're going to be doing what I did in the code above many times, then it would make sense to create a function that does it for you. You just need to give it a proper name (Collision.CheckCollisionandSendPoints(Physics)). Now, there is probably a better name for it, however I just couldn't think of one (Stupid Me tongue.png!).

Even if it's more code, coding the right way will pay out in the long run. Resulting in adding features extremely easy. For example, when I made breakout my code was filled with these functions, all kinds of extremely specific properties, and a code-base that resulted in needing fifty classes passing to each other, making adding power-ups a futile attempt. You often need to strike a balance. My code-base would have been more expansive and readable had I been more lenient on the principles I was using. You can never "always" apply a principle, however when it applies, it applies (When using it strictly makes sense, it really helps your code).

I hope you enjoyed this article, and please comment below with how you handle your functions. If you disagreed with it or have a correction, feel free to criticize me and mock how amateur I am tongue.png!

0
Sign in to follow this  
Followers 0


0 Comments


There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now