1
Zelda Projects / Re: [Startup Phase] Project GettoGohma
« on: April 21, 2015, 05:33:11 am »
Ohhhhhh, it's Get To Gohma. I kept reading it as Ghetto Gohma. >.>
Hello! New to the forum, etc etc, you know the drill. Could I ask the exact sprites that you would want made?Quick tip, since you're new: be careful when posting. This thread was almost two years old.
I dabble in sprite-making from time to time, and the original Zelda is pretty much one of my favorite games. I'd like to help, if possible. Thanks~!
Yes, C# does require memory management. While you aren't responsible for allocating, tracking and deallocating memory to the extent that you are in C, you still have to pay attention to the lifetime of your objects and be careful of how many and where you are allocating these. Garbage collector sweeps can be massive sources of performance problems in games....The problem with it was, I don't even know how to do that. What could I have been doing wrong? I couldn't find any tutorials on it at the time either. Basically the way I saw it was, it's not working as I'm programming it and C# apparently doesn't require memory management, so I'd rather use that and it work.
I'm not talking about improperly structuring your code, I'm talking about taking the dozen or so lines of code from Update and maybe mingling them into the same function as the dozen or so lines of code from Draw, for the sake of simplicity, instead of making a Game class.I'm sorry but yes, you are talking about improperly structuring the code. Right now, sure, the methods are only "a dozen or so lines." But believe it or not, games take more than a "dozen or so lines" to update, and more than a "dozen or so lines" to perform rendering logic. And if the advice to "stick everything in main()" were followed, eventually the code would be an absolute mess. Encapsulating game logic into its own class is a good practice - the only thing that should go into main should be logic necessary to initialize and clean up the game/application.
If that's bad practice, then fine, but please don't talk to me like thatIf the advice you offer is bad, I'm going to call you on it. Because otherwise, somebody's going to see that advice and think "oh, I'll just throw everything in main! I don't need to consider the fact that my code is going to expand later and become a maintenance nightmare!"
Someone told me that it might be lack of memory management and variables getting rewritten, or something. Idk. That frustrated me and made me quit.I'm sorry, because I'm about to sound like a bit of a !@#$%. If learning how to manage memory is "frustrating" enough to make you quit, then maybe you should find something else to do because programming clearly isn't going to be a great choice.
I, personally, would take advantage of the simplicity that SFML offers. I would drop the GameCore class and the Program.cs file tight butthole, and just use a simple int main() function to store all that stuff in. Not sure if this is good practice or not, but if you're cut loose from the ties of XNA, it'd be worth trying.No, it is not a good practice. In fact, it's a very, very bad one. Properly structuring your code is one of the most important things you can do if you want to actually be able to complete a project any more complex than "Hello, World!".
I run a mac with a Windows virtual machine, so it's hard to test smoothnessOriginally I wasn't going to say this, but now that you've said this:
What do you mean when you say "states"?Entities, objects, etc in a game benefit greatly from being represented as finite state machines. The gist of it is, something can exist in a number of "states", such as "walking", "falling", "jumping", "running", "dead", etc. Each state has its own rules for logic.
The Adult/Child Link Conundrum
This is one thing that's always bothered me. For aLttP you *can* have an adult link, but he always looks very strange. Link's Awakening however, there's no way to have an adult link. How do you solve this? Well simple- Think of Adult Link Hyrule as a new map; like the Dark World. There are differences in it that allow you to progress certain places you couldn't before. There's no need for crawly holes because in the future they could just simply *not be there*.
DOUBLE POST SORRY FOR BREAKING THE RULESNope, sorry, going to have to ban you.
draw all the empty hearts first(as in the total hearts say, 12)
then draw full hearts upto the current heart
finally, draw the final heart which could be quarter, half, three quarters, or full
I agree with this, though I think forking and pull requests aren't nearly as big an issue as dealing with branches, with regards to people who don't have the prior experience with source control. A better solution I think would be to make master your development branch an set up a separate branch for milestones or release candidates. The fewer steps people have to go through to get their hands on the materials they need, the better.The problem with the team was that we never had any dedicated programmers other than myself. I would love to get 1 or 2 more people on board with consistent coding. If others want to contribute to code, they may, but it has to be done on their own fork of the repo (this is basically what larger open source softwares do, Linux included).Quoteequally, the development branch should be the most important branch at the moment.
Correct, development is the ONLY branch that people from create their forks and branches from. Master is a stable release which is merged with development when releases are ready.
Here's another problem. Good coding standards are great and all, but trying to do this with the level of programming knowledge of most of the people that visit this site is going to heavily put people off contributing.
If you want to setup community projects, make them as simple to contribute to as possible, don't get into bs like forking source bases.