:o
In an RPG, you’re going to want to run automated simulations to test play balance. Hardwiring dependencies on graphics classes in your game logic is going to make that sort of thing that much harder. You don’t have to be an Architecture Astronaut to follow some basic sanity guidelines.
Still, the lesson Cas is teaching is that you shouldn’t start with heavy abstraction – his libraries were factored out of existing code, so they’d already proven themselves useful.
Acctually fun topic… I think there are 2 “types” of game programmers: one, who acctually just want to create a game, and some, who really want to create something, they can create games for 10 years with. Just have to say: CodyBunny’s Rabbit engine? 
By example, when i wrote a game (always little games because i havent’ sufficient commitment alone) i wrote because i love to develop.
It’s a game because all the days i work on business application and want to add more fun when it’s at home. But i don’t do a game for the game itself.
I really think that this spirit is the ** bad way **, because i lost often some objectives and disgress often quickly and for too long time.
The functionnal end-result should be always the main objective but i can’t work like it.
I think I enjoy programming toolsets/libraries/engines more than the games themselves…
Recently I’ve started making mini-games and demos alongside library/toolset development – it helps me focus on productivity/practicality rather than thinking too much about “abstraction” and “OO wank,” as Cas calls it.
[quote]Pro tip: do all the title screen, menus, and options first, before you start the game.
[/quote]
Heh, that’s my favourite part, and generally after spending way too much time polishing a menu, I have no more motivation left to program the game itself… 
For a big RPG, IMO one of the most important aspects is having a lot of game content. This means quests, items, areas, entity types, and more quests and items. A world editor would be pretty essential.
Someone said “big RPG” is a bit vague, and I agree; so here’s some details.
First of all, I’m not one of those idiots who go, “I’m gonna make the BIGGEST, BADDEST MMORPG EVAR!!1!”, this is just a project I’m doing for STLP next year. I want to show all of those idiots who use Game Maker what a real programming language can do. lol.
Anyway, the game is essentially revolving around dungeon exploration that is randomly generated, in which take place in the players mind. (Imagine orthographic LSD dream emulator).
When he’s not dreaming, he’s going about his normal life and facing psychological problems.
So really, the game goes from:
Apartment Room
City
Dreams
and every one excluding the dreams need to have quick ways to add different events to each without making the engine ugly.
How should I organize it? Especially the game loop itself. I was thinking: Input, Logic, Draw for the loop, but I want your opinions. Also, should I make different classes for each game state, or have one core game state that loads different maps?
Thanks for the input guys, it’s really helpful.
I may also be considering adding multiplayer co-op, seeing as I can just send the Seed for the dungeons to each player and just have an entity list sync. Which shouldn’t be too hard in theory, but please feel free to enlighten me.
Well, if you design it before you code it, you’ll probably end up changing the design when you’re coding…
Keep rendering and logic separate. Generally stay away from the Static key word. Your Game loop is just like any other game loop ever superb. You’ll be fine.
This is by no means an advice, but this is how I code:
- ensure enough sleep (mandatory)
- make a short term plan
- make a mess
- make it work, GOTO 2 or 5
- refactor until OK code quality, GOTO 2
- make it public (optional) GOTO 2
- call it beta & redirect stdout, stderr to your server
- make it faster to the point where players stop complaining (optional)
- make money (unlikely, unless dayjob)
Like Cas said, patterns and structure will emerge, don’t force them in your code. Common sense helps, a design pattern here and there, sure, so point #3 should a temporary state, 1 day tops, or it will rot and emit unpleasant fumes. I can’t stress enough how important a proper amount of sleep is: developing is 80% debugging*, and with enough sleep, you write fewer bugs, find the remaining ones faster, etc.
* a guesstimate, it might as well be over 90%.
I completely agree. There have been numerous instances where I’ve rage quit and gone to bed because I couldn’t fix a problem…only to have a EUREKA!! moment as soon as I woke up 
Rage quiting is only tolerable in PHP. :cranky:
my EUREKA time becomes often in the bathroom…
O_o are you saying that you spend most of your time in the bathroom or the…peculiar environment of the bathroom causes your mind to go on overdrive? :o
A multiplayer architecture should definitely planned from the very beginning. Adding it later means writing a new game from scratch.
Implementing a good real time multiplayer mode I would call one of the hardest tasks of all.
Lately I find game development is 90% playtesting and then twiddling something to try and make it more fun 
I am so utterly sick of the sight of Ultratron. Two solid months so far on a game that looks like it took two days to make. I have no talent whatsoever.
Cas
After deliberating for 2 pages, not a single rule about this was fixed~
Static data is bad. Static functions with no side effects are good.
Btw, interesting read: http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/
Overgeneralization is bad.
I use static data all over the place. Win!
Cas
Yeah, I wanted to be a super programmer so I never used statics. Then I got lazy and now I use a few static classes/data when appropriate. There’s really no reason for me not to use a few static classes/data for my own shitty small games 
However, in bigger projects methodologically cutting the static data use gives super cool superpowers and actually cuts debugging time tremendously. (I’ve no first hand experience of this but I think it’s true, it makes sense).
I gave up on avoiding statics. Its just easier to get the job done. And its not difficult to read. If the use case changes, it is not hard to change.