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

Archived

This topic is now archived and is closed to further replies.

Lance

Get rid of these annoying ranks.

7 posts in this topic

The ranks of people posting are highly misleading. The titles of the ranks imply some knowledge of game programming ("guru"??!?!?), but instead their meaning is directly correlated to the persona''s number of posts. Newbies who look through this page for advice are bound to run into posts from "zealots" and "gurus" (whatever the names are) and think highly of the responses. However, a majority of the time these posters are giving bad advice, horrible implementations, and at times completely invalid information. I would take a guess that many of these posters are high school kids who fanatically post replies when they barely have any grasp of the concepts underlying proper procedural and OO design let alone the myriad of other concepts which form a game. Understand that I have no qualms about people learning to program games and their enthusiasm to do so; I (and other professional game programmers) were all once at that same stage. However, I do object to a forum which I believe encourages the "blind to lead the blind." I think newbies helping other newbies out is integral to the learning process. Just remove the labeling system so newbies can''t hide behind titles.
0

Share this post


Link to post
Share on other sites
While ranks do show the number of posts, it gives reason to see that thrtr are certain ones that are:
-prone to help or respond
and
-have been around long enough

While I don''t recomend taking advice based on the ranks, I do suggest that you respond in those cases where somebody is wrong on their advice. The only way for that person to learn their mistake is if somebody informs them, or shows what they believe the proper way is.

As for implementation, the basic rule is usually if it works - go for it. Sometimes I really don''t care if it''s the prettiest looking code, or the easiest way to do something - the question is does it work?



Jim Adams
Game-Designer/Author
tcm@pobox.com
http://www.lightbefallen.com
http://www.basicelectronics.com
0

Share this post


Link to post
Share on other sites
Hmm...

"As for implementation, the basic rule is usually if it works - go for it. Sometimes I really don''t care if it''s the prettiest looking code, or the easiest way to do something - the question is does it work?"

This type of mentality is fine (and probably good) for people beginning programming games. However, for large scale professional games this is IMHO the biggest reason for their long times in development and the crappy bloated code which is the result (and their cancellation / and/or failure). My friends commonly refer to this as "shotgun" programming. I.e. those who instead of thinking of the elegant solution just sit down and hammer out code (sometimes even guessing to the solution) and run the code multiple times to _see_ if it works rather than looking at the code and _knowing_ it works.

I cannot stress the importance of writing an _elegant_ engine. I rewrite major sections of my engine architecture constantly to support seemingly trivial things which make the architecture streamlined. Once you start letting the architecture deteriorate hacks start sinking in and before long you have a huge big mess in which when you fix one bug five more crop up because of the interlinked-hacked mess which was once an engine. I spend hours every week lining up code stylistically and renaming functions to be more mneumonic. The major modules which handle object interactions (i.e. the interface to my engine) all look like very nice API files with highly commented code and functions which share common naming conventions.

0

Share this post


Link to post
Share on other sites
[rant]With proper object oriented design, the "hacks" can be isolated from other more elegant code. Once it''s isolated you can work on getting the product working and then going into your implementations to clean things up, without bringing the whole project down to its knees. If you get a large enough code block from the someone else that you can''t isolate by object coding, then you''re not really a professional.[/rant]

I''ve seen a forum where a moderation method was implemented. *cough* slashdot *cough* The end result was that it enforced a certain kind of thinking. If you didn''t toe the party line, even if you had good points, you were moderated down. This kept others from picking up on the good points. In this board any registered visitors could moderate. The alternative, staff only moderations, was impracticle due to the volume of traffic they were getting.

So I guess the only way you can deal with seeing bad advice, bad implementations, or just outright wrong statements, is whenever you see something, post yourself, and you''ll soon get your rank up there so that you''ll have the influence to sway opinions as well.

I personally have seen poor implementations and perhaps bad choices of function calls (deprecated API entries for example) but only rarely something outright wrong. There are plenty of professionals and real programmers out there to mitigate the "blind leading the blind" effect. They can (and will) blast anyone posting outright bad information. As for me, as long as don''t see "real programmers only use FORTRAN" I''m happy.
0

Share this post


Link to post
Share on other sites
hey Jim Adams-

your that rpg dude i keep hearing about, huh?

Edited by - Uthman on 1/13/00 3:44:05 PM
0

Share this post


Link to post
Share on other sites
Back to the original post...

The current user levels were chosen specifically because they don''t reflect a level of knowledge, but rather a level of dedication (read: activity). "guru" is not among the current titles for that very reason.

Regardless of titles, I think many newbies are likely to believe ANYTHING they are told, regardless of the source, so removing the user levels wouldn''t help that much. Of course, spreading misinformation is a serious problem, so we have measures in place to prevent that as much as possible. The main one is that we have moderators who are knowledgable in the subject they moderator who are supposed to keep an eye out for that kind of thing. The members of the GDNet staff also look at almost every post that''s made. We have a couple of other things in the works too.
0

Share this post


Link to post
Share on other sites
> I rewrite major sections of my engine architecture
> constantly to support seemingly trivial things which
> make the architecture streamlined.

One could just as easily say *this* is why most games are late.

There's a balance between hacking something out and making something elegant, and releasing a good game on time requires you to walk that line very carefullly. I guarantee that every commercial game out there has been hacked together just as much as it has been elegantly designed.

It's silly to say that "too much" or "not enough" hacking is why most games are late. Reality is much more complicated than that.


Mason McCuskey
Spin Studios - home of Quaternion, 2000 GDC Indie Games Fest Finalist!
www.spin-studios.com

Edited by - mason on 1/13/00 6:03:54 PM
0

Share this post


Link to post
Share on other sites
*Shrug* people can tell me hacking is acceptable all they want.

It is not a practice all game programmers follow. I might lose some time reworking my architecture but I can honestly count the number of hacks in my game engine code on two hands. If you have ever worked on a AAA project with multiple programmers from the genesis of the idea to the end you know that doing it the "right way" might suck _now_ but you will be thanking yourself six months down the road when one change to the game pipeline screws half the game up.

I think the trend towards properly engineered engines is increasing while companies with old-school shotgun programmers are going to start having difficulty. Software engineering costs are climbing and unless companies can engineer reusuable, solid code they will find rewriting projects from scratch each time both cumbersome and cost-prohibitive.

There are few times and places for hacks. If you run across something that needs to be hacked a majority of the time this means you didn''t think your design through. Instead of pushing this hack on your system, I advocate rewriting it. If you don''t you might end up hacking on a hack and then eventually you will have a big mess.

Caveat: Hacking is less a problem the smaller a game gets. My opiniion mainly revolves around my experience recently (~1-2 year AAA games).
0

Share this post


Link to post
Share on other sites