The future of Pascal as language for games

[SilverWarior]

and as you maybe noticed that embarcadero and borland previously Focused on database all times , so the name 'delphi' has been associated with databse domain rather than games

Yes I did noticed that and infact I can't understand this policy.
I can understand back in day Borland focused a lot on databases mostly becouse of their BDE (Borland Database Engine). The main advantage of BDE was ability to work with various types of databases raging from old DOS databases like paradox to all the newest and all this with exactly the same framework. If my memory serves me corect BDE was the only tool back in day to provide that and SQL was stil in development.
But today when we talk about databases we always talk about SQL. Why? SQL is similar to what BDE was back in days with the main difference that it is cros-language and cros-platform compatible. Lets face it nowadays rarely anybody works directly with databases all other use SQL for that.
Yes through out the years Borland and now Embarcadero did developed a lot of standalone programs for working and managing the databases but I still doesn't understand why they focus so much about databases.

I do have to admit that some of the focus has ben turned to FireMonkey lately wich should alow developing application for multiple platforms but still the main focus is on databases. You can even see this by the fact that whole FireMonkey platform focuses on data binding.

And as I'm mentioning FireMonkey here I might share some of my expiriences with it.
The core idea for FireMonkey is good but I'm afraid that its implementation isn't. If you intend to use it for game development I recomed you to stay away, atleast for now. Why? FireMonkey's performace is quite bad.
Having quite simple form with several controls on it and you are already down to les than 30 FPS especialy if you use any special effects that FireMonkey provides.
The special effects that FireMonkey provides also aren't much.
The worst part is how controls works. For instace if you have a form with three trackbars wich are used to determine rotation of some 3D object wich is being drawn by FireMonkey you could expect horible performance (verry laggy). Why? Becouse for some reason FireMonkey seems to be queing events fired by your interaction with FireMonkey-s controls. So for instance when you move trackbar left for three units three events would get qued. And FireMonkey will first rotate your object based of first qued event, than on second qued event, and then on third qued event. And if this 3D object of yours is atleast a bit compex could take even a second for FireMonkey to finish all three events.
If you ask me FireMonkey-s controls should check their imputs only after redrawing phase and not que any events just as games graphical engines does.

[AirPas]

I still doesn't understand why they focus so much about databases

because it is the most requested in the market

[FelipeFS]

It is comforting to see that there are people who realize the potential of the Pascal language.
This post renewed my courage to go ahead, not only with my game engine, but with the IDE I'm doing for Free Pascal.

Thank you very much, guys!

[phibermon]

I believe that for commercial game development, pascal will one day be a viable choice in the financial sence but that won't happen until there are sufficiently advanced cross platform capable libraries to choose from. And for pascal to be an attractive option for increasingly larger game budgets, it's often preferable within the industry to license engines and libraries that don't require them to reveal their code assets due to various open source licenses.

Now indie development is a totally different matter, we already see FPC compiled games released for IOS and people are making great headway with Android framework designs that can make efficient use of OpenGL. Win/OSX/Lin are all sorted and to top it all off there's a myriad of other supported operating systems as an added bonus.

The best thing that could happen at this stage is for one engine to rule them all, and in the darkness bind them. An engine that does so much for you, that it's just a pain in the ass to consider anything else. I think projects like GLScene are pretty close to that idea and I've seen some impressive engines here in the forums but it's like they've spent their experience points in different stats, and nobody has reached level 60 yet.
*edit* me included. *shame*

[LP]

I believe that for commercial game development, pascal will one day be a viable choice in the financial sence but that won't happen until there are sufficiently advanced cross platform capable libraries to choose from. [....] The best thing that could happen at this stage is for one engine to rule them all, and in the darkness bind them. An engine that does so much for you, that it's just a pain in the ass to consider anything else. I think projects like GLScene are pretty close to that idea and I've seen some impressive engines here in the forums but it's like they've spent their experience points in different stats, and nobody has reached level 60 yet.

These two statements assume that everyone in the game development industry uses third-party engines for creating games. By this logic, I guess we all should forget programming and software development beyond anything trivial and start using Unity3D from now on... On the other hand, I think you don't need any third-party engines to make even the largest game project, which in this sense is no different than any other software project out there. Therefore, the existence of third-party engines and libraries do benefit the game development community, but they are not essential to consider Delphi and FPC/Lazarus as viable platforms for commercial development.

[czar]

You can make commercially successful games without spending massive of amounts of money. Take Angry Birds, written in LUA. The hard part coming up with a brilliant idea and pulling it off with style.

[deathshadow]

