Another Game Dev Library...

[pjpdev]

I recently got this idea to create a new Game Development library. The entire idea is using SDL, OpenGL and OpenAL for its core. The library is should be a simplification of the core objects. The idea is still in its pen and paper phase, and I'm just sharing my ideas. I'm trying to make something that is the perfect tool for a new developer with little programming experience.

A few ideas I have:
- Use a class as an application definition, similar to VCL/LCL form creation.
- Try to make it compatible with both Lazarus and Delphi.
- Functions and procedures with simple names such as "LoadImage(src: String)"

I know its not much, but your ideas are welcome.

Also I'm planning on licensing it under the LGPL, and host in SourceForge.net. If anyone is interested in working on this, please send me an email.

[pstudio]

If you're targeting beginners I would suggest you to spend a lot of your resources on documentation. Write a complete documentation and give some tutorials that covers all (most) of the library's functionality.
I don't know how much functionality you plan to add, but I would value documentation higher than functionality you don't need in every game since this is for less experienced programmers.

[pjpdev]

If you're targeting beginners I would suggest you to spend a lot of your resources on documentation. Write a complete documentation and give some tutorials that covers all (most) of the library's functionality.
I don't know how much functionality you plan to add, but I would value documentation higher than functionality you don't need in every game since this is for less experienced programmers.


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.

[pstudio]

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 :D



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




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.

[pjpdev]

Thanks a lot pstudio... This will certainly help very much. A 2D lib is propably the best place to start. A newbie can use this lib to get his feet wet, and when he feels ready he can move in deeper and use more advanced libs out there.

Another great idea that I have is to give the developer a template to work from. This template will have a basic framework, which makes it a bit easier. Kinda like creating an application in Delphi or Lazarus, which sets up a basic framework:



//Automaticaly Generated...
type
TMyGame1 = class(TMyGame)
private

public

end;

var
MyGame1: TMyGame1;


There are still a few kinks in this system that I have to sort out. Through innovation it shall happen. This lib is also pretty much nameless, I can't think of something catchy and original, I'll propably think of something cool as this project moves forward.

Furthermore, I'll toy around and see what I can come up with.

[paul_nicholls]

Thanks a lot pstudio... This will certainly help very much. A 2D lib is propably the best place to start. A newbie can use this lib to get his feet wet, and when he feels ready he can move in deeper and use more advanced libs out there.

Another great idea that I have is to give the developer a template to work from. This template will have a basic framework, which makes it a bit easier. Kinda like creating an application in Delphi or Lazarus, which sets up a basic framework:



//Automaticaly Generated...
type
TMyGame1 = class(TMyGame)
private

public

end;

var
MyGame1: TMyGame1;


There are still a few kinks in this system that I have to sort out. Through innovation it shall happen. This lib is also pretty much nameless, I can't think of something catchy and original, I'll propably think of something cool as this project moves forward.

Furthermore, I'll toy around and see what I can come up with.


Hi :)
Having a template class that you can inherit from is exactly the same thing that I have done for my personal 'game libs' I have done.

So I think you are on the right track :-)

cheers,
Paul

[pstudio]

Thanks a lot pstudio... This will certainly help very much. A 2D lib is propably the best place to start. A newbie can use this lib to get his feet wet, and when he feels ready he can move in deeper and use more advanced libs out there.

Another great idea that I have is to give the developer a template to work from. This template will have a basic framework, which makes it a bit easier. Kinda like creating an application in Delphi or Lazarus, which sets up a basic framework:



//Automaticaly Generated...
type
TMyGame1 = class(TMyGame)
private

public

end;

var
MyGame1: TMyGame1;


There are still a few kinks in this system that I have to sort out. Through innovation it shall happen. This lib is also pretty much nameless, I can't think of something catchy and original, I'll propably think of something cool as this project moves forward.

Furthermore, I'll toy around and see what I can come up with.

I would actually advice you to take a look at XNA. It's really easy to use IMO. You don't have to copy XNA but maybe you can find some ideas on how to structure your lib. For instance XNA gives you a template to work with just like you suggested.

About the name. You can always just show your big ego to everyone and name it after yourself. PJPLib :P :D

[User137]

Game := TGame.Create(800,600,'MyFirstGame',false); //width, height, title,
...
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


This caught my eye. Using .Destroy calls in main program is bad habit ::)
Delphi help says: "Do not call Destroy directly. Call Free instead. Free verifies that the object reference is not nil before calling Destroy."

[pstudio]

Game := TGame.Create(800,600,'MyFirstGame',false); //width, height, title,
...
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


This caught my eye. Using .Destroy calls in main program is bad habit ::)
Delphi help says: "Do not call Destroy directly. Call Free instead. Free verifies that the object reference is not nil before calling Destroy."

I know. ;)
I usually use freeandnil myself. As I sad it was just a bad example on how the lib could work. :P

[pjpdev]

This caught my eye. Using .Destroy calls in main program is bad habit ::)
Delphi help says: "Do not call Destroy directly. Call Free instead. Free verifies that the object reference is not nil before calling Destroy."


