• 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.
Sign in to follow this  
Followers 0
Tutorial Doctor

Your one stop shop for the cause of all coding horrors

37 posts in this topic

My personal project right now is a world conquest game that has various source files for rendering the globe. The internal name of the project (i.e. the one I use in code, not the one it will release under) is Globo.

 

I think of that Smurf Naming thing every time I type: #include "Globe/Globo_Globe.h"

0

Share this post


Link to post
Share on other sites

"Heisenbug"

 

yeah, those are annoying...

 

like, bug which is annoyingly hard to recreate and occurs rarely, may appear only when not run in a debugger, or when the code is stopped/single-stepped there is no evidence of the bug's existence... (ex: program runs with a bug, set a break-point, single-step, and everything works as intended...).

 

 

may sometimes be due to "spooky action at a distance", like (off somewhere in some distant part of the program) instead of writing "foo[x*y+z]=...;" one wrote "foo[x*y*z]=...;" which may otherwise go largely unnoticed if it fails to land on an unused memory address (may be very common for programs where most of the address space is in-use).

 

may be also be called "dude, where's my RAM?" if it also results in an intermittent memory leak.

Edited by BGB
0

Share this post


Link to post
Share on other sites

I have to admit, the Egyptian brackets do annoy me. But then, lower-cased first letters of functions names annoyed me, but now I prefer it that way. So did underscores in variable names. 

0

Share this post


Link to post
Share on other sites


Egyptian brackets do annoy me

I prefer Egyptian brackets because it eats less lines. Indents give enough information what is inside which block so I don't need brackets to tell me same thing.

0

Share this post


Link to post
Share on other sites
function EgyptianizeTheBracket(){
    looks missing;
}

function UnEgyptianizeTheBracket()
     { for short lines;}

function UnEgyptianizeTheBracket()
     {
     for longer lines;
     }

Good point Zaoshi. I just think that having them on the next line shows the start and end of the code inside the function. Along with indentation it just looks neater. 

Edited by Tutorial Doctor
0

Share this post


Link to post
Share on other sites

I've been using Egyptian brackets for a long time, so I read indentation, not brackets. When I have to read code based on brackets instead of indents it's too hard for me (luckily VS2013 has autoformatting!).

0

Share this post


Link to post
Share on other sites

I love egyptian brackets but not everywhere, i think they are most fitted for ifs and while/for loops. Function and switch should use normal brackets style.

void Function()
{
    if(x == 1){

    }

    for(;;){

    }

    switch(x)
    {
    case 0: ...
    }
}
1

Share this post


Link to post
Share on other sites

Maybe, but as the article says, it like saying "if blue is the sky" or "if tall is the man", it's just harder to read this way imo. Forgetting a '=' is not an excuse for writing harder to read code imo, since that doesn't happen very often.

 

Beside, i dont know about other compilers, but doesn't visual studio warn us about this kind of error as a warning at compile time?

 

EDIT: Seem like it dosent warn you after all... i was mistaken. That's a weird quirk of the language tho, assigning a value returning true, i never understood why c++ allowed that in the first place.

Edited by Vortez
2

Share this post


Link to post
Share on other sites

EDIT: Seem like it dosent warn you after all... i was mistaken. That's a weird quirk of the language tho, assigning a value returning true, i never understood why c++ allowed that in the first place.
 

 

This is not a quirk of the language, its only returning true if the assigned value is truthy, this allows for constructs like the following that are allowed in almost all languages i've ever used:

while (mesh = imaginaryMeshStack.pop()) {
// do stuff with "mesh" here
}

EDIT: "returning true" is the wrong wording, "evaluates to true" fits better here.

Edited by LJ_1102
0

Share this post


Link to post
Share on other sites

EDIT: Seem like it dosent warn you after all... i was mistaken. That's a weird quirk of the language tho, assigning a value returning true, i never understood why c++ allowed that in the first place.

 

It doesn't really return true, it "returns" the result of the assignement.

if(var = 5) // -> if(5) => true

if(var = 0) // -> if(0) => false