I've gotten the "Pascal is dead" asshattery a good deal the past few years... usually they'll point at this ancient article filled with half truths and outdated information as their justification -- they'll call the language 'useless for doing anything' or "inferior to C dialect for getting to the hardware" when that's total 100% grade A farm fresh MANURE!

... and I love rubbing their noses in the sheer number of programs written in Pascal they are probably using and don't even realize it!

Avant? (the IE wrapping browser?) Asus Power4Gear? ThinkSQL? Pixel? GBXEmu? FLStudio? PC Tools Spyware Doctor? Inno Setup? CambridgeCAD? MSI Afterburner? MediaMonkey? PE Explorer? MyCORSA? AVS? BitZapper? IMGBurn? Daring Apprentice? Space Rangers 2? All of CoffeeCup's software?

... and that's the little stuff... How about Partition Magic? MagicISO? CloneCD? IcoFX? Spybot Search & Destroy? ADAWARE?!? WINRAR?!?

How about this one: SKYPE?!?

All those software packages? Written in Delphi... or Lazarus+FPC when there's a cross-platform version. Modern Object Pascal being used to build modern applications... Quite often for multiple platforms at once!

It goes back to something I've been saying for years, the only thing holding Pascal back was a lack of a decent cross platform compiler. Delphi was a good start to keeping Pascal modern by tossing Visual programming on top of it, but FPC+Lazarus takes that cross platform. There's really little you can do in C or C++ that a modern Pascal compiler like Delphi or FPC can't do.

Well, other than write needlessly and pointlessly cryptic code with a half assed object implementation. C++ really excels at that -- hardly surprising since we all know that C and Unix are a hoax.

But as I've said a million or so times the past 30 years, I'd sooner hand assemble 8k of Z80 machine language than try to find a bug in 100 lines of C code.

I swear that C and it's derivatives exists for the sole purpose of perpetuating the idea that programming is difficult -- it isn't... Assembly is simpler than C! It is an ugly, half-assed language that I cannot fathom the desire to use.

But to keep that in perspective, I say the same thing about HTML 5.

[Eric]

You can make commercially successful games without spending massive of amounts of money. Take Angry Birds, written in LUA. The hard part coming up with a brilliant idea and pulling it off with style.

Definitely.

A good idea isn't enough, you also need good style, good execution and good marketing/buzz.

The game mechanics of Angry Birds f.i. were not invented by Angry Birds, there have been quite a few (more or less experimental) predecessors, and where Angry Birds succeeded was in:
- having cutesy characters that "scaled" well in the real-world and had enough fun/appeal (ie. good stylistic ideas, predecessors were unimaginative bomb or rock throwing)
- great execution on churning out levels and themes to keep the trend going (most predecessors had neither the polish nor the quantity)
- great marketing (viral buzz "the way it has to be done")

Overall I would say the code and engine are the simplest and cheapest part in terms of man/hours.

[WILL]

You can make commercially successful games without spending massive of amounts of money. Take Angry Birds, written in LUA. The hard part coming up with a brilliant idea and pulling it off with style.

I would also add that having a talented artist in your pocket doesn't hurt either. Nice looking assets can make all the difference from looking amateurish to professional or even stylistically cleaver. Minecraft might not have as much oomph in the 3D graphics department, but you still need someone with at least an ounce of visual talent to make the game look decent and complete all things need done.

From my experience I've noticed a huge difference in my own projects when I had a talented person who is committed to my graphics needs versus trying to create things myself or using programmer art or even friends and colleagues who don't exactly have a nack for professionally looking artwork. Garland's Quest as a direct example will be able to make a good run for it's cost on stores like Apple's App Stores and Steam thanks to the extra visual oomph that hiring a professional artist has given it.

Not that you have to hire a professional artist, but if you don't have a "committed" person with this talent in your group, you may need to shop around for one. ...and get a commitment!

This bares nothing for the language it's self as it's a common rule for an indie developer of ANY language. It's just good practice if you want to get serious with Pascal game development and want to have a good run of it. ...same is said of any language though.

I do however love seeing all the commercial games coming out from Big Fish games that stretch multiple platforms, especially iOS which proves it's being kept current by those making tools and libraries for it.

Cezar is a notable contributor to this cause. I hope to follow within a year or so with one of my own titles myself... finally!

[LP]

If you ask me FireMonkey-s controls should check their imputs only after redrawing phase and not que any events just as games graphical engines does.

I disagree. Event-based refresh mechanism does not inherently imply low performance or slow performance time. The problem is, as you correctly pointed out, an actual implementation, which in the case of FireMonkey is not good.