I am just starting working on a RPG. (Well actually, I have been working on it for 6 months, but I had to restart some time ago, using different technology). Anyway, I had just finished building a system to give monsters turns depending on there speed and that type of stuff, when I wanted to start working on the combat system. But for the combat system, I think I will need a HUD first, so I can debug the players HP and level and stuff, and I would need a HUD later anyway, so I thought I would do it right away. I wanted a message system similar to old games like nethack that you could read back from to see what happed in the past, and I thought I might need other off screen elements like inventory or a detailed examine/encyclopedia window later. I didn't want this to get all to complicated, so I decided to split the screen in 4 sections, that I call windows, one big one to show the screen, one for stats, one for log lines, and one for inventory. The problem was that all drawing and main stuff was handled by one class called "Isometric_Rendered", that also called the level generators "Generate Level", stored the level, kept track of all objects in the world (different from level in this case), passed all events on to the player object, managed when AI got turns, drew the debug log while loading to show progress of level generator, and a whole lot more stuff. Taking out the render world code and placing it in a "Window"class would be easy enough, but the renderer, of course, needs access to the level data. So I Thought I would build a world object that took out this part of the main classes responsibilities. But then, would every level have its own world object, or would there be one global world object, or should I just assume there is only one level as long as there is only one level, and worry about that part later when I actually have multiple levels?

So does anyone have any comments on the way I am doing this?

(I realize that this is a horrible run on paragraph rant, but if you don't like the post but have nothing to say about my problem, I would rather that you PM me then that you post about that, I know some people on this form who like to go around posts and complain about peoples grammar, but could those people just PM)

Ask if there is anything I can clarify.

The art is temporary, until by artist has time

I don't think you're overengineering.
Just a few remarks I'd keep in mind:

- make sure your classes don't multiple purposes, for example my rendererer class is only fed by either a bucket of buffers (index/vertex) with indices, or an object of my GUI class
- I'd make a separate GUI class containing your 4 windows, so you can pass the GUI object to the renderer
- a world class sounds fine if you ask me, maybe level woud be better like mentioned above. Depends though on your game, if you have a level which can have more worlds, then level would be better for example

If you have never made an RPG before, then yes, you are over-engineering. It is different if you've made these before and you know what you will need, but it sounds like this is your first attempt.

Here is one of the design mantras I always try to follow: By only adding the code that you need right now, you make it easier to change direction later. This is hard, only adding the code you need and keeping everything as simple as possible.

"I think I need a HUD first?" This is your first clue. You are making things you think you need, but may not. Time spent on this right now may be wasted effort.

Why do you need a message system to read back past events? To debug your combat system? But you don't have a combat system yet, so how can you know what you need to debug it?

You have everything in an "Isometric_Rendered" class. What is wrong with that? Don't just refactor stuff because you think the code "looks" bad. No one will ever see it anyway. Time spent moving things around without any positive gains is also wasted time. If you just add the dumbest code you can, eventually the design will appear. Blocks of code will look the same, and can be moved into their own functions and classes. Tools needed to debug current problems (not predicted problems) will need code changes to support the debugging. Eventually you'll have you game, and it will look nothing like your designs from the beginning.

Here is one of the design mantras I always try to follow: By only adding the code that you need right now, you make it easier to change direction later. This is hard, only adding the code you need and keeping everything as simple as possible.

THIS!

it becomes easier as you develop more coding discipline.

more sprigs of gamedev wisdom:

Time spent moving things around without any positive gains is also wasted time.

If you just add the dumbest code you can, eventually the design will appear.

Eventually you'll have your game, and it will look nothing like your designs from the beginning.