Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 27 Jan 2010
Offline Last Active Jul 19 2016 10:00 AM

#5296392 When you were starting out...

Posted by on 13 June 2016 - 04:06 PM

I don't have much to add to the above, but I agree that memorization is wildly overrated in programming (and most other fields as well). It's impressive to be able to rattle a variety of  complicated things off from memory, but memorization is hard, time-consuming, and in the end you only get marginally (at best) faster code entry into whatever you're working on. On the other hand, learning to look things up efficiently gives you prompt access to everything which can be looked up (which is pretty much everything there is).


Keeping a well-organized collection of references is much better than trying to memorize.

#5293283 Game Prices on Steam: should there be regulation/guidelines?

Posted by on 24 May 2016 - 07:07 PM

Since we mostly agree I don't want to spiral down into nitpicking. I'm definitely not saying that the Steam market is perfect (or even necessarily that good), or that there aren't real problems with race-to-the-bottom price competition, or anything to minimize the issues we're talking about. I'm really just saying three things, which you may or may not agree with to varying degrees:


1. Price controls are hard to get right, and getting them wrong doesn't necessarily result in a better situation than what you were trying to fix in the first place

2. The problems we are talking about are real, but likely have other solutions than price controls

3. Given (1) and (2) a price floor seems, to me, unlikely to be the best choice

#5292167 Game Prices on Steam: should there be regulation/guidelines?

Posted by on 17 May 2016 - 04:30 PM

How much does price influence your purchasing decisions when it comes to video games? I have two tracks that usually come in to play for me: I'm either looking for a specific game, or I'm looking to see if something catches my eye. In the former case a high price might persuade me not to buy it right now, and a sale or a low base price is a bonus. In the latter case I may or may not buy a given game but if I'm on the fence I'm more likely to click "buy" if the price is low. It's not necessarily a choice the dev has between a higher price or a lower price, it's a choice between making 1 sale or 0 sales.


With the really cheap games, in the $2 to $15 range for base prices, it's an information problem. Steam is flooded with games and unless it's one that has a lot of press I have no idea at all what I'll get out of any of them. If a dev (or publisher or whomever) wants me to buy a specific game they can persuade me that it's worth my money. It's hard for a game to differentiate itself well through the Steam platform alone, and that leaves price as the only thing to entice me. If there were a mandatory minimum price for games the main result, for me, would be that I would buy fewer of them.


Rather than an information-destroying policy like price floors I would rather see an approach that gives me more information about whether or not a game might be worth my buying it. Steam has tried a bit of this with their customer reviews, customized recommendations, curated game lists, and return policy. Maybe those aren't enough to avoid some Pyrrhic price competition but there will always be some games that flat-out aren't worth $X. Making it even harder to identify such a game could very easily reduce sales enough to offset the extra revenue from a higher price, leaving indie devs even worse off.

#5291053 How do I measure risk?

Posted by on 10 May 2016 - 05:48 PM

I had to take a project management course in graduate school and one of the things that was emphasized is that while most tools project managers use are not too complicated (including risk analysis), project management itself is currently heavily based around experience-- using knowledge gained in working one project to do a better job working the next. That may change as the field is still professionalizing and developing core standards and techniques but for now there is no real recipe approach.


I used this book, which was OK but not stellar (and the Kindle formatting was awful). It would be enough to get you started, and with a tool like Project Libre you should be able to be start working as your own project manager. There aren't any substitutes for experience though. At my last job my department was put under a new project manager fresh out of graduate school (for project management). Her lack of experience showed, both as the two projects she worked with us on unfolded and when they finished (unsuccessfully by any measure: budget, schedule, results). But the second project went better than the first, and I've no doubt that she's far better today.

#5289993 Time - the most important factor.

Posted by on 03 May 2016 - 07:58 PM

I agree with the posters above, but it's also a huge pain to debug software, make sure that a game is balanced, and ensure that it runs properly on different platforms. Even when a game is feature-complete it may not be ready for release. I've never made anything nearly as large, complex, or good as Stardew Valley. Because of that, and my observations between beginning programming and today, I accept that it took more work to create such a project than I am prepared to understand just by thinking of it.

#5288669 Total Begginer needs lot of advice

Posted by on 25 April 2016 - 03:58 PM

I know you said your mainly a C# programmer so I accept your going to be slightly biased here, but whats your thoughts on going with java? is the language capable of such things and run them smoothly and get a good end result? I dunno, im worried about what ever I learn handling the animation smoothly, (I have no foundations for such concerns but there ya go LOL) is java harder to code games and more to the point games like im looking to do point&click / visual novel....


