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

Master thief

Members
  • Content count

    58
  • Joined

  • Last visited

Community Reputation

350 Neutral

About Master thief

  • Rank
    Member

Personal Information

  • Location
    Portugal
  1.   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. :)
  2. I'm following this article in order to understand noise algorithms, and I'm still only half way through it, so I'm still doing the simpler stuff. As I'm doing this I'm trying to translate what I learn into my intended application of it: terrain generation for a platformer (I can't find any useful tutorials for this...). However, I don't know if I'm doing this right, and there's also a few things I'm getting confused about. I figured if I got the output values of the noise functions between 0 and 1, and then multiply that output by the height of the map (which is for now the same size as the screen (768px)), it could work. I can use that to know where each tile goes. I figured if I later have a bigger map I can lower this value to something sensible like, say, a 5th of the map's height. Am I on the right track here? It does seem to work. Kind of... The results from the red noise function are quite appealing (with 50 smoothing passes).   But the results from the violet one always go near the top of the screen/map and I don't know if that's natural behavior or a flaw in what I'm doing. I figure it's the latter since I'm not being able to display them any lower by playing with the numbers. The tiles at the bottom are actually wrapping around the top cells, which is why the red lines aren't connecting to them. I'm also confused about whether the output should include negative values (-1 to 1). The article author uses them here and there without even flinching. But I'm not sure how to account for that. I'm not using any, but the rough() function (below) naturally gives me some. If I converted those negative values to positive, I end up taming the violet function, but only slightly. And the tiles are still near the top. Here are the functions as I made them (in python (pySFML)):   # In the Noise class... # I stripped these functions of class specific stuff, # like 'self.' and '@classmethod', for readability def red(n, seed = 0, lmin = 0, lmax = 99, avg = 0.5, passes = 1): random.seed(seed) points = [] for i in xrange(n): points.append(random.randint(lmin, lmax)*0.01) # smooths the values return smooth(points, avg, passes) def violet(n, seed = 0, lmin = 0, lmax = 99, avg = 0.5, passes = 1): random.seed(seed) points = [] for i in xrange(n): points.append(random.randint(lmin, lmax)*0.01) # roughs the values return rough(points, avg, passes) def smooth(noise, avg, passes): if passes > 0: output = [] for i in xrange(len(noise)): if i is not len(noise)-1: output.append( avg * (noise[i] + noise[i+1]) ) else: # Average of the last value and the first output.append( avg * (noise[i] + noise[0]) ) return smooth(output, avg, passes-1) else: return noise def rough(noise, avg, passes): if passes > 0: output = [] for i in xrange(len(noise)): if i is not len(noise)-1: output.append( avg * (noise[i] - noise[i+1]) ) else: # Diference between the last value and the first output.append( avg * (noise[i] - noise[0]) ) return s.rough(output, avg, passes-1) else: return noise # and in the World class # I use 's.' instead of 'self.', by the way def genNoise(s): numPoints = s.numCellsX*s.tsize # s.tsize = tile size (16px) s.points = Noise.red (numPoints, 0, 0, 100, 0.5, 50) # s.points = Noise.violet(numPoints, 0, 0, 100, 0.5, 3) def placeTiles(s): for i in xrange(len(s.points)): p = s.points[i] tileX = int(i%s.csize) # s.csize = cell size (16 tiles) tileY = int(((p*s.mh)/s.tsize)%s.csize) # s.mw/s.mh = map width/height (1280x768) cellX = int((i%s.mw)/s.csize) cellY = int(((p*s.mh)/s.tsize)/s.csize) s.cells[cellX][cellY].tiles[tileX][tileY].show() s.cells[cellX][cellY].hasTiles = True
  3. Good stuff to keep in mind. Thanks.   I am considering that. Perhaps I should just do it and get to work...
  4. 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).
  5. 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).
  6. 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): base.h class Base { virtual ~Base() =0; virtual void funk() =0; void common() {} // deal with shared stuff // knows nothing about der1::draw() and der2::write() }; der1.h class Der1 : public Base { void funk() { ... } void draw(); // specific to this class }; der2.h class Der2 : public Base { void funk() { ... } void write(); // specific to this class }; elsewhere.h Base* ptr1; Base* ptr2; elsewhere.cpp - this is my actual goal ptr1 = new Der1(); ptr2 = new Der2(); ptr1->draw(); ptr2->write();
  7. 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...   .   (Greyed out items are just things I thought of, but don't know if I can implement or if I even need to)
  8. 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.
  9. I have been writing short stories for some ten years, and I still can't write a decent one in 3 seconds, figuratively speaking or not. In fact, I have yet to finish one...         If you're at that skill level, then you'd probably do better with programming. RPG Maker takes a lot of time to get stuff done too, and it imposes many limitations that you'll likely want to program your way around anyway. To me one of the biggest repellent aspects of RPG Maker games (and the reason why I don't find them visually appealing since VX came around) is the square unnatural looking tiles (you can literally tell which games are made with RPGM). Tiles used to be made to not look like tiles, i don't know what went through their minds... RPG Maker kinda died with XP for me. Still, in terms of playing the games, well, I only ever found less than a handful of interesting ones, so... as far as I'm concerned you're chances aren't that great. I don't even play games on a phone anyway, and I have a hard time understanding people who do.   Either way, I do see what you're saying. You could very well throw out some half assed game and see what happened. You could potentially bombard sites with Happy Flocks... and see if any bird would poop some money your way. If your game costs 5 and you sell 200, you got yourself 1000. Doesn't sound that hard, does it? I think you need to get lucky though. Your game will still take some time and effort to make, and there's a good chance it gets stifled in the noisy market. If you're just thinking about the money, you might go broke.   I've never released a game, but I would assume it's like diving into a pool to impress a girl: if you're greedy and don't care to check what you're doing, the pool might be empty.
  10. Sorry to say, but I really do not recommend that book. I found it slightly sloppy and a bit inconsistent in several ways... One example that stuck with me is that the author claims the book is not for the absolute beginner, and indeed he does some advanced witchery with little or no explanation sometimes, yet later on he went to surprising lengths to explain how the Y axis is inverted in computers... Go figure.   I had trouble learning SDL. Mostly because at the time I couldn't find any proper tutorials. Maybe there weren't any... Lazy Foo's seemed alright, but they didn't teach you much more than just SDL. It didn't teach me how to properly organize the code in separate files either (which that book actually kinda did). That, in my opinion is a great red flag. I would think there's a good chance a beginner who's tackling SDL has already been through the frustrating experience of having 3000+ lines of code in one file...   I really don't know if it was SDL, Lazy Foo, or just me. I just couldn't go forward with it. I tried Allegro later on and I found it comprehensible enough that I did quite some progress. And more recently I started tackling SFML and I'm happier with it every day. So I dunno...   I'd say, by all means, try SDL and try Lazy Foo. If you find yourself struggling much, then try to find tutorials that focus mainly on making a game... with SDL (personally, I would try this right away, but LF's tutorials might have improved - I wouldn't know, it's been a while for me). If that still doesn't work, then perhaps try another library. Don't get too attached to anything, and don't condition yourself to follow a strict path. At this point the smartest thing you could do is really to just go with whatever works.
  11.   Indeed. As some programmer (on youtube) once said: "A programmer is, in essence, a problem solver".   Although, if that's the problem, quitting might still not be the choice he should make, yet. He might want to tackle game making software first.
  12. While looking for that I stumbled upon this (about FF7's engine): http://q-gears.sourceforge.net/gears.pdf   It seems they made the menus modularly (page 56). Sadly it doesn't explain the window system used by each module. 
  13. Callbacks is something that's still rather advanced for me. Though I've already read a few things about them, I might end up using them.   Do you know of any JRPG tutorials that implement menus? I had never noticed before, but it seems most of them neglect to teach that. I'd like to take a peek at their implementation.
  14. It really comes down to what your heart is saying. Your heart always tells the truth. And remember, it's your heart, so you should heed its words. In the real world you only get one life to do that, and you can't save your progress or start over and try different endings. So let your heart speak louder until it stifles the outside noise.   Let it point its figurative finger in the most desired direction.   Look in that direction, see what's on the horizon. It's never the edge of a cliff, and it's usually a long and irregular, yet beautiful path.   Simply start walking. Don't look back.
  15. When I was starting I found pure (text) Roguelikes to be quite accessible, as well as Text Adventures (never found a decent tutorial for these, though), as well as adventure Myst-like games, if you have the skills for graphics, or if you like taking photos for the scenery.   Still, some nice choices would be Pong, Arkanoid, Space Invaders, Tetris, Snake, Pacman, Super Mario, 1942/43. It's worth noting that these games get often suggested for learning, not because they're renown titles or challenging to make, but because they all entail a number of important concepts that you'll need to learn in order to make any game you want to make.   Flash games sometimes bring up great simple ideas, like 2D Shooters (those you control a crosshair and shoot things) and simple puzzle games and top-down stealth/shooting games.   There are some games that look simple but in reality (or as far as I can tell) are quite more complex, such as Worms and Lemmings.