Jump to content

  • Log In with Google      Sign In   
  • Create Account

Master Thief

Member Since 01 Oct 2006
Offline Last Active Yesterday, 06:22 PM

Topics I've Started

Polymorphic uninvolved parenting?

02 April 2016 - 12:18 PM

My goal is to have a base class that deals with all the stuff that the Derived ones will have in common, but then allows each of the derived classes to implement their specific stuff on their own, without the Base knowing or caring about any of it, and still somehow be used in a polymorphic pointer. The derived classes are supposed to have distinct usefulness, so they'll have different functions altogether. One might deal with sprites, the other with text, etc, but, again, they do share some background/backstage functionalities.

Currently I'm declaring a pointer of type Base*, and defining it as type Derived*. And it works fine but only until I call one of Derived's specific functions. I get this error:

'class Base' has no member named 'function'.

I understand why that error occurs: I'm accessing a Derived through a Base pointer, and sure enough, Base knows nothing about that function because it was not declared in Base. That might be one solution, to declare it in Base, but that would then force me to also declare every other function specific to each derived class, in the Base class, and that's what I'd like to avoid.

Is there a way to achieve this?
Some (pseudo)code, illustrating what I'm doing and what I'd like to achieve (streamlined for simplicity, assume everything is public):

class Base
	virtual ~Base() =0;
	virtual void funk() =0;

	void common() {}		// deal with shared stuff

	// knows nothing about der1::draw() and der2::write()


class Der1 : public Base
	void funk() { ... }
	void draw();		// specific to this class


class Der2 : public Base
	void funk() { ... }

	void write(); 		// specific to this class


Base* ptr1;
Base* ptr2;

elsewhere.cpp - this is my actual goal

ptr1 = new Der1();
ptr2 = new Der2();


Wondering how to build a somewhat complex UI...

28 March 2016 - 07:35 AM

I'm trying to make the UI for resource management functionalities, which are also what makes up most of the game I planned to make. However, I'm a bit lost on how exactly to do it.


I'm not sure of all the stuff this will imply, but I could think of these:

  • A manager (the game class itself, probably, containing a stack of all the in-game screens)
  • A container (a screen, if you will, containing an amount of Panels (screen parts))
  • Panels (like viewports, in a way, containing any of the stuff below)
  • Buttons (multi-purpose, with a Sprite icon - much like the ones here above the forum post editing box)
  • Text Buttons (with a label - I wonder if they could double as clickable dialogue responses)
  • Text Boxes (NPC dialogue, item descriptions, story telling, etc)
  • Lists (containing non-clickable Text Buttons as indices (for stock items lists), or clickable Text Buttons (for dialogue choices), or even mini-panels (a third type of button) with a mix of elements (for example, an NPC list, and each index with a name and some stats and a mini-portrait))
  • Portraits (containing a large image of an character - to exist alongside/inside a player/NPC inspection panel)

Now, I don't really know if I can extend those functionalities like that (text button -> dialogue choice, etc). I don't know how to plan to implement all this, in terms of polymorphism and inheritance, interfaces, etc. I did this once in raw c++ in a console app, but I didn't finish it, so I never knew if it would work in the end.


I'm using c++/SFML now, but I'm more interested in understanding this conceptually (or in pseudocode). If I understand it in that way, I'll probably manage to implement it on my own.


What classes could I have and which could derive from which, and which could have versatile functionality, is what I'm trying to figure out. Also trying to figure out the way to repeat less code. Any help or suggestions or ideas, or whatever, would be greatly appreciated.

Need advice for user input parser for text adventure

27 September 2014 - 03:29 AM