It has its uses though

if(auto pMesh = GetMesh(L"Lala") // only enters when pMesh is no nullptr
{
 // DO SOMETHING
}

// pMesh not accessible here
// VS

auto pMesh = GetMesh(L"Lala");
if(pMesh != nullptr)
{
 // DO SOMETHING
}

// pMesh still accessible

EDIT:

 

It does warn you of the opposite, though:

const int constant = 5;
int variable = 0;
variable == constant;
warning C4553: '==': operator has no effect; did you intend '='?
Edited by Juliean
2

Share this post


Link to post
Share on other sites

EDIT: Seem like it dosent warn you after all... i was mistaken. That's a weird quirk of the language tho, assigning a value returning true, i never understood why c++ allowed that in the first place.

In my experience, at least VC++ versions 2008/2010/2012/2013 will give "warning C4706" - if your warning level is at least /W4. However, some of the warnings are just noise (constant conditional expression). "/w44706" might be more preferable option (sets warning level for C4706 to 4, without affection others).

http://msdn.microsoft.com/en-us/library/thxezb7y%28v=vs.120%29.aspx

Recheck your settings.

 

edit: Forgot to add my 2 cents. I hate "Yoda Conditions" and consider it a strictly bad practice. Just do not do it.

Edited by tanzanite7
0

Share this post


Link to post
Share on other sites

Actually, since i mentioned the existence of useless/unhelpful/bogus warnings - why not share them. For readers benefit:

 

#pragma warning(disable : 4201) // (BOGUS) nonstandard extension used : nameless struct/union  // C++11 allows it
#pragma warning(disable : 4510) // (BOGUS and USELESS) default constructor could not be generated // generates an incorrect warning with "struct Foo { const int; } snafu[] = {{1}, {2}}; "
#pragma warning(disable : 4610) // (BOGUS and USELESS) struct can never be instantiated - user defined constructor required // this is just wrong (caused by const member variable)
#pragma warning(disable : 4512) // (BOGUS and USELESS) assignment operator could not be generated // it is only a problem when you use it - and it is an error then. What was the point of this warning again?
#pragma warning(disable : 4100) // (UNHELPFUL) unreferenced formal parameter // i prefer to keep the name of the parameter for clarity even if the particular implementation does not use it
#pragma warning(disable : 4127) // (UNHELPFUL) conditional expression is constant // this is actually almost always desired
#pragma warning(disable : 4310) // (UNHELPFUL) cast truncates constant value // BOGUS: int16(0x8000), VALID: int16(100000). However - i have never encountered the later.
 

With thous i have no warnings at all with warning level 4.

0

Share this post


Link to post
Share on other sites

Maybe, but as the article says, it like saying "if blue is the sky" or "if tall is the man", it's just harder to read this way imo. Forgetting a '=' is not an excuse for writing harder to read code imo, since that doesn't happen very often.

 

Beside, i dont know about other compilers, but doesn't visual studio warn us about this kind of error as a warning at compile time?

 

EDIT: Seem like it dosent warn you after all... i was mistaken. That's a weird quirk of the language tho, assigning a value returning true, i never understood why c++ allowed that in the first place.

 

Depends on how your read it. "if blue matches (is) the color of the sky" or "if tall matches (is) the height description of the man" Gotta name your variables something meaningful. ;)

0

Share this post


Link to post
Share on other sites


#pragma warning(disable : 4127) // (UNHELPFUL) conditional expression is constant // this is actually almost always desired

 

It is? Isn't the conditional expression rather pointless if it is constant or am I missing something?

0

Share this post


Link to post
Share on other sites

Gamedev forum software crapped its pants again, so can not use any formatting. Did my best to make it readable.

------------------------

 

frob: "4201 is valid unless you told the compiler to use c++11."

 

VC++ does not have such a specific switch - all that it is capable of supporting is enabled by default. And i use a lot of c++11 features. One might say that vc++ is not really c11 - but that is not an useful distinction as it tries to be everywhere else.

 

frob: "The invalid automatic functions are correct, these are not things the compiler can automatically generate."

 