I would have called .Destroy ::), but now I know that calling free is a more effective way.

I think the name PJPlib will do it, it also holds reference to PJP Dev. Which is in the first place an egoist name... ;D

And as more ideas roll in actual development can begin soon...

[pstudio]

This caught my eye. Using .Destroy calls in main program is bad habit ::)
Delphi help says: "Do not call Destroy directly. Call Free instead. Free verifies that the object reference is not nil before calling Destroy."


I would have called .Destroy ::), but now I know that calling free is a more effective way.

Well I don't think it's more effective. On contrary it may just be a little less effective. As the help says, Free checks that the object reference isn't nil and then calls Destroy. So I suppose Free just looks something like this (perhaps a bit more advanced code)

if Object <> nil then
Object.Destroy;

[User137]

Sidetracking with offtopic .Destroy a little... I would just say that calling it while object does not exists gives the Access Violation error which many think quite nasty even in testing phase. .Free avoids that, though then your real issue in program may be harder to track... go figure :P I have always used .Free only.



I recently got this idea to create a new Game Development library. The entire idea is using SDL, OpenGL and OpenAL for its core. The library is should be a simplification of the core objects. The idea is still in its pen and paper phase, and I'm just sharing my ideas. I'm trying to make something that is the perfect tool for a new developer with little programming experience.

A few ideas I have:
- Use a class as an application definition, similar to VCL/LCL form creation.
- Try to make it compatible with both Lazarus and Delphi.
- Functions and procedures with simple names such as "LoadImage(src: String)"

I know its not much, but your ideas are welcome.
Good luck with project, though the compatibility part may be problem. Is that really what you want to use time to, because there are lots of language and library differences with Delphi and Freepascal based code. Personally i'd like to have some Freepascal based OpenGL engine which i roughly tried to learn but quitted. (in the lack of everything and oversized exes, i could be wrong)

[pjpdev]

Good luck with project, though the compatibility part may be problem. Is that really what you want to use time to, because there are lots of language and library differences with Delphi and Freepascal based code. Personally i'd like to have some Freepascal based OpenGL engine which i roughly tried to learn but quitted. (in the lack of everything and oversized exes, i could be wrong)


I have more experience with Delphi than Lazarus, and I still use it more. For starters I'll develop the lib on Delphi, and at a later stage maybe port it to FPC.

Another thing on my mind is the sound API... I have two choices - FMOD 3 or OpenAL... ???
Which one is the best? Personally I like FMOD a lot, it would be the ideal candidate for the lib's sound core... I haven't tried OpenAL yet, and maybe I should sometime.

Anyway its time to get back to work on this... :P

[paul_nicholls]

Hi pjpdev,
With regards to compatibility between Delphi and Freepacal/Lazarus, I would try to make it work in both from the beginning to make it easier for you later on. Then it can be used in both :-)

It shouldn't be too hard to do (as long as you don't use VCL/LCL controls, etc. but just use 'template' classes and similar.

Good luck :)

cheers,
Paul

[noeska]

Do try openal: http://www.noeska.com/doal .

[pjpdev]

Hi pjpdev,
With regards to compatibility between Delphi and Freepacal/Lazarus, I would try to make it work in both from the beginning to make it easier for you later on. Then it can be used in both :-)

It shouldn't be too hard to do (as long as you don't use VCL/LCL controls, etc. but just use 'template' classes and similar.


I'm not going to use VCL/LCL, so I should do it this way. This also gives me a greater oppurtunity to make it cross-platform as well.



Do try openal: http://www.noeska.com/doal .


I'll definitely have a look at it. Thanks...

[WILL]

You know there may be a way to do both VCL and LCL. Though you'd have to properly and smartly separate your LCL from your VCL stuff using {IFDEF Delphi} and {IFDEF Lazarus} clauses.

One of the biggest attractions to the old DelphiX library was that it was a part of the RAD tool bar hence easier for those used to only the app development to get into making games using visual components. I would note that I don't think anyone has made such a set of visual components for Lazarus yet... Just a though. :)

[pjpdev]

You know there may be a way to do both VCL and LCL. Though you'd have to properly and smartly separate your LCL from your VCL stuff using {IFDEF Delphi} and {IFDEF Lazarus} clauses.

One of the biggest attractions to the old DelphiX library was that it was a part of the RAD tool bar hence easier for those used to only the app development to get into making games using visual components. I would note that I don't think anyone has made such a set of visual components for Lazarus yet... Just a though. :)


Come to think of it, me neither. It is a great idea... :yes:

But... :o

The only problem of doing it like this is the fact that Lazarus needs to rebuild itself in order to install new components. This might be confusing to new developers ???. I don't know if we can find a way around this... If you know of anything, please let me know.

[pjpdev]

Well well... I can finally begin with the development of PJPlib... You can keep track of my progress in the following post - http://www.pascalgamedevelopment.com/forum/index.php?topic=5720.0 or on the official PJP Dev forums - http://forum.pjpdev.co.za

Thanks for all the advice I got in this post, it helped a lot guys. You're always welcome to make comments on the new posts. :P