Jump to content

  • Log In with Google      Sign In   
  • Create Account

Khaiy

Member Since 27 Jan 2010
Offline Last Active Today, 08:41 PM

#5288669 Total Begginer needs lot of advice

Posted by Khaiy 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 Khaiy 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 Khaiy 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 Khaiy 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 Khaiy 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 Khaiy 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 Khaiy 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 Khaiy 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 Khaiy 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 Khaiy 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.




#5255751 Creating a World for a Text/Menu based Life Sim/RPG

Posted by Khaiy on 05 October 2015 - 08:58 PM

I don't know how much programming experience you have, but I'll suggest that before you start planning out a city and filling it with things you try a single room. Then implement some of the things you'd like to simulate, like interacting with another person in the room. After that add a second room, and implement the features that multiple rooms would require, like the ability to move between them, update a room while the player is not there, etc.

 

It's amazing how many design steps you can miss when you start with content in a type of program you haven't written before. I've been amazed by it in my own projects.

 

If you are going to stick with the design as you've laid it out (and for all I know you already have all the details planned for how everything will fit together), it may be better to use a more general Location class as Dragoncar suggested. But your needs and style will inform the specific design approach you use, and there is always more than one way to accomplish a programming task. The right way is a way that works, and you can refine things after the basics are running.




#5234795 Is it really as simple as read a book and then try to figure things out?

Posted by Khaiy on 14 June 2015 - 05:03 PM


I tried asking questions on other websites on what tools/books I should learn to get the job done, and I was asking for advice to see if there's a more efficient way to creating my game, such as if one language makes things more efficient.  (In terms of less bugs, runs faster or w.e else an educated person would know about.)

 

For a beginner, this question is basically meaningless. The sorts of issues you're describing just won't come up until you're far more experienced. For example, C++ has an internet reputation as one of the "faster" languages, and while that may be true in some circumstances you won't be dealing with a code scenario where that will come up for a long time, nor will you be able to take advantage of what C++ offers in that dimension. By far the best answer for someone starting out is what you describe-- you just need to pick one and get working.

 


Is game development really that simple as, I read a book on a language and I get straight to making my ideal game just like that?

 

It's that simple in the sense that coronary bypass surgery is just removing a clogged tube and replacing it with another tube. Actually doing it is harder than that description may suggest.

 


If I take peoples advice I might run into a problem that might make me scrap my whole game or remake everything all over again because of a single issue.

 

You might run into a crippling problem no matter what you do. If you could predict that sort of thing right now you wouldn't be a beginner. In ten years' time you might be able to make very good, nuanced choices about this sort of thing, but you'll develop that skill as a result of overcoming challenges between then and now. There is no path to programming games that is straightforward, easy, and has no risks of issues down the line.

 


Is it really a bad idea for me to post my game idea, then ask people what languages/tools they recommend I learn about to get the job done?
Because I asked this question on many sites and never had a single suggestion.

 

The real answer is the same as what you say you've gotten elsewhere-- it doesn't matter much what you choose, because most languages can do what you want. If you just have to have a specific answer before starting, then stick with Ruby because you already have some experience working with it. I promise you, any choice you make will still leave you with issues you didn't predict, and you will be able to address them.

 

 

As has been said above, it's easy for a beginner project to get out of hand in terms of complexity. Before diving into a multiplayer networked game, you may want to focus on something smaller. You could try coding a couple of sample characters, a couple of rooms/dungeon areas for them to explore, something like that. It's still plenty of work, but it's a realistic task and you can build on it for the future.

 

I also recommend not starting with your dream project because beginners are very likely to 1.) imagine something way beyond their ability to create right away, 2.) produce incomplete or problematic game designs which are very difficult to implement in code (whatever the language and tools being used), and 3.) focus on the "fun" game elements and neglect the utilitarian aspects of the program which must exist but are dull to create and debug. A smaller project that isn't as close to your heart will be easier to create, less frustrating, and ultimately bring you closer to what you'd like to accomplish.




#5234167 I get distracted with my other hobbies when watching video tutorials. [Read M...

Posted by Khaiy on 10 June 2015 - 05:37 PM

I only have a little to add to the above. Programming is a pretty attention-intensive activity, and if 20 minutes is the maximum amount of time you can focus on a tutorial video then you might be better off using written tutorials, even if you enjoy videos more.

 

Paying attention, for me, is always about will power; I don't know any tricks, you just have to make a firm decision to work and then stick to it. If your cursor starts drifting towards a link to a fun video while you're working, there's nothing to be done except to move the mouse away and get back to work. It might help to set specific project goals and then dedicate fixed amounts of time to working towards them. When I set aside exactly one hour of work time a day for programming, and don't allow myself to spend more or less time than that each session, I have a much easier time staying on task. My mind still wanders from time to time but it's easier to draw it back. No trick in the world will keep you engaged with a hobby that you don't enjoy.




#5226400 Now what?

Posted by Khaiy on 29 April 2015 - 07:14 PM


What i wanna know is if you guys think i know enough to start getting to know how to work with Slick2D and how to make games in it, or i have to learn more (maybe more than in that tutorial is) to get to that point.

 

It's hard for anyone to say how much skill you've developed just from a link to a tutorial you looked at for a week. It's also hard to say whether or not you're equipped to tackle a project of undefined scope.

 

It's really easy to underestimate the difficulty of a programming project-- and it's especially easy to underestimate what's involved in tasks you haven't successfully undertaken before. If your programming experience is one week's worth of following tutorials, that's going to be a long list even for a very simple game. For what my opinion is worth, if you are still looking exclusively for tutorials and have not completed an original project of your own (similar in scope to the 2D game you'd like to make, save for graphics) then making any 2D game might be too ambitious.

 

Are you dead set on making a 2D game, and no other type of project will do? Is there a particular style of game you're thinking of making, or a similar game you might be interested making a clone of? Answers to these will help figure out what might be a good project for you.




#5225320 Steam's compensated modding policy

Posted by Khaiy on 24 April 2015 - 02:42 PM


Valve are a retailer, and as such, they should be expected to care about the products they sell (Nb: I do believe the original developers are the ones who should care the most).  I'm sure Valve do not want to garner a reputation for selling poor quality mods any more than developers want to gain a reputation for allowing poor quality mods for their games.

 

They already have that issue, and address it through reviews from a huge user base. Steam has plenty of low-quality games, but it isn't known as "the place with the crappy games". User ratings go a long way towards persuading me whether or not to buy a game, and I imagine it won't be any different for mods. The best will rise and the worst will fall, and Steam will be known as a convenient way to access lots and lots of great mods.






PARTNERS