This isn't the first time I'm doing this, but the first time it was simpler than what I intend now. My goal is to add a little bit of depth. My concern is mostly with how to handle this in the code, although I'm also struggling a bit to find a good way to describe objects and items in an external file, as well (not which format to use, just what elements to consider (name, ID, what variables, etc). So I guess my problem is twofold. 
A few examples of the input I would want to allow: (I'm using parentesis to mark irrelevant commands and commas to mark actual object names. Doing this only for clarity, the user wouldn't type type the markers. Also using slashes to separate equivalent commands.)
lock east door / lock "front door"                     (assuming "front door" is the one at the east)
cover east window (with) sheets / use sheets (on) "big window"
combine key (with) clay / use key (on) clay
(the object names, by the way, is what I thought could be used to distinguish two doors that might be in the same room, for example, as well as allow the player to refer to them by the name they see in the descriptive text of the area they're in)
I'm curious to know how people would go about doing such a thing. The last time I did it I ended up with an gigantic function with a switch() with many switch()'s inside it. I used arrays to separate and store the commands by categories (specials (quit, help, save...), verbs, directions, etc) and their short versions if available in subsequent dimentions, like this,...
string specials[3][7] = {
    {"exit", "quit", "help", "back", "save", "load", "\0"},
    {"----", "qqq" , "h"   , "bk"  , "----", "----", "\0"},
    {"\0"  , "\0"  , "\0"  , "\0"  , "\0"  , "\0"  , "\0"}

...and when I received input I'd compare them to find in which array the command was, and in which column.The column would be the criteria I'd handle in the big switch(). But I never went any further than to accept one command, because, like now, I was struggling to find a way to do it that made sense. My vision was that it would require at least one more huge switch() like the one I already had.

Considering the ammount of combinations, my guess is that I'll have to reduce whatever I get to a set of main commands, (i.e., "cover" and "combine" would evaluate to "use", "walk" to "go", etc.). Being that the case, I wonder if an enum would be of any use. I also wonder if my intermediary method with the arrays couldn't be superseeded by something else more handy.
That's the kind of thing I'm trying to figure out: the tools that are reasonably adequate for the job. Not how to code it, but what to code it with. I may come to simplify/streamline my goals, but I'll have to see what I can do before I make those decisions. Inform games had a pretty neat system for input, I wish I could see a source code for such an engine, because most of the open source games I found on google used choice menus... :|
Any help/insights/advice would be really apreciated. Thanks. 

Needing some quick tips on how to organize my code

15 March 2014 - 04:37 PM

I've been learning C++ from a book lately and I've been making something of a console game/thingy, and a map editor for it... Whatever it is I'm just coding and it's being fun and interesting, but I've coded it all in one file, both because I wasn't expecting to get so far with it, and because I don't know any better. At some point I moved all the declarations into a header file to make it easier to tweak things without as much hassle, but it's still being a huge hassle, it's becoming too much to cope with. I'm well over 2000 lines of code (on the map editor alone, including comments and garbage), and I'm finding it too confusing. An example of a side effect I found was that I was assigning values to the same variable from three different functions during the initialization. But I'm finding it hard to detect and fix stuff like this in all of this mess.


So I need to separate my code into more files, but I haven't learned anything about classes or even header files yet. I "know" what they are and what they're for, but I can't make them on my own yet. So what I need is a quick (and maybe dirty) way to just break up the code and make it bearable, because if I stop working on it I'll eventually lose motivation to keep learning. It doesn't matter if it's a cheap thing to do, the project isn't important, it's just a way to get my hands dirty and learn from mistakes. Like my father said once, analogously, your first car is for you to break.


So if anyone could give me some hints or thoughts on how to go about separating the code into more .cpp or .h files I'd really appreciate it. My biggest problem is with avoiding calling the same header file from several files, I think. But I also feel confused on things like, should I just create header files, should I just create cpp files, should I create both as needed, and how do I determine if they're needed, and how exactly do I make the code from one file interact with the code from the other...


Any help is greatly appreciated. Thanks.

In what ways can a text adventure have combat?

10 December 2013 - 11:38 AM

I've been planning a text adventure for a long time now, and combat is the part that's been giving me some trouble. I'm trying to avoid "dice rolls" in my game, which makes matters worse, and I don't know if I can actually avoid it.


To give you a better idea of what I'm trying to achieve, this is not your ordinary text adventure but rather a more... graphical one, with actual buttons and maps, inventory, item icons, etc, and I'm even considering having some sort of NPC graphics for encounters and dialogues. Otherwise every feedback the player gets is text as usual.


In essence, my goal with the combat system would be, ideally, to provide the player with a chance to be skillful at it. But... again, I'm a bit at a loss on how to do such a thing in this type of game. So for now I'm trying to figure out in what ways can a text based game have combat, so that I can take as much into consideration as I can, and hopefully come up with something. Or if someone has any great ideas I'd be happy with that too. :)


Any help or insights would be greatly appreciated.