Kids can't make fun games anymore.

Member
Posts: 227
Joined: 2008.08
Post: #31
Yeah, I have a long history of working with tools. Never stayed with one for more than 6 months. From my experience (being under 10 when I tried some of them)(several not shown):

1) Dim3 is brilliant, runs beautiful on low spec hardware, easy, best mod tools, but is not very flexible and is almost strictly a mod maker for a built in FPS. (11 at time I started looking at it)

2) Flash is a disaster, follows a unplanned format and the flow is terrible, Dad loves it (he is a web designer): should have stayed with Flash 8 AS1 concept. I started on this around 9 years old. Stopped at 11.

3) Baja engine has a nice scripting interface, don't like the rest of it.

4) Lovin' Cocoa (the full one, not kiddie app), although is not necessarily the beginner style. (A simplification would be great)

5) From experience with making my own game engine, do modules that allow the using of different .

I am working on a similar concept. The components are in parts (not all finished):

OE- the core (lightweight, demo can be made with only this)
OP-physics (collision)
OM-media (audio,video)
OI-human interface (menus, buttons, joysticks)
OS- OS compiler and libraries (OS is a Obj-c/Lua like language)
OU-auxilary utility libraries

All less than 15 required functions each, work with any c variant, and provide hooks to be flexible and alllow for any other libraries to be used instead.

Standard stuff is prefixed with OX and implementation specific extensions have ox. For example: key detection on PC/OSX ( oeKey() ), touchscreen on iPhone ( oeScreenTouchedAt() ) ).

Just some helpful experience.
Quote this message in a reply
Moderator
Posts: 683
Joined: 2002.11
Post: #32
I would be extremely interesting in seeing the results of that whenever it's finished. I haven't yet seen a decent C-based game library.

My web site - Games, music, Python stuff
Quote this message in a reply
Member
Posts: 227
Joined: 2008.08
Post: #33
I am making it because most game libraries are C++ based and I dislike C++.
I'll try and get a progress website up.
Quote this message in a reply
Moderator
Posts: 683
Joined: 2002.11
Post: #34
I think I have uncovered the real problem: conditionals.

One method would be to have a bunch of events that trigger behaviors. For example, you would have a Collision event with an EnemyBullet as an argument trigger a TakeDamage behavior. However, if you wanted to display text on collision based on the object's current health, you probably couldn't do it. You would need to resort to scripting.

I suppose that providing that much functionality would decrease the quality of the interface and turn the app into a "programming with graphics" app rather than a "making interactive stuff" app. If anyone can think of another way to do it, though, I'm all ears.

One side goal of this project would be to isolate a subset of common Python libraries and set up an automated build process for them that doesn't involve config files. Actually, this is where I would start, because building and distributing is probably the hardest part of Python game development to figure out.

My web site - Games, music, Python stuff
Quote this message in a reply
Post Reply