Jump to content

  • Log In with Google      Sign In   
  • Create Account

Master Thief

Member Since 01 Oct 2006
Offline Last Active Aug 09 2016 03:00 PM

Posts I've Made

In Topic: How do I finish my first game with few hours to code but a lot of free time?

12 July 2016 - 09:35 PM

I use the Haxe language and HaxeFlixel as the engine, you may have never heard of.


Papers Please was coded in Haxe, though with openFL (formerly known as NME). I used Haxe once, and I liked it. It's a pretty smooth language, and development went quite fast for me (compiling too). I just quit it because I'm developing for desktops and (at the time) there were a few limitations that made a bit of a difference to me.


I can't really help with the main issue, but I just wanted to mention that I know from experience that violent video games actually do a bit of what I like to call the "punching bag effect" (release tensions, stress, anger, etc - and some games made me have an even greater distaste for wars in the real world!). Unfortunately, that I know of, there doesn't seem to be any studies corroborating that notion, but there are studies showing quite some other benefits from playing games in general, but maybe you already know all that.


I have some relatives (my aunt, for one) with similar opinions to your grandma's, but since they never really imposed them on me I never really argued either, so I'm a bit clueless about that... But if I had to, I might do it by, instead of arguing, trying to just ask questions, such as why exactly does she think games are whatever she says they are, and where did she get that idea from, and aren't crime rates lowering, and does she think puzzle games are bad too, and what about racing games (or whatever else you play), etc.


With carefully chosen questions you may end up leading her to realize that her opinion is unfounded and that she actually doesn't know much about games in the first place, and if she realizes that by herself, in the privacy of her own thoughts, she may eventually cut you some slack (people often admit their flaws/mistakes much more easily if they're doing it within themselves, without feeling the pressure of external scrutiny or anything that may make them feel attacked or unwilling to give in).


Although, if that's ever to work, you shouldn't expect it to be in the foreseeable future. It will depend on lots of factors pertaining to her personality that only you can consider and what questions you ask and how, but, who knows, may be worth the effort sometime. Essentially, try to leave something in the air that will make her think.


That said, if you get better results by doing things your own way, then forget everything I just said and go for it. Just see if you don't dig yourself a deeper hole by arguing too much like I used to. :)

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)