GAMING DEVELOPING AND WHERE TO BEGIN.

I learned Ruby in about an hour, but I already knew how to program in other languages. Editing existing scripts is easier to learn than making new scripts though, and menu systems aren't too hard, since the main things you're gonna be changing are just the locations of things on the screen rather than any real functionality. I'd guess that even with no programming experience, you can probably find a basic programming tutorial online and learn enough about Ruby programming to make a menu system in about two weeks, though the actual crafting of the menu system might take another couple weeks.

My experience with event-based battle systems is mostly that they are a gigantic MESS. Stuff is formatted in ways that make it a nightmare to track down what you've already done and figure out how you did it. There are also a few things you just cannot do properly with events, and there are a lot more things that you can do but they require duplicating the same code thousands of times, on every exit tile of every map, and then realizing six months later that it causes a bug if the player tries to crouch in the middle of jumping into the water, and so you have to track down and change each of those thousands and thousands of events instead of just changing it once. (That is an actual example from someone's game I played, but I'll keep their name private to be nice, since the author might not want me advertising their problems.) That example is an action battle system of course, but menu-based battle systems don't have any fewer problems. And anyway, more to the point, events just aren't designed for that sort of thing and so everything you do is going to be working against the system instead of using the tools it gives you. It's just... it's not a fun way to spend your afternoons.

Novices seem to think that the idea of finding bugs late in the game's development that you didn't catch when you were making the system is a semi-rare occurance. This is the opposite of the truth. Expect it to happen a few dozen times over the course of your game's development. That's just how it works: you're not a great programmer and you're gonna make mistakes. So having to go back and edit code in a thousand different places to fix each one of them is going to cost you a couple months of work, probably - especially if you account for the procrastination that will inevitably spring up when you realize that's what you have to do.

These days I tend to take other people's public-use scripts and edit them until they serve my needs, rather than making anything from scratch. It's not always less work than building my own scripts or making evented systems (which can work well for small things like damage), but it's still the fastest for me because I have a working starting point. Without which I tend to open up RPG Maker, stare at it for an hour, realize there's nothing there that I can work on, and then close it and decide to try again tomorrow.

I tried making all the graphics ahead of time. I really did. Then about 10% of the way through, as soon as I had enough to make most of the first dungeon, I quit and made the first dungeon.

author=Daria
Personally I'm making my entire game using RTP. IF I finish and IF it's good then I'll focus on replacing all the graphics (and recoding it in Java or C++).

I seriously wish I could give this a like or a +1 or something - too many people focus on the graphics and the other resources and not enough on the stuff they should: story, mechanics, balance. The rest of the game ends up suffering because they spend too much time making everything look shiny, but not enough time working out the kinks in the rest of the game. I'm not saying this is true in every case, but easily with 90-95% of the cases.

author=FlyingJester
because I only worry about codez and not graphicz.

Same here... I was worried about "graphics" once, but only about how to render them :D

I would absolutely build a prototype of the game with placeholders before any sort of graphics, story or anything else. This is my typical method and I prefer it because it is the quickest way to find out if your game is fun to play or not.

The exception to this rule would be a game where the graphics are heavily entwined with the basics of gameplay, or the game's enjoyability is dependent on creating a particular atmosphere. An common example are horror games, which try to create an extremely specific atmosphere that can be hard to reproduce with only placeholder graphics.

I suppose another exception to the rule would be a game with gameplay mechanics copied directly & exactly from another game; however in practice most of us hybridize our ideas between games that have influenced us, often across genres (which is a good thing), rather than copying a single game's gameplay 100%.

I like swapping as well. One thing I want to avoid is burning out on something. And you can't really burn out on something if you're waiting to work on a new feature while creating resources.

Also, if I don't make any resources for awhile, I tend to be very rusty.