Jump to content

  • Log In with Google      Sign In   
  • Create Account

Master Thief

Member Since 01 Oct 2006
Offline Last Active May 04 2016 06:22 PM

Posts I've Made

In Topic: Polymorphic uninvolved parenting?

04 April 2016 - 07:10 AM

a pointer to a base class is supposed to mean that you don't care what the derived type is

For example, if both "draw" and "write" actually just draw the thing, they should both be called just that (and not separate names for no reason)

In games generally the game objects do not draw themselves. (...) Game objects are generally worked on as a tree.

all UI elements should simply have Draw()/Paint()/Render()/Display() function which each subclass implements; whether its plain text, sprites, or a container of other elements, there is no need to have a different function name when the intention is the same - in each case, you are just trying to display the element for the user.

Good stuff to keep in mind. Thanks.

You could go the route of a text adventure game (plus GUI)

I am considering that. Perhaps I should just do it and get to work...

In Topic: Polymorphic uninvolved parenting?

03 April 2016 - 07:07 AM

Making these threads is useful for me to think about things, but it turns out this is leading me to a confusion about what I'm doing, but at the same helping me find the cause of the confusion. I made another thread before this one that also lead me to confusion (and I realize now it's not all that different from this one). It's no one else's fault but mine, really.


It think my confusion stems from the fact that I can't clearly visualize what I want while I'm not being able to prototype something. No matter how many drawing I make on paper. Perhaps I would benefit from explaining my actual goal in detail, and perhaps I could do it right here (hope it's ok). Maybe someone can tell me then if what I'm trying to do with the UI is overkill or not, or maybe if there's a better approach that I could take (considering I'm a beginner/intermediate programmer).


The project I'm trying to work on is intended to be essentially a resource management game, in a similar vein to the old Pizza Tycoon, but set in a medieval fantasy world where the player is an inn keeper. Aside from running the inn, the inn keeper can also trade/buy/sell information to travelers, adventurers, spies, etc (goblins robbing travelers in a road? The emperor planning to attack the northern towns?), and this is supposed to be one aspect in which the player could have an influence in the overall storyline (for example, there is a war, and if you trick a spy, you can potentially damage the enemy - or you could get murdered for it). The player can also hire spies and thieves for gathering more sensitive information, or even guards for protection, among others.


Since I found out I'm terrible at making sprite animations, I thought - for now at least - of leaving out the possibility to view the inside of the inn where one might contemplate the NPCs having a drink or eating a meal, and the view of the town, where one might see... something interesting and relevant that didn't cross my mind so far.


That leaves me with a game that is practically just a GUI, with a handful of buttons with which to alternate between each screen that, in turn, show the player information about his current patrons, the regular ones, allow him to study his acquaintances for potential strategies or just curiosity, check the stock/sales/recipes, the hired staff, the hired mercenaries/thieves/spies/etc, view all the money stuff, view character progression, etc. As of my current plans, the currently in-house costumers would be shown in a list (each with a small picture and a few icons to show their mood and other things, and also their known name, their current expenditure, if they rented any rooms, etc - just some quick info there) where the player could get into dialogues to make their acquaintance, but also get information about the outside world, and even see a sheet with the detailed (known) NPC information with hopefully a slightly bigger portrait.


I think I'm also divided between attempting to build a proper or a good-enough ui system, or attempting to customize each part of each screen as I go along and as I think of the stuff that could be shown there...


Here's a screenshot from my first attempt at this, somewhere in 2014, on windows console. There was no game content either, I just had managed to build the menu you see on the left. I was at that point going to attempt to build each of screens corresponding to a menu option. Hopefully it illustrates the amount of stuff I have planned to be able to display (some, like the Necrology and Animals options, aren't really in the plans, and I'm intending to streamline a lot of what's shown here).


In Topic: Polymorphic uninvolved parenting?

02 April 2016 - 12:58 PM

Just to make it clear, my intention is to create several parts of a UI, in which some parts deal with several lines of plain text, some are lists of information (several texts in each line), some show sprites, etc.


My intention is to have a class that manages the screen, storing each part in the same vector<> (or maybe map<>, not sure yet). My plan was to have that vector be vector<Base*> or something that would allow the managing class to easily access each part as needed, to pass on mouse/keyboard input, controlling focus/unfocus, selected/unselected, for drawing them in a for loop rather than risk forgetting some, etc, while each of them still knows how to display their own thing by themselves.


The functionality to draw a frame and background is common to them all, as are those I just mentioned above, but a list is going to have an addIndex() function, while a textBox won't. That addIndex() is as of now being called by the managing class (although, it just occurred to me that this might not be how I want it to be - perhaps the class should know when to add indexes by itself based on info from elsewhere, not by (arbitrary) request from the manager).

In Topic: Wondering how to build a somewhat complex UI...

01 April 2016 - 05:57 AM

I decided to go with something like this. It's similar to what I had done before.

Except I made Panel derive from sf::View instead (SFML View(port) class).

It seems to me this should work. We will see...


. 8h5Fvzi.jpg


(Greyed out items are just things I thought of, but don't know if I can implement or if I even need to)

In Topic: Is Programming an RTS Game still good?

31 March 2016 - 07:43 AM

To be honest, I'm thinking of buying it myself, from what I've read in the responses. I don't intend to ever build any game using DX, or using any platform specific code/lib, but the fact that it involves creating an RTS and terrain generation, and is being well spoken about, has got my mouth watering. I'm all for interesting reads on concepts I feel attracted to. :)


For me, specifically, I think it might be a good source of further knowledge that I might end up translating/incorporating into my actual projects (I don't think I'll be attempting to develop an RTS anytime soon). For you, well, I don't know. You could follow along using the old tools, and it should still work on any windows machine (that's my guess).


One thing to keep in mind is that once you're done you'll want to step up to more up-to-date technology, and that will involve further reading and learning, kind of like starting over, in a way. Might still be a lot easier than to follow along with the book while trying to translate it to its modern counterparts, which, as far as I know, involves not just using different keywords, but writing different code in a different mindset for different specific reasons.


Or you could still buy the book and read it on the side, as you focus on something else with some other book. To be honest, I can't really say what would be the best option, since the most important thing is that you're approaching the subject in a way that you really enjoy and keeps moving you forward. What I think I can say is that, from what it seems, you'll probably not be sorry to have bought it, regardless.