• 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.

spinningcube

Members
  • Content count

    124
  • Joined

  • Last visited

Community Reputation

90 Neutral

About spinningcube

  • Rank
    Member
  1.   I'm sure a bad designer would produce crappy work no matter the methodology. Granted, OOP gives you a richer set of tools to introduce strange and unnecessary relationships, and in that case sticking to C/Pascal might give you some damage control.   You need an experienced designer willing to take the time to constantly re-evaluate the design as the system grows.       I highly recommend Evans Domain Driven Design. Beware that it's not a beginners book. Although it has a lot of patterns (OODish or whatever you want to call it), I think the main point is more the process or rather mindset when designing large software systems.     Exactly re-evaluation is one of the most interesting skills in a designer and it is easier implemented if the core architecture is also agile (not as in agile development) meaning re-adaptable.   Sometimes though with very complicated object oriented designs it is better to just start over from scratch. That is also true of non-object oriented though. However with time pressures on projects this is often left unattended and many times a system that would better be scrapped and re-coded in 2 months takes 6 months of artificial life support before it finally is re-designed. However most of the time when this re-design is then done, the manager at a higher level then demands a "grand" design which of course will make the cycle repeat. But now we go into politics rather than technical parts of it. Sometimes I think it's better to show a grand design scheme to management with lots of intricate arrows and boxes and have a an actual simple implementation for the running system ;-)   Thanks for the ref, will have a look :-)
  2.   *sigh*   I'd suggest you stay in academia, old sport. Probably the only place you can stay afloat based on skills and experience alone. In the real world, being rude, arrogant and patronizing works against you regardless of your certificates.   Its a shame. You'd be a great learning resource if you were able to interact well with others.     Haha! Working on it. Thanks for the backhanded compliment ;-)
  3. Very cool explanation Hodgman,   For the OOP/OOD debacle I think it is because I have seen much bad OOP code in production systems (I have had my own company since 2006, but admittedly I always have a strong bond to academics, I want to improve scientific data visualisation) and with lots of zealots marrying themselves to concepts that you say (inheritance for re-use, coupling, over-use of templates etc.) where they are "experts" but only experts in making the code more bloated, harder to understand and hard to extend.   I've seen this so many times in companies that I think it boiled down to the fact that the designer wanted to have job security by designing something overly complex and that management would never dare to touch. I have also been part of such management and seen it pushed on me.   I have always pushed for independent code blocks, modules and as much as possible data oriented programming not because it gives better performance (but sometimes does, in fact most of the time does as access is often linear and sequential (but that is another discussion)) but because it it allows for clean decoupling almost treating the code as some kind of scripting language doing transformations on data.   So yeah, when I see clean OOP code I am more than often surprised and it is mostly because the person has gone though the zealot years of OOD (what you call badly taught OOD and I agree, just that it is so dominant right now it is hard to say what is good OOD) then came out "cleansed" of such over complicated notions and has a better flexibility with design and thinking about programming.   I have a much easier time thinking of someone with a background with a function based (not functional lambda calculus) experience like C/Pascal will do a better job at designing software than someone with a (bad) OOD background. He or she would use the modules approach of Pascal and apply it to OOP and we would all be happier for it.   I am always trying to improve and to know more about OOD (a new improved way) is always interesting.
  4. (To the guys (as a group) that try to oppose the obvious. Not the OP who is caught it in the crossfire.)   If you still don't get it after my posts and the post of hodgman, I am at loss of words.   Hang in there some 10+ years and then get back to me.   Cheers,     PS - and then you can buy me a beer ;-) No hard feelings fellows. You just don't want to get it.   PS2 - Pro tip. Look me up and see what I have achieved. Then think.
  5. I actually took the time to read the PDF out of curiosity (though, it is kind of misleading to post two links, when one is just a couple paragraphs and a link to another).   What I got from it is completely different from what you are saying. [...]   None of what he was saying is bashing OOP, in my opinion. Referring back to the aforementioned example of a key => value dictionary, he didn't advocate getting rid of the object entirely, just redesigning how it works on the inside; the interface may even go unchanged!     So then why is the author summing it up with?   (Lie #1) Software is a platform I blame the universities for this one. Academics like to remove as many variables from a problem as possible and try to solve things under "ideal" or completely general conditions. It's like old physicist jokes that go "We have made several simplifying assumptions... first, let each horse be a perfect rolling sphere..."   The reality is software is not a platform. You can't idealize the hardware. And the constants in the "Big-O notation" that are so often ignored, are often the parts that actually matter in reality (for example, memory performance.) You can't judge code in a vacuum. Hardware impacts data design. Data design impacts code choices. If you forget that, you have something that might work, but you aren't going to know if it's going to work well on the platform you're working with, with the data you actually have.   (Lie #2) Code should be designed around a model of the world   There is no value in code being some kind of model or map of an imaginary world. I don't know why this one is so compelling for some programmers, but it is extremely popular. If there's a rocket in the game, rest assured that there is a "Rocket" class (Assuming the code is C++) which contains data for exactly one rocket and does rockety stuff. With no regard at all for what data tranformation is really being done, or for the layout of the data. Or for that matter, without the basic understanding that where there's one thing, there's probably more than one.   Though there are a lot of performance penalties for this kind of design, the most significant one is that it doesn't scale. At all. One hundred rockets costs one hundred times as much as one rocket. And it's extremely likely it costs even more than that! Even to a non-programmer, that shouldn't make any sense. Economy of scale. If you have more of something, it should get cheaper, not more expensive. And the way to do that is to design the data properly and group things by similar transformations.   (Lie #3) Code is more important than data   This is the biggest lie of all. Programmers have spent untold billions of man-years writing about code, how to write it faster, better, prettier, etc. and at the end of the day, it's not that significant. Code is ephimiral and has no real intrinsic value. The algorithms certainly do, sure. But the code itself isn't worth all this time (and shelf space! - have you seen how many books there are on UML diagrams?). The code, the performance and the features hinge on one thing - the data. Bad data equals slow and crappy application. Writing a good engine means first and formost, understanding the data. 
  6. The only good thing about OOP is data encapsulation and the best case scenario for OOP is binary interface classes where the user has no access to the inside code.   When it comes to inheritance I am basically against both shallow and deep ones as both create a co-dependence on some pre-set design and therefore consequently create problems with code re-use as you are stuck to a certain pattern.   For example the gravity function would be re-usable but not a gravity class given that the in parameters are raw data such as arrays of floats or similar. What is even more interesting is when it comes to performance where OOP basically has to pack it and go home.   The root of all evil and the great temptation to do wrong is as hodgman pointed out, the article pointed out and as I have pointed out Object Oriented Design.   OOP in itself is just "a neutron bomb kit" but combined with OOD we get the real danger :-) Then the neutron kit is assembled and presented as something great when if fact it will just blow up and leave a wasteland to the code.   OOD in this case being UML design, finding objects from problem specifications etc. Basically what many program design books are preaching.   The best of both worlds is possible and as pointed out several times OOP when treated as structures or the very naive part of OOP is used can be a good tool.   One example I can come up with is a recent project where I did a 3D voxelisation of a brain. The brain model was in fact based around a tiny structure of voxels. I fed them to different functions that did the voxelisation, the bounding volume hierarchy, ray tracing etc... And it was all done without the bounding volume hierarchy knowing about the brain or even voxels for that matter.   I have some quite nice large functions that take the voxel data as in parameters and transform this data into other structures. It's beautiful.   At the same time having some form of OOP was good for the brain model where I hid the 3DS loading in another class and lo and behold I did use sub-classing for the GUI system as it made sense to have some parts virtual functions.   When OOP comes up however most of the time OOD is implied and that has killed many promising projects by over-engineering problems with complexity that was never there.
  7. Nice example hodgman!     PS - I should make you my personal PR spokesperson ;-)
  8. My interpretation of this is that the more you idealise your problem and your problem domain using objects, the more you stereotype your problem and you in fact create a new one, that might actually be harder to solve. For example as in the slides with the chair, why is there a chair object that you can act upon, rather than a game object that happens to have a "sitable" tag?   I still use objects such as mesh, grid etc... but I try as much as possible to make them not contain the data but rather be a table of functions that take data as parameters. The more you contain the more "dead" your code becomes.
  9. That is just me being me ;-)
  10. http://www.insomniacgames.com/three-big-lies-typical-design-failures-in-game-programming-gdc10/   Maybe :-) I'm just too much of an idealist trying to wake people up by shaking up their beliefs.   I hope someone actually reads the link and takes home a betterment to their coding style and design thinking.   Cheers,
  11. http://www.insomniacgames.com/three-big-lies-typical-design-failures-in-game-programming-gdc10/   Haha!   Oh it's refreshing how programmers react with their gut, religiously bashing what they cannot understand or have a blind spot to. Talk to any game (or non-game) programming veteran and they will show you how   OOP design leads to zero core re-use (this is sold as the big thing but in fact more than often leads to code trashing) Function based and data oriented is plug-and-play OOP for simple data encapsulation is ok. (I never said I don't use structs or templates and other "naive" OOP concepts) How thinking of objects and object-to-object interaction leads to more complex code while data transformations leads to less complex.   No this has nothing to do with entity-component which in my mind is also an OOP fallacy. Hah! Now I just upset two hornets nests...   If you actually read what I have in the link (will take maybe 40 min) you see it's from seasoned programmers from Insomniac games, with the best programmer working environment in the industry. Is that a coincidence? Maybe they actually think less stereotyped and more free about programming?   Meditate on that :-)   PS - why do I even bother...   PS2 - The reason I think OOP is used in programming is to increase code trashing, design cycles and increasing complexity such that more money can be demanded from clients. I think that was the original factor ;-)
  12. Since it falls on some deaf ears.   http://www.insomniacgames.com/three-big-lies-typical-design-failures-in-game-programming-gdc10/   https://d3cw3dd2w32x2b.cloudfront.net/wp-content/uploads/2011/06/threebiglies2010.pdf   Short version:   (Lie #1) Software is a platform I blame the universities for this one. Academics like to remove as many variables from a problem as possible and try to solve things under "ideal" or completely general conditions. It's like old physicist jokes that go "We have made several simplifying assumptions... first, let each horse be a perfect rolling sphere..."   The reality is software is not a platform. You can't idealize the hardware. And the constants in the "Big-O notation" that are so often ignored, are often the parts that actually matter in reality (for example, memory performance.) You can't judge code in a vacuum. Hardware impacts data design. Data design impacts code choices. If you forget that, you have something that might work, but you aren't going to know if it's going to work well on the platform you're working with, with the data you actually have.   (Lie #2) Code should be designed around a model of the world   There is no value in code being some kind of model or map of an imaginary world. I don't know why this one is so compelling for some programmers, but it is extremely popular. If there's a rocket in the game, rest assured that there is a "Rocket" class (Assuming the code is C++) which contains data for exactly one rocket and does rockety stuff. With no regard at all for what data tranformation is really being done, or for the layout of the data. Or for that matter, without the basic understanding that where there's one thing, there's probably more than one.   Though there are a lot of performance penalties for this kind of design, the most significant one is that it doesn't scale. At all. One hundred rockets costs one hundred times as much as one rocket. And it's extremely likely it costs even more than that! Even to a non-programmer, that shouldn't make any sense. Economy of scale. If you have more of something, it should get cheaper, not more expensive. And the way to do that is to design the data properly and group things by similar transformations.   (Lie #3) Code is more important than data   This is the biggest lie of all. Programmers have spent untold billions of man-years writing about code, how to write it faster, better, prettier, etc. and at the end of the day, it's not that significant. Code is ephimiral and has no real intrinsic value. The algorithms certainly do, sure. But the code itself isn't worth all this time (and shelf space! - have you seen how many books there are on UML diagrams?). The code, the performance and the features hinge on one thing - the data. Bad data equals slow and crappy application. Writing a good engine means first and formost, understanding the data. 
  13. My take on this. As long as you move away from encapsulating data in objects and rather work on data in its rawest form and sending them to functions - the better.   However what I see in your approach is some form of super-object-oriented or semantics based rule language. As I abhor OOP and especially OOP design based principles, this would be the pinnacle of bad programming practice as it cements the use of objects that make the problem more complex and harder to solve.   Sorry to sound so harsh, but I really believe that what you do will bite you in the end.   You just create massive confusion like this and your code would become unmaintainable.
  14. I personally think that building a tinier PC with just the minimum amounts of processing power you need for a game server would be cheaper than getting a cloud storage system in itself. Well, maybe not, but you can easily get a very good server for 400 USD or less. The lower the power (the lower the heat) and the less the noise of the fans the better. On this you can trust me (that less noise and less heat is a blessing), sitting in a room with 10 nodes at the moment with super silent 65W Hashwells. 
  15. Forget it. Future proofing code is the source of all procrastinations (trust me, I am fighting my instinct to do the "smart thing" every day :-) ). When you want to write your improved algo you will know better how to adapt and how to change it. No need to write a thesis about ray intersection abstraction or bit pattern matches. The code used in production renderers using octrees and sparse voxel octrees (whih I think are just a fad and so does John Carmack ;-) ) is so human unreadable that it hurts the eyes. It's layers of hack on hack of bit pattern shifts and masks that you won't know what is going on.   Long story short. Just implement what you have and think of speed and other data structures later.