_Nor does it need to_. The warning is a very low priority bug in the compiler: http://connect.microsoft.com/VisualStudio/feedback/details/488660/improper-issuance-of-c4610

 

Even so, it is still an useless warning as the language does not allow improper use anyway (ie. more than it normally does) - there is nothing worth warning about.

 

And yes, one should generally avoid such structures. Exceptions excepted (funny: commented out the warning to see where i use them => apparently i do not use them at all anymore [except a few of the assignment ones - adding "=delete" assignments]).

 

frob: "4100 is a fun one that requires an understanding of the language history."

 

Interesting. I did not know that backstory. Thanks.

 

frob: "The 4310 case is VERY valid in this case. int16(0x8000) is an overflow"

 

Exactly. Which is why it is tagged "UNHELPFUL" instead of "BOGUS" or "USELESS". Unhelpful is a fairly subjective tag (*).

 

I use, in every language, hex-notation to signify bit-patterns. Ie. "int16(0x8000)" should be interpreted as bit-pattern 0x8000 in int16 storage (_ie. platform dependently interpreted as some 16 bit integer_). Obviously, C does not interpret it that way and never will - not a problem here.

 

The warning is very rare.

 

I have only a few of them from various macro-driven tests. Platform specific integer conversion ... the only place where anyone would write stuff like "int16(0x8000)". Hm, i should move the pragma there and undo it after the test section - much more sane. Thanks.

 

(*) I copy pasted thous few example lines out - leaving out some less likely useful ones (and commented out unused ones) and a few comments. One of them probably bited here. Pragma reminder-comment in split with "//": left of it is about the warning - to the right is for use-case reminders of how one might get the warning etc. So, BOGUS for "int16(0x8000)" does not mean the warning is bogus! - it signifies that it is UNHELPFUL as it is BOGUS for the use-case (the bit pattern fits nicely).

 

Perhaps i should have left out all the UNHELPFUL tagged ones here due of their high subjectivity.

0

Share this post


Link to post
Share on other sites


Maybe, but as the article says, it like saying "if blue is the sky" or "if tall is the man", it's just harder to read this way imo. Forgetting a '=' is not an excuse for writing harder to read code imo, since that doesn't happen very often.

It happens an awful lot more than you might expect. Defensive coding is important, and it often comes at a perceived cost to readability.

 

I'd honestly be rather alarmed to meet a senior engineer who didn't write their conditions that way, when coding in C++.

1

Share this post


Link to post
Share on other sites

 


#pragma warning(disable : 4127) // (UNHELPFUL) conditional expression is constant // this is actually almost always desired

 

It is? Isn't the conditional expression rather pointless if it is constant or am I missing something?

 

 

while(RUNNING == gameState)
{
  // Run Game Code
}
0

Share this post


Link to post
Share on other sites

Oh, missed a post.

 

 


#pragma warning(disable : 4127) // (UNHELPFUL) conditional expression is constant // this is actually almost always desired

 

It is? Isn't the conditional expression rather pointless if it is constant or am I missing something?

 

 

Typical direct example: "while(true) { ... }". But it usually comes indirectly from macros and templates (ie. stuff that is not, in its final, form written by the programmer).

 

Ie. the warning is valid, but unfortunately tends to flag code that is perfectly fine - which is just too annoying of a problem when one treats warnings as errors that could be temporarily ignored. Hence: UNHELPFUL.

0

Share this post


Link to post
Share on other sites
while(RUNNING == gameState)
{
  // Run Game Code
}

 

That's not a constant conditional expression, unless gameState is const, which I assume it is not...

 


But it usually comes indirectly from macros and templates (ie. stuff that is not, in its final, form written by the programmer).
Ie. the warning is valid, but unfortunately tends to flag code that is perfectly fine - which is just too annoying of a problem when one treats warnings as errors that could be temporarily ignored. Hence: UNHELPFUL.

 

Ah of course, got it.

0

Share this post


Link to post
Share on other sites

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
Sign in to follow this  
Followers 0