If you are attracted to Java, regardless of the reason, then go with Java. It's more than capable of making the kinds of games that interest you and has a reputation (deserved, from what little I know of it) for being forgiving for beginners. As the posters above me said, if you later decide to learn another language it will be easier with Java under your belt, and that's especially the case for C# because they have so many similarities. Don't let the choice between C#/Java stress you out at all-- either will do everything you need them to do.

#5288495 Total Begginer needs lot of advice

Posted by on 24 April 2016 - 03:04 PM

although you say a VN is doable pretty early on you also say and I quote


"It is not a good project for introducing yourself to the language or to coding more generally."


could you expand on this??? why is this? because there isn't a lot of stuff involved in such a venture and I would be missing out on lots of important aspects? if this is the case would my plan to do lots of small games like pong and the like be a good idea before I went actually doing the VN thing to experience in other areas?


Sure. There are things you need to learn about programming to make anything at all, things like syntax, variable types, design ideas, etc. There are a lot of them and they are kind of fussy to learn but they really matter. Small projects, on the scale of tech demos, are good for learning these things and gaining an understanding of how they work. When people want to make a game, they generally have in mind something that will require some higher-order knowledge which doesn't depend much on the language you're using, like how to work with game states, transition between scenes, handle input, and on and on. You need the earlier programming knowledge to be able to build those higher-order systems, and especially to build them well. It doesn't work very well to jumble the order around.


Anything you're thinking of as a game you want to make is almost certainly beyond your skills as a beginner (this is true of everyone, not just you) and it will likely be frustrating to work on it right away. Learn the language a bit first, then start building specific components of a project that is a radically scaled down version of what you ultimately want. So developing some C# skills first (if you choose C#), then learning how to make a text-only story in a console window, then adding a player input piece, then making a larger story with player choices sounds like a reasonable sequence to me. And one that will help keep you from getting ahead of yourself. After that you can dive into bigger topics like how the game code should be structured (game states, saving and loading progress, etc.), graphics (with SFML or whatever you decide to use), and other topics that will lead to the game you are imagining.


That's the same reason I'm recommending point-and-click for later-- you'll have to cover the same material as you would need for a VN, plus more. There's no reason not to build up to it. Pong is a fine project, but you won't learn much from it that you can apply to the game types you are interested in that you won't learn from a VN. I suggest a progression that starts with making a very small, simple VN, and then expanding on it rather than moving to a similarly large, complex project that has little to do with what you want.


It's generally true of programming, and especially for beginners, that a project is bigger and harder and more complicated than you predict it will be and the only realistic measure of whether or not you can do something is whether or not you've already done it.

#5288481 Total Begginer needs lot of advice

Posted by on 24 April 2016 - 12:58 PM

Visual novels are among the easier types of game to program, largely because they are more "on rails" in terms of design and are less complicated than other games. I think that it is absolutely an achievable goal for a first "major" project, by which I mean I think that you can make a VN rather than Pong or something similar. It is not a good project for introducing yourself to the language or to coding more generally.


Point-and-click isn't that much harder but I would still recommend the VN first, as you've planned. Point-and-click can be an expansion on the skeleton you develop for a VN.


I think that Unity is overkill for that specific type of game, although it will do what you want if you choose to use it. From what you listed as your goals, I think that C# along with SFML would be a good route. Java would also be fine, I just happen to like C# more

#5286028 Question about health bars

Posted by on 09 April 2016 - 10:31 AM

Oh so the class that actually handles the rendering elements... Lol sorry should have payed a bit more attention the first time. So I don't necessarily have to make a separate class for my healthbar? I just kind of assumed it would be inefficient not to.


It may be a good idea to have a separate class define a HealthBar object, if only to define its on-screen dimensions and location and store the sprites that will be drawn. The instances of HealthBar can be instantiated anywhere that makes sense for your code, updated with player health values when your game logic updates, and then rendered along with everything else in the render loop.


Other design approaches exist which will work, but I think that HealthBar objects will be easier to work with both conceptually and for code maintenance. Again, efficiency (in terms of code performance) in this case will probably not matter much.


Thank you for your help, by the way!


Happy to help! I hope my suggestions are of some use to yo.

#5286022 Question about health bars

Posted by on 09 April 2016 - 10:07 AM


Why can't you have the health bar as a member variable in your Player class, rendered above/around your characters? You can still have a separate HealthBar class with its own sprites and render method. I doubt that any approach you take to implementing health bars could be inefficient enough to matter.


EDIT: I checked out your other thread, and now I understand what you're describing. In the same code that displays your other HUD/UI elements you can include instances of a HealthBar class (or whatever other approach you want to take). It will need to take information from your Player instances anyways, to show each player's current health, and at the same time you can pass information on the characters' onscreen locations to render the health bars in the right locations. You don't need a class to be static for it to provide information to other classes.

So  I should render the health bar itself in the same class where I have the instances of my player objects? 



It depends on the structure of your code, but probably not. Your Player instances will be in some class (maybe Game, or something like that), and another class which is responsible for rendering UI/HUD elements on screen will exist elsewhere. Data does need to pass from other objects to the object that does the rendering but they don't have to both be members of the same containing class for that to happen.

#5286018 Question about health bars

Posted by on 09 April 2016 - 09:41 AM

EDIT: I checked out your other thread, and now I understand what you're describing. You don't need a class to be static for it to provide information to other classes. In the same code that displays your other HUD/UI elements you can include instances of a HealthBar class (or whatever other approach you want to take). It will need to take information from your Player instances anyways, to show each player's current health, and at the same time you can pass information on the characters' onscreen locations to render the health bars in the right locations. Do you currently have a specific class for rendering things on the screen?

#5277989 best way to write clean code

Posted by on 24 February 2016 - 08:31 PM

Here are some tips that have helped me, in no particular order:


1. Refactor. When I write code to do something I haven't implemented before, it's just about always a mess. That's doubly true if I'm writing the system the code will fit into for the first time as well. I have to force myself to do it, but I do try to set time aside specifically to refactor code I've already written-- not writing anything new, just cleaning and streamlining what I have already written.


2. Use a pseudocode approach to writing. Before writing any code, write comments the describe each step of what your code will do and then fill the actual code in around them. It helps me for planning, and good comments make it much, much easier to revisit code later. Especially for code you intend to reuse someday but aren't sure when.


3. Keep your code as modular as possible. When you're focusing on avoiding coupling pieces of code together it's easier to keep things neat.

#5274551 SFML Cannot get sprite rect to change

Posted by on 05 February 2016 - 05:43 PM

C++ isn't my strength, but I don't see anywhere where you update the position of the rectangle on the sprite sheet. I'm assuming that you intend to do that in your moveTextureRect functions, where you update the Player's position but then set the textureRect for playerSprite with the playerRect object, which never changes.

#5270608 Good Choices for a first game?

Posted by on 11 January 2016 - 04:59 PM

I'm always a fan of basic (linear) dungeon crawlers, text based with menu style actions rather than an input parser. Though, if your problem in the past has been with finishing projects it might be better to go with kseh's suggestion of Blackjack where feature creep will be less likely.

#5257425 I got the basics of c#.. I need help implementing the code.

Posted by on 15 October 2015 - 10:15 PM

I think you are on the right track, but might be overdoing it on creating classes.


For the menu situation, a common approach is to have a high-level class called "Game" or something similar with a member variable to represent the game's state, called, say,  "State". The game state would be represented by a class with public methods for whatever data needs to be passed from the state to Game, along the lines of a Draw() method that renders things onto the screen. So you have an instance of State called MainMenu, which has the code for the start button, and when the player clicks on that button the Game class (or another class, depending on your design) swaps out the MainMenu state for the next state (maybe "Playing", or whatever). The Game class keeps working along in the same way, for example calling currentState.Draw(), and your current state handles itself.


For input you see something similar. You have a class that receives input by listening for key presses, mouse clicks, reads the mouse cursor position, and so on, with switch statements, sets of if-else statements, or some more exotic arrangement. This class would also be a member of a high-level class, like Game. That input then gets passed into whatever the current state is, and logic inside of the state class' definition decides what to do with it. In general you probably won't want a lot of classes for this but instead have specific classes implement logic so that they have the behaviors you want.


For example, say your input listener notes that the D key is pressed, and passes along that information to currentState. If currentState == MainMenu, and the main menu doesn't respond to the D key, then nothing happens. If currentState == Playing, and the D key moves the player to the right, then the state passes the key press on to the PlayerCharacter object. The PlayerCharacter object then responds, maybe by checking if moving to the right is valid and if so, updating the PlayerCharacter's currentPosition variable accordingly as well as setting the PlayerCharacter's own state variable to "movingRight". Code within PlayerCharacter notes that movingRight == true, and implements the animation for moving to the right for as long as that is the case.


I hope that got at your question and makes sense.