RPG Style Simple Text Menu

[archentity]

Looking for a simple text menu like the ones in 2D Final Fantasy games to put into your SFML game??

I have been looking around for a very simple, easy to use rpg style text menu that C++ beginners will have no problem understanding. For some reason it appears no one makes these using SFML or this is such a noob thing that advanced programmers don't even give it a second thought, let alone make a class for it. So this is what I did.

Warning: I am a noob, so keep this in mind. I've spent weeks trying to make this class work and I have also sent every function through rigorous testing so there shouldn't be any problems with the code. The code is also heavily littered with comments and the functions have self explanatory names.

The menu class's declarations (Menu.h) and its definitions (Menu.cpp) are attached to this post. When using these make sure you have the header files that the class asks for.

A brief explanation of how it works

Basically the menu consists of 4 main things:

- a container deque (basically an array that can change size while the program is running like vectors can except they are slightly different) that holds every option in the menu.

- another container deque that holds a list of pointers that only point to the options that are supposed to be drawn to the screen.

- an sf::Rectangle object that works as the background for the menu

- an sf::Rectangle object that works as the border for the menu



I think most of it should be easy to figure out how to use, especially with the comments. BUT if anyone has any questions, problems, or bug reports, just send make a reply to this post or send me an email at www.archentitykalim@gmail.com to let me know. I'm kinda busy right now but I will eventually make a full on tutorial for this if need be.

UPDATE!!! ATTACHMENT FILES HAVE ALSO BEEN UPDATED SO RE-DOWNLOAD THOSE IF YOU ALREADY DOWNLOADED THEM!!!

I added some extra functions to the class that you probably won't have to use but they are there just in case. These functions are:

- int getCurrentOption(); --- Returns the number of the current option.

- std::string getCurrentOptionString(); --- Returns the text string of the current option.

- std::string getFirstOptionString(); --- Returns the text string of the first option.

- int getLastOption(); --- Returns the number of the last option.

- std::string getLastOptionString(); --- Returns the text string of the last option.

- std::string getOptionString(int number); --- Returns the string of the chosen option.






 

[The Terminator]

Instead of pasting all of the code into one thread, have a look at creating a repository at websites such as https://github.com/

[archentity]

Instead of pasting all of the code into one thread, have a look at creating a repository at websites such as https://github.com/

Sure, I'll look into it. Just out of curiosity, did you use the code? If you did, did it work okay for you?

[The Terminator]

Instead of pasting all of the code into one thread, have a look at creating a repository at websites such as https://github.com/

Just out of curiosity, did you use the code? If you did, did it work okay for you?

I didn't, mainly because I already have a similar system in my engine but it's good work regardless.

[archentity]

Instead of pasting all of the code into one thread, have a look at creating a repository at websites such as https://github.com/

Just out of curiosity, did you use the code? If you did, did it work okay for you?

I didn't, mainly because I already have a similar system in my engine but it's good work regardless.

Cool, thanks

[ChronicRat]

Some moments (in random order).

1.Use STL containers by reference.
Bad:

void Menu::changeOption(int Number, std::string NewName)

Good:

void Menu::changeOption(int Number, const std::string& NewName)

2. Use logic. =) And arrays started from zero.
Bad:

if(Number > 0 && Number <= Option.size() && Option.size() > 0)

Not bad: (size_t is unsigned, so it can't be less than zero)

if( (size_t) Number < Option.size())

3. Use correct types and prefix form of ++:
Bad:

for(int v = 0; v < Option.size(); v++)

Good:

for(size_t v = 0; v < Option.size(); ++v)

Very bad:

std::string Menu::getOptionString(int number)
{
        if(Option.size() > 0)
        {
                std::string h = Option[number - 1].Text.getString();

                return h;
        }

        return false; <----  :o

}

Not so bad:

const std::string& Menu::getOptionString(size_t n)
{
        assert(n < Option.size());
        return Option[n].Text.getString();
}

And there are many many more pretty things to refactoring. You have to read this book http://www.gotw.ca/publications/c++cs.htm

[The Terminator]

I've got some more suggestions:

In your constructor, use initialization lists: http://www.cprogramming.com/tutorial/initialization-lists-c++.html

When looping through your STL containers, use iterators versus array indices: http://stackoverflow.com/questions/131241/why-use-iterators-instead-of-array-indices

I think it's good that you're providing sufficient documentation, but there is such a thing as too much . On lines like this:

// Update the menu.
updateMenu();

It's good that you provide relevant names to your methods, so such comments aren't necessary because you can tell exactly what it's going to do.

Also, prefer smart pointers to raw pointers as they utilize RAII: http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization

std::deque is not the appropriate container to use, especially since you are searching through them using array indices which is a slow operation. Prefer std::vector because it is inexpensive and efficient to search through.

VisibleOption[v] = NULL;

NULL is a deprecated C-style way of declaring a null pointer constant, and could sometimes yield undefined behavior. Prefer nullptr, which is the C++ way of doing the same thing without the risk.

I sorta searched quickly through your code, but I hope you find this useful!

[FRex]

NULL is a deprecated C-style way of declaring a null pointer constant, and could sometimes yield undefined behavior. Prefer nullptr, which is the C++ way of doing the same thing without the risk.

It's not, it should not be used but there is no need to go on NULL hunt in fear of code being undefined on different setup. In c++ NULL is 0, but it's not typesafe at all. I used 0x0 (because hex instantly makes me think of pointers) before 11, tried to never use NULL, now I use nullptr. NULL can only result in wrong function getting called but that's not 'undefined' by itself.

void hehe(int hehecount);
void hehe(Hehe * hehe);

hehe(NULL); //totally the right thing happens here

but at least GCC is smart about it.

hehe.cpp: In function 'int main()':
hehe.cpp:17:10: warning: passing NULL to non-pointer argument 1 of 'void hehe(int)' [-Wconversion-null]
 hehe(NULL);
 

http://www.stroustrup.com/bs_faq2.html#null

From c++11 draft (emphasis mine):

18.2
1 Table 30 describes the header <cstddef>.
//table was here, it contained NULL among other things
2 The contents are the same as the Standard C library header <stddef.h>, with the following changes:
3 The macro NULL is an implementation-defined C++ null pointer constant in this International Standard (4.10).

4.10.1
A null pointer constant is an integral constant expression (5.19) prvalue of integer type that evaluates to zero or a prvalue of type std::nullptr_t. A null pointer constant can /* lots of stuff about how conversions to pointers from null constants work were here*/

[ChronicRat]

When looping through your STL containers, use iterators versus array indices

Not always. =)

[Nexus]

When looping through your STL containers, use iterators versus array indices

not always. =)

But mostly.

[ChronicRat]

But mostly.

I did almost the same test a year ago. I compared wxArray and std::vector. Results are the same, but in wxWidgets iterators are much faster than and index and STL iterators. Of course, there is no need to use wxWidgets because of its containers only. But in wxWidgets based application - iterators are winners without questions.

And one more thing to TS:

// Deconstructor.
        ~Menu();

It's destructor. =)

[AFS]

Use correct types and prefix form of ++:
Bad:

for(int v = 0; v < Option.size(); v++)

Good:

for(size_t v = 0; v < Option.size(); ++v)

May I ask why using pre-increment is preferred?

[ChronicRat]

Well, i think that is a matter of taste. =) But i read somewhere three or four year ago, may be in "C++ Coding Standards" by Herb Sutter...

[zsbzsb]

http://stackoverflow.com/questions/24853/what-is-the-difference-between-i-and-i

...But in this situation is makes no difference.