Originally Posted by
pjpdev
Documentation is definitely important. And its one of my top priorities. But I still have to keep it somewhat simple to avoid the person using the lib from getting confused, and discouraged.
It's hard to say what's simple. IMO Andreaz's Phoenix lib is simple, but people who has never programmed a game before may not think so.
Is this lib meant to 'teach' newcomers how games are usually structured and then they can move one to something more advanced, or do you want people to keep on using the lib and therefore add more features to it? I would personally go for option #1.
I've assumed that it's for 2D games. Am I wrong?
You said that this should be the best tool for a new developer, and IMO such a tool would teach these aspiring game developers a good (not neccesarily the best way) and typical way to make a game. So for instant instead of loading an image, you load a sprite. You might as well teach them the proper terminology. They'll have to learn it sometime if they want to make games.
I've already pointed out that documentation and tutorials are a key to succes for this lib. If the developer is in doubt about something, he should be able to find the answer in the doc. This should also make it more simple to write your library.
Ok, that was a lot of jibberish (I'm tired and shouln't be replying to this thread 
Here's an idea from the top of my head as to how a game using your lib could be structured. Just to give you something to think about, and to get someone else to say it's a bad idea and then join this discussion 
Code:
uses Myclasses;
var
Game: TGame // So this basically creates a screen, runs the game loop and does the rendering etc.
IntroState, MenuState, GameState ... whatever: TState // So you would actually create a class for each state that inherits from the TState, where you will overload the update, input, render ect methods
begin
Game := TGame.Create(800,600,'MyFirstGame',false); //width, height, title, fullscreen . This is just some random example of how it could be done
IntroState := TIntroState.Create;
...
Game.AddState(IntroState);
Game.SetActiveState(IntroState);
Game.Start; //Starts the game loop - Game calls the active states render, update... methods
//Game returns when the game has finished
Game.Destroy; //It automagically destroys it's associated states or whatever you prefer
Code:
unit Myclasses;
type TIntroState = class(TState)
private...
public
procedure Update(double TimeStep);
procedure Render(...);
I suppose you get the idea. Not the best design I'm certain. As I said I just wrote it of my head, but using some OOD where the developers just have to inherit from some objects seems simple in my eyes. Others may disaggre so don't base your design solely on what I say
I may be able to write something more clever tomorrow when I'm not tired.
Btw. I do find this project interesting, so if you get it going I may be interested in contributing with some tutorials or something like that. I won some kind of help and manual writer program a while ago, so I might as well use it for something.
Reply With Quote
Bookmarks