Visio (or a similar piece of software) and a pen & pad combo are your best friends when it comes to the OOP design paradigm. While there is always some debate as to whether UML is actually useful, it all comes down to preference. For example, my design process is like so:
1) I usually run through the program in my head, thinking about the various class that I would need to create. While this never is an exact match to the end product, it gives me a place to start.
2) Once I get some ideas flowing through my head, I go to the pen & pad, and start to jot down my ideas, considering how they all fit together. I continue to do this until I have a prototype that I think might work.
3) At this point, I move on to Visio and create a UML structure from my prototype. While creating the UML, I usually realize a few flaws that I didn't catch before, and fix them accordingly.
4) Once the UML Is finished, I take a few days (different sittings) to reread the UML and try to catch more problems.
5) Once I'm confident that the UML is sound, I start to implement it in code.
6) There is sometimes some tiny details that I missed that I directly correct in code and then alter in the UML.
Keep in mind, however, that although this is my method, everyone has their own ways of doing things. The trick is finding your own means. No one's mind works the same as some one else's.
Planning (OO - Design) ?
I personally take this view even further. Every program in existence is a database. Even "Hello world" is a database, it consists of the data "Hello world" and the "view" or "transformation" how ever you want to specify the results of "printf" in this case In terms of "transormation" it would be to move DB entries to console output, in terms of view it would be "printf" is the view implementation. Blocks are just a piece of data: "color at grid location". A "pixel" representation of the block is just a transformation to a different view, and a shape is just a higher level representation of multiple blocks in the database.
Usually these data transforms are thought of as various game systems and the connections between them. Consider the case of taking a game world item and transforming it into a visible form, you "transform" the internal representation into 2d/3d coordinates and assign a view to the result. I.e. you map an index in the db to a pixel location on screen and draw the "view" of the data at that location. Going the other way, you can't just insert multiple blocks into the game world to represent a shape, you have to keep information about the shape so that moving it down, rotating it etc properly move all blocks at the same time. In DB terms, you build a temporary table to contain the shape, and the "visualization" merges the temp table and the game world.
I know, an odd idea. But I'd put bets on no one able to present a case where a program is not explainable as a DB.
That seems like an awkward way of thinking of things. At least the 'everything is a function' mental model of lambda calculus has its own elegance/provability.
[quote name='AllEightUp' timestamp='1318388427' post='4871703']
I personally take this view even further. Every program in existence is a database. Even "Hello world" is a database, it consists of the data "Hello world" and the "view" or "transformation" how ever you want to specify the results of "printf" in this case In terms of "transormation" it would be to move DB entries to console output, in terms of view it would be "printf" is the view implementation. Blocks are just a piece of data: "color at grid location". A "pixel" representation of the block is just a transformation to a different view, and a shape is just a higher level representation of multiple blocks in the database.
Usually these data transforms are thought of as various game systems and the connections between them. Consider the case of taking a game world item and transforming it into a visible form, you "transform" the internal representation into 2d/3d coordinates and assign a view to the result. I.e. you map an index in the db to a pixel location on screen and draw the "view" of the data at that location. Going the other way, you can't just insert multiple blocks into the game world to represent a shape, you have to keep information about the shape so that moving it down, rotating it etc properly move all blocks at the same time. In DB terms, you build a temporary table to contain the shape, and the "visualization" merges the temp table and the game world.
I know, an odd idea. But I'd put bets on no one able to present a case where a program is not explainable as a DB.
That seems like an awkward way of thinking of things. At least the 'everything is a function' mental model of lambda calculus has its own elegance/provability.
[/quote]
Actually I have a much similar approach in thought ^.^ Maybe I don't go as hardcore as the feller in the quote, but it's basically manipulating data.
[quote name='Telastyn' timestamp='1318444213' post='4871944']
[quote name='AllEightUp' timestamp='1318388427' post='4871703']
I personally take this view even further. Every program in existence is a database. Even "Hello world" is a database, it consists of the data "Hello world" and the "view" or "transformation" how ever you want to specify the results of "printf" in this case In terms of "transormation" it would be to move DB entries to console output, in terms of view it would be "printf" is the view implementation. Blocks are just a piece of data: "color at grid location". A "pixel" representation of the block is just a transformation to a different view, and a shape is just a higher level representation of multiple blocks in the database.
Usually these data transforms are thought of as various game systems and the connections between them. Consider the case of taking a game world item and transforming it into a visible form, you "transform" the internal representation into 2d/3d coordinates and assign a view to the result. I.e. you map an index in the db to a pixel location on screen and draw the "view" of the data at that location. Going the other way, you can't just insert multiple blocks into the game world to represent a shape, you have to keep information about the shape so that moving it down, rotating it etc properly move all blocks at the same time. In DB terms, you build a temporary table to contain the shape, and the "visualization" merges the temp table and the game world.
I know, an odd idea. But I'd put bets on no one able to present a case where a program is not explainable as a DB.
That seems like an awkward way of thinking of things. At least the 'everything is a function' mental model of lambda calculus has its own elegance/provability.
[/quote]
Actually I have a much similar approach in thought ^.^ Maybe I don't go as hardcore as the feller in the quote, but it's basically manipulating data.
[/quote]
Data is the #1 item in most games, code is secondary in my thinking. (Long years of optimization; almost everything ends up as a data access problem at the most critical points.) But, keep in mind when I said "database" I should have been using the term "data" without limitation or implied structure. A vector is a database, a list is a database, a scene graph is a database, and of course a simple "string" is a database. A database in my thinking is "data" with a set of queries defined and/or a generic query system. (All containers in STL are "databases" by this definition.) For the game programmer, this means thinking about something like a scene graph and considering the data which is stored and how you intend to query it (and by definition use it in various places). Or, for a spacial awareness system, a db of points in space, some underlying structure and the queries which will be used on it.
Given the original question this is getting very off topic, but the underlying data almost always drives the oo "design" and the problems with the designs are usually only found when you try to access the data and find that various pieces of code don't have efficient/direct access. I'll write entire systems using nothing more than a vector knowing that it will be horribly inefficient just to make sure the data organization works. So long as the data layout is valid it is quick and easy to rewrite all the internals with proper structure and efficient implementations. As soon as you hit a data layout problem though, those are usually the most nasty issues because moving data implies changing all accessors to that data which can be very significant portions of code.
Again, it's an extreme view, but it works for me.
"A database in my thinking is "data" with a set of queries defined and/or a generic query system. (All containers in STL are "databases" by this definition.)".
In OO parlance, this is an "object".
In OO parlance, this is an "object".
Visio (or a similar piece of software) and a pen & pad combo are your best friends when it comes to the OOP design paradigm. While there is always some debate as to whether UML is actually useful, it all comes down to preference. For example, my design process is like so:
I think the UML standard is more debatable than the concept of diagramming your system. I don't know anyone who has found diagramming bad and consistently made good system design decisions.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement