Brainstorming: Simplified game making language and IDE

[User137]

I have had this idea hatch in my mind for some while... To make a programming IDE little similar to Lazarus, although much simpler. It would require only FPC compiler to make executables. User would use written and possibly some visual designing aswell to program games. IDE would create a full fpc source code out of it, adding all the "carbage code" required in freepascal language.

Theoretically a full application that draws image on screen could look something like this:

using Window, Input
window = MakeWindow // I guess name overloading with packages is allowed.
// It could make it var_window for the fpc source code.
using nxpascal
UseOpenGL(window)
texture = LoadTexture("test.png")
// Or have the texture list in the IDE, call LoadTextures(TexList1), and Draw using index 0

// Here could start thread instead, example below
repeat
Draw(texture) // or Draw(texture, 0, 0)
FlipOpenGL
wait // This calls Application.ProcessMessages
until keys[KEY_ENTER]
FreeOpenGL(window)

end
//window.Free // Not exactly sure if this is needed, or it it should be written like that, or
//FreeWindow(window)
end

This is just first sketch of idea, but i think it would greatly simplify game making. A package in this case would be a wrapper unit that adds available commands, types and variables. It would be required to make a system unit which adds all basic functions, and that would be autoincluded. I just added nxpascal as example, but basically you can use many graphics libraries in a big mix, if they are all based on OpenGL.

Also, most importantly, through packages it is possible to make a very powerful code completion. Opening lists of available commands as you type, completing lines with tab key. Language insist of automatically indenting code where proper blocks exists, so it won't be possible to make 2 commands on 1 line. This is for clarity, and requirement for possibly cool features for the IDE.

Finally thread possibility:

...
StartThread(gameThread)
...
thread gameThread
repeat
Draw(texture) // or Draw(texture, 0, 0)
FlipOpenGL
wait // This calls Application.ProcessMessages
until keys[KEY_ENTER]
CloseProc
end

// Auto initialize all procedures and functions in source code.
// It shouldn't reduce performance or add to the exe size, but lets use them in other procs before it.
proc CloseProc
FreeOpenGL(window)
end

Small issues i didn't fix in that yet:
- Keyboard and mouse Input is not updated (attach it to Wait?)
- Threads and procs need own "using" blocks, or write them inside the first blocks?
Suggestions, ideas welcome...

[Darthman]

As far as I know OpenGL does not support rendering from threads. Maybe something changes with time but if not...
Also I don't think that proc-oriented style is useful. I'd like object-oriented one.

As a main (and only) quad-engine developer... hm what can I say. Code abstraction must be as greatest as it can be. Thus can help in fast development later. But I think that if developer really wants to use all low-level stuff (direct opengl management, or winapi etc)

[User137]

Oh, i didn't intend for it to render from many threads at the time. The above thing should work just fine, as there is only 1 rendering thread.

I don't think this can have support for low level stuff, directly in the code. But you can do that stuff to package functions. They are just almost ordinary pascal units (.pas) and you can do whatever you want in them. However, intention is not that every game would need to make its own helper packages.

Then also what i think is that many people who are not that familiar with programming at all, would be able to make something with it. And... maybe the language/IDE would fit to more than just games. Thinking about it, its actually not a scripting language, but its not a real programming language either... What is it? The language that is used to make the final source code is irrelevant, it could even be C++, Java or Python. Although limiting factor is mathematical calculations and used symbols. If i'd have to parse them all, then yes something else than FPC could be used. But if i don't touch the math code and let write "A+B div C", then it's directly only compatible with FPC.

[Cybermonkey]

This reminds me a bit of my proof-of-concept project called fpBASCON which is a BASIC to Pascal translator. Using the SDL based game engine I wrote one can do something like this (simple mandelbrot):


IMPORT egslengine

DIM x, y, c, pow,time1,time2 AS integer
DIM a, b, z, a2, b2, x2, y2, przesx, przesy, przelx, przely AS real
MAIN
openwindow (800,600,32,"Mandelbrot")
backcolour (0,0,0)
drawtext (0, 20, "MANDELBROT SET")
drawtext (0, 40, "Press any key to start.")
redraw
inkey
clearscreen
time1=timerticks()
pow = 1
przesx = 0
przesy = 0
przelx = 3 / (800 * pow)
przely = 2 / (600 * pow)
FOR x = 0 TO 799
FOR y = 0 TO 599
a = 0
b = 0
c = 0
x2 = (przelx * (x + (przesx * pow))) - 2
y2 = (przely * (y + (przesy * pow))) - 1
WHILE c < 255
a2 = a * a - b * b
b2 = 2 * a * b
a = a2 + x2
b = b2 + y2
z = a * a + b * b
IF z >= 4 THEN
BREAK
END IF
c = c + 1
WEND
IF c = 50 THEN
colour (0, 0, 0)
ELSE
colour (255 - c, 255 - c, 255 - c)
END IF
dot (x, y)
NEXT
redraw
NEXT
time2=timerticks()
colour (0,0,0)
drawtext (0,0,STR$(time2-time1)+" ms")

redraw
inkey
closewindow
With the keyword IMPORT one can include all fpc units. All keywords are in uppercase, procedures and functions from the used units are in lowercase.