   has anyone here actually finished a 2d rpg?
  i was just wondering.  how long did it take you?  did you do it alone?  ive done the pong thing and the tetris thing but i run into a lot of hitches when starting my 2d rpg... myabe your guys experiences can help:first off i always get stuck in a neverending loop of wondering and writing down what i will need and what i end up with is a billion pages of stuff that is all intertwined but so God awful confusing to look at that i figure there is a better way and try again.  go back to start.second i get stuck wondering what exactly a game loop looks like for an rpg considering that most rpgs have somewhat nonlinear play.  wait for input translate input check for battles special tiles etc but when a battle occurs you leave the loop entirely render screen etc... there just seems to be so much going on that it is ridiculous to keep track of.third i am also in a never ending loop of deciding what structures to use and how to implement them.  do i want a CEntity class and then players and NPC and monsters branch off of there?  do i use a linked list for rendering NPCs, or queues for deciding battle order, and how do i keep track of all the crap that is going on between a single rendering of a screen?im not shooting for FF3.  im shooting for dragon warrior .5.  it still seems like way too much going on for one person to do.  any input?  thanks. 
  A basic game loop for an rpg could be something like..-Update music.-Get Input-Check and Run current Game State-Check to see if any NPCs have been queued by pressing action near them and then handle the action request(open/update a textbox for instance)-Update Sprite list (read from the keyboard input, parse their command queue or execute their AI, check map/sprite collision, animate onscreen sprites and then finally move them to their new position on the map, after that do any sorting of the list if necessary).-Check If the player character qualifies for any scripted events  (i.e. he is standing on a special tile or something, or perhaps  its time to load a new map).-Update background(ex. scroll if the player has moved)-increment frame counterAdditionally you could update any particle requests if you happen to have a particle engine. Thats just a basic handler.The game state is just the current mode of execution, it changes based on the input.. so if the default walk around state is 0, and the player presses the menu button, switch the gamestate to 1 and handle the request by loading a menu, locking/hiding sprites, or what have you. The same principle could apply to accessing the battle engine.I find a doubly linked list to hold the sprites makes for efficient sorting(one pass of a brute force sort, swap as you go).As far as a sprite structure goes, I suggest you make a base sprite class that handles all logic associated with moving, animating and displaying a sprite on screen, then perhaps derive from that base to form classes that include your in game necessities like status or name. You could also use aggregation, or whatever.After that you can make a spritemanager class that loads in sprites and does all that Update stuff I was talking about earlier.As far as rendering goes.. just process all your game logic and then do your rendering after everything has been updated.  signature? -http://www.sarinsoft.net/rpg/ctdemo.zip    [edited by - Vinyl on February 17, 2004 12:10:18 AM];  Build your code incrementally. Stub-out your interfaces, and try to get the overall structure of your classes before you go ahead and write a bunch of code that may end up like spaghetti. When stubbing a function, include a few notes in comments within the empty function body, notes on what the function is intended to do, what conditions it expects, and so on. Stuff that comes out of your design, but it''s handier if it is there in comments when you go to actually write the function. Of course, you can''t write the entire application as stubs to start, but stubbing is a helpful trick that can help you to get the form of things, and possibly identify weakpoints in your design.Remember that there are a million and one ways to do any given thing, and there is no such thing as a "right" way for most tasks. Design a structure, flesh it out, and stick with it. Even if it turns out to have shortcomings and failures, it will still teach you valuable lessons on how to do it better the next time.Try to make use of re-useable components-- libraries to load images in various formats, wrapper classes around DirectX or OpenGL (whichever your poison); sound wrappers and so on. Things that you can develop and flesh out external to the development of your game core, and which can be re-used in any number of games.Try to identify common methodologies that keep cropping up, and abstract them for general-purpose use. An example from my personal set of base code is a templated management object called a RefCountList. It can be templated for any sort of resource (bitmap, game entity, sound effect, etc) and keeps track of a reference count for each entity, deleting the object when all references have been released. (Objects are not actually "deleted", using delete when released, but are returned to a collection, or pool, of unused objects; this avoids a lot of unnecessary allocation/deletion at run-time, and reduces memory fragmentation.) It is a common structure that I use extensively in the asset management portion of my games, so I abstracted it to a template and can easily instance a manager pool for any class or hierarchy of classes.Beware of going too in-depth with a design document, especially as a beginner. It is easy to waste a lot of time writing a complex design for a game you have no chance of completing at your current skill level. It is also easy to waste a great deal of time on a design which will seem insufficient or stale as the game progresses. As your experience grows, you will become more effective at fleshing out the document with the necessary information, and at organizing and structuring your design. You should design, of course, but as a beginner it may be pointless to include such information as "There will be exactly 537 types of weapons, including the Bladed Axe which does 3d6 points of damage, the Poisoned Long Knife which does 1d8 points of damage..." and so on. Odds are very good that your final Bladed Axe will be completely different than what you designed, due to game balancing, so spending a great deal of time specifying exact weapons, armor, and damages may be a bad idea.Instead, try to limit in-depth design to the underlying mechanics of your weapon system, such as how weapons are represented and what attributes they can have, and leave exact damages and attributes to the game content creation and balancing stages.Structure your game to accentuate your strengths and lessen the impact of your limitations. I personally have a great deal of difficulty in realistically modelling the human figure, getting the proportions right, getting the movement right, etc... Since I do my own graphics, I can not afford to spend endless hours practicing at modelling the human form--not if I expect to release Golem before I die of old age. So, I structured the premise of the game and the storyline to avoid having to display my weakness for the human figure. The story involves golems (animated statues, basically) moving about the world in the aftermath of a genocidal war that nearly wiped humans out. Since nobody can tell me my golem''s are incorrectly proportioned or animate strangely, I am saved.Now, corollary to this of course is that you should always try to identify your weaknesses and work on them, since constantly avoiding them or letting them spoil your ideas is counter-productive.Read up on software engineering, design processes, and design patterns. Although a lot of it is technical and/or theoretical, there are countless valuable nuggets of wisdom and technique to be found in the least likely places. A lot of the organizational problems of an RPG devolve to simple database management, or to structures which have been developed elsewhere to solve unrelated problems. Case in point: game object management. You need to build a system for handling the allocation and safe de-allocation of game entities. It can be simple to construct a hierarchy of game entities, deriving from a simple BasicObject class which provides a generic interface for common functionality. The object factory design pattern can come in handy for providing a mechanism whereby objects belonging to classes of this hierarchy can be allocated and managed. All allocations and deletions are handled through this factory, which can count references to objects if necessary, in order to avoid the dangling pointer problem of an object being deleted before another object is done with it.KISS: Keep It Simple, Stupid. (No, that''s not a personal attack.) When beginners set out to make an RPG, they set out to make the next Diablo 2, or the next Baldur''s Gate, or the next Neverwinter Nights, etc... Nevermind the fact that those games were made by teams of programmers, artists, and QA testers. That''s not to say that a solo developer can''t make a large, complex game; they can, given sufficient experience. However, if you try to tackle too much at first, it breeds discouragement. If you are ending up with "billions" of pages of stuff, you may be aiming too high. It takes practice and experience to be able to implement a system that complex.If/when a project gets too much for you, conduct a post-mortem on it. Analyze it to see where you got confused, where you went wrong, what should have been simpler. Keep a notebook of thoughts and ideas on what you did wrong and what you think you should do next time to make it write. If you prefer, this design notebook can be on your system, but I personally prefer actual paper and a real pen. It''s more intuitive for me to leaf through a dog-eared notebook, looking for that note on that idea I had, rather than scrolling through a file--but it''s your choice. Carry this notebook around with you, and don''t be afraid to open it up and write stuff down wherever you happen to be. Sometimes, ideas on how to handle a particular problem may occur while you are not at your computer; rather than let them slip away on the hopes you''ll remember later, write them down in your notebook.Check out the little code snippets, tips of the day, etc. here and at flipcode.com. Just take some time to read through them, not necessarily with any specific agenda in mind. It''s amazing how many little ideas you can pick up just browsing through--stuff that strikes you as interesting and which can go into your notebook for future reference. Don''t be afraid to shamelessly rip off the code in those tips--that is usually the author''s intent on posting them in the first place.Try to save time and effort by using existing third-party libraries for things. There a lot of libraries out there (many under the LGPL, so releasing your game as open-source is unnecessary) for things such as image loading, math (vectors, matrices, etc.), sound, embedded scripting, etc... learn them and use them, rather than trying to write them on your own.It can be helpful to base your game mechanics on existing systems, though you should be wary. Not only are many existing RPG systems overly complex (at least the P&P games), they may also come with licensing restrictions. But it can be helpful to have many of the formulae and calculations already determined, rather than to have to make them up on top of everything else.Above all, keep practicing and don''t let failure discourage you. I remember being exactly where you are right now. Just try to keep learning and experimenting, and you will come through.Good luckJosh GolemBlender--The Gimp--Python--Lua--SDLNethack--Crawl--ADOM--Angband--Dungeondweller