|Jim Perry (Machaira)|
To OOP Or Not To OOP
Object Oriented Programming (OOP) has been the topic of a lot of posts Iíve read lately in message boards. People asking what it means, how to do it, whether or not they should do it, flames against, posts for, Iíve seen almost everything that could be said about it. Conflicting experiences are as common as conflicting opinions based on no experience. This column will be my opinion based on experiences Iíve had, not just what Iíve heard. Still, donít just take my opinion (good as it is J) for yourself, do your own experimenting. Youíll not only know whether or not itís for you, youíll learn something as well, and thatís whatís most important in the end.
Human beings think in terms of objects since weíre a mainly vision oriented species. Thinking of code in terms of objects is just an extension of this. Consider a GUI system in a game Ė which would you rather see:
and considering you could have dozens of window objects in a games GUI this would get very ugly very rapidly.
Or consider what the possible code for an RPG character would be like Ė dozens of variables to track everything from the character stats to his equipments, skill, spells, etc. This is an example just begging for a class. Some people might be tempted to use a UDT and functions in a regular code module. This is a possibility but consider that the functions wonít know what instance of the UDT to work with. You would have to pass it into the functions since you could have more than one character (not just a player character, but NPCs and monsters which could also all use the same code) that the code operates on. In the RPG Iím working on my entity class currently has 42 member variables 8 of which are class objects. And this is by no means the final version. Who knows how many member variables and functions it will end up with. Currently it knows how to load and save itís data, checks to see if itís dead when itís damaged, checks any bonuses that it currently has that are time based to see if theyíve expired and adjusts itself automatically, knows how to perform actions and uses the necessary equipment for every action it can perform (ex. If the character starts swimming it puts away any weapon and/or shield it might be carrying), and updates itís mana when spells are cast. Thereís more to the class than these few examples but I think you get the idea. All of this code could be done in a regular code module, but imagine the headache of making sure youíre working on the correct character.
People say writing OO code is more difficult than writing non-OO code. This depends on the person and their background. If a person starts their programming career learning Windows programming theyíll get exposure to some OO aspects right off the bat Almost everything in Windows is based on a Window object. A button is just a Window with some extra member variables and functions. The same for a ListBox, RadioButton, etc. They all inherit the base Window object functionality and add what they need that isnít in the base object. I wrote code for many years before starting on Windows programming. It took a little time to switch my thinking to an OO frame of mind, but now that I have I canít imagine writing code any other way. Humans think it terms of objects since weíre mainly vision oriented so itís not a big deal to get used to the idea of thinking in terms of code objects.
The biggest reason I hear against using OOP techniques is that it slows down a program. This just isnít true. Any code can slow down a program if itís poorly written. Usually the extra hoops you have to jump through to get non-OO code to work in different circumstances takes more time than cleanly written OO code. You may see examples of non-OO code vs. OO code in speed demos, but usually these demos are practically useless in real-world situations. Usually these examples are differences of milliseconds, which could be negligible anyway.
Given the fact that most games are usually written by more than one person, would you rather be on a team of programmers who used OOP techniques which made understanding, using, and modifying their code easy or a team of programmers who each had their own style of programming, none of which was clean, easy to understand or modify? In the former case, usually youíll sit down and come up with a list of objects that will be necessary and each programmer will work on a couple of these Ė no collision of work. In the latter case, there could be plenty of opportunities for collision of code and effort. Give me a team of OOPers any day!
Iíll be the first to admit that writing OOP code takes a little more effort up front. Every single time, however, Iíve never regretted the work. Itís saved me a huge amount of time in the end. Before I started writing OOP code, even though I would have some up-front design Iíve had to rewrite chunks of code several times since it never did what I ended up needing it to do and adapting it to work with what I ended up needing it to do was a nightmare. It was more time than if I had taken the time to design it in an OOP manner.
Before you dismiss OOP, take some time to learn and use it. Iíll almost guarantee you wonít regret it in the end and youíll never go back to non-OOP if you can help it.
Read the Freaking Manual
State of the VB Gaming Community Address
|Jim Perry is:|
|A programmer at Breakaway Games|