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

Can you do this with a class instance?

13 posts in this topic

Hi guys,
 
I have created a renderer framework with an instance called mRenderer.
 
I have a huge amount of calls to mRenderer in my application. For example;
 
mRenderer->dothis();
mRenderer->dothat();
mRenderer->etc();

Is there any way to have the application 'assume' that mRenderer is constantly going to be called and just have this instead? Something similar to namespaces?
 
dothis();
dothat();
etc();

Any suggestions would be awesome cool.png Edited by lonewolff
0

Share this post


Link to post
Share on other sites
#define dothis() mRenderer->dothis()

Is this a good idea ? Hmmm, I'm not a big fan of meta-languages...

Edited by Ashaman73
0

Share this post


Link to post
Share on other sites

#define dothis() mRenderer->dothis()
Is this a good idea ? Hmmm, I'm not a big fan of meta-languages...


Thanks for the reply.

I can see how this could get tedious setting up defines for every function.

I guess using that method you would also have to setup macro's for anything that requires a parameter, right?
0

Share this post


Link to post
Share on other sites

You could take a look at http://en.wikipedia.org/wiki/Fluent_interface
 
Instead of returning void the methods would return Renderer* (or possibly Renderer&) and you can chain calls like this:



mRenderer->dothis()
    ->dothat()
    ->etc();

That is an interesting concept. I have never seen that done before.

Although, a lot of my call return values for either error codes or calculations.
0

Share this post


Link to post
Share on other sites

Paradoxically the thread title involves part of the 'answer'.

Yes, you can (sort of) do that with a class instance.

This is available in a few languages as a built in feature and is called 'With statement' : http://www.freepascal.org/docs-html/ref/refsu58.html

In C++ you can use a quite genius but very nasty trick that you can wrap in a macro:

http://stackoverflow.com/questions/2279180/does-c-have-with-keyword-like-pascal

That'll most likely confuse many programmers who never seen that in Pascal (or in any language with 'with' keyword).

It also doesn't let you use any local variables, unlike real with.

Edited by FRex
1

Share this post


Link to post
Share on other sites
As ApochPiQ points out, trying to use an object many times in a row to accomplish a task is a code smell.

It can be a symptom of several problems. It can be a symptom that your code is written for micromanagement; you wrote tiny tasks rather than big tasks. His solution is to consolidate the work into bigger tasks.

In addition to micromanagement smells, it could be a symptom of a god class, of a SRP violation, feature envy, trivial modules, primitive obsession, or several other problems.

Each of those problems has its own set of different solutions.

Or, it might just happen that you need to do a series of operations on an object as a matter of course, which is no problem at all. In that case, you just use the object and manipulate it as you need. If retyping the name bothers you, rename the variable to something shorter. The compiler doesn't care what it is named; the object's address will be loaded to a register and reused each time without any penalty or anything.
0

Share this post


Link to post
Share on other sites

Or, it might just happen that you need to do a series of operations on an object as a matter of course, which is no problem at all. In that case, you just use the object and manipulate it as you need. If retyping the name bothers you, rename the variable to something shorter. The compiler doesn't care what it is named; the object's address will be loaded to a register and reused each time without any penalty or anything.


It is more a case of the above I think.

For example my renderer has separate functions for position, rotate, scale, and a lot more.

I could do this all in one call but then on the other hand it would be silly to set all paramters if I only wanted to reposition x & y.
0

Share this post


Link to post
Share on other sites
This is what I'd consider a great opportunity for reorganization. As a possible suggestion, what if you had a simple SetTransform() on your renderer that takes a standard 4x4 matrix, and then a library of free functions for composing transformation matrices from various components?
0

Share this post


Link to post
Share on other sites
If it's purely because of readability, you can consider making an auto &.. based on the mRenderer object and give it a name with one character. Then it would be: r->dothis() etc, keeping the original object's name untouched and clear to understand.

Personally I would keep it like you have right now and try bundling functions that you often call in "pairs" (like some said above)
0

Share this post


Link to post
Share on other sites

Some of the things programmers do to "tidy up code" or "reduce typing" are an absolute nightmare.

 

Some people call it "job security measures" because no fecker in the world can understand the code when you have finished with it.

 

Hell I saw one block of code where the programmer had redefined + - * / to be complex functions. 

 

A += B              just added the two values together and stored it in A

A = A + B          created a matrix based on B, multiplied A by it converted the results to a vector normalised it and stored it in A

 

How the hell was I supposed to read the code?

 

Just don't do it unless you have a really, really good reason for it.

Edited by Stainless
0

Share this post


Link to post
Share on other sites

Just don't do it unless you have a really, really good reason for it.


Don't conflate obfuscation with simplification. Good simplifications make code easier to read, not harder.
1

Share this post


Link to post
Share on other sites

 

Just don't do it unless you have a really, really good reason for it.


Don't conflate obfuscation with simplification. Good simplifications make code easier to read, not harder.

 

And bad ones obfuscate the code smile.png

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