(BTW - for anyone who''s interested, my last talk went OK. I now have about 20 pages of ideas of ''Ultimate Pacman,'' which I have about a week to implement ) I''m writing a sort of game framework, most likely to be used as a teaching tool, in which the APIs for graphics/sound/etc are completely abstracted, and the developer stores his/her/its game in a DLL (single files are much easier to distribute). It''s designed mainly for 2D games in the vein of Pacman or Tetris - i.e. arcade games - but as I go I''m doing my best to make sure that a person could develop something like Super Mario World on it. Assuming that it does someday end up being used as a teaching tool for game newbies, which concepts do people feel I should make it use? For example: everything is powered by a ''Game State'' engine. The developer ''registers'' a number of different ''states,'' each consisting of Draw, Think, Start, and End functions (with a little more, too). They can then switch between states at will - if the PlayLevel state detects the end of the level, it can set the state to EndOfLevelScreen, and so on and so forth. Which other concepts should I push my developing users (no pun intended) towards? Superpig - saving pigs from untimely fates - sleeps in a ham-mock at www.thebinaryrefinery.cjb.net

So, what do kids want ?

Documents [ GDNet | MSDN | STL | OpenGL | Formats | RTFM | Asking Smart Questions ]
C++ Stuff [ MinGW | Loki | SDL | Boost. | STLport | FLTK | ACCU Recommended Books ]

Sorry, maybe you misunderstood. (Unless of course you were talking about the Ultimate Pacman thing, in which case I misunderstood.)

I''m not necessarily talking about teaching kids in schools - I mean teaching people who are new to making games. By hiding all the API-dependent stuff, they''ll be more able to train up to use any platform. Plus, the API-dependent stuff is the messy stuff, so they won''t need to worry about it.

For example, the .DLL code for adding a menuitem to the menus is something like:

menuItem mi;
mi.mID=ID_MY_MENUITEM; //menuitem ID
mi.parentID=0; //id of the parent, for nested/popup menus
mi.text="My Menuitem"; //menuitem text
mi.flags=MI_ENABLED|MI_CHECKED; //flags
mi.callback=OnMyMenuitem; //callback function when selected
ss->menus.AddMenuItem(&mi);

No need to worry about message handling or anything - just provide the callback function.

Now, I''m looking for ''key game concepts.'' If my software were in 3D, I might be looking for things such as ''portals'' or ''bsp'' - rather, I need more general ideas.

Superpig
- saving pigs from untimely fates
- sleeps in a ham-mock at www.thebinaryrefinery.cjb.net

I was talking about the kind of features they had requested.



Documents [ GDNet | MSDN | STL | OpenGL | Formats | RTFM | Asking Smart Questions ]
C++ Stuff [ MinGW | Loki | SDL | Boost. | STLport | FLTK | ACCU Recommended Books ]

quote: Original post by superpig
Which other concepts should I push my developing users (no pun intended) towards?

You could peruse the websites/mailing lists associated with the various gmae making toolkits out there and see what the common requests are. You could also interect with the author of 2D GameStudio I believe it''s called and see what he thinks.

Honestly, I have no ideas as I''ve never considered the needs of that demographic.

Fruny: Ah, right. Well, most things seemed to tend towards the cosmetic - different bad guys, the ability to play as different Pac-people (Pacman, Ms. Pacman, Baby pacman, etc).. although the idea of ''traps'' in the levels was frequent, as was giving the player a weapon. Boss creatures every 5 or so levels.

The end result is going to be a Pacman game which can actually be completed (being limited to premade levels). The levels will all be accessed through a Map screen (a la Super Mario World).

Oluseyi: No, no! If you were hiring at a game company, what non-API-specific programming skills would you want in your people? Familiarity with COM-style interfaces? Knowledge of fuzzy logic? What?

Superpig
- saving pigs from untimely fates
- sleeps in a ham-mock at www.thebinaryrefinery.cjb.net

What about the ability to create levels where the doors move about but the bad guys all stand still?

No, wait, I should be helpful.

freeform targeting, multiple collision contexts and reactions for each object, opponent priority lists, conjunctive object-player modifications, paths, level-morphs, timewindow interactions, player control shifting between objects, quizing the player, and and and

alright, you guessed it, I''m just making this stuff up.

oh... and player morphing with various triggers

damn! I knew I could think of something cool to finish with

If I understand it correctly, you want to write an API that abstracts all the base level and hardware/libs dependant calls. This API would load up a DLL containing only the game rules and the intialization system. This DLL would be developped by students to train them in general programming concepts.
Your question seems to be what kind of minimum abstract interface do the students need so that they can complete simple classic 2D Games.

I have considered developping a program close to your proposal for myself and I have made some research. Before telling what I have looked into, I would like to ask a few questions:

- what do you wish your students to be able to do at the end of their training ?
- what is the target learning curve ? (pre-requisite ? steep or smooth learning curve ? ...)
- what language do you wish to teach ? (C++, Basic, ... ?)
- why is learning to use an abstract interface to base level hardware/libs better than learning to use the base level hardware/lib (e.g.: learning to use abstract graphics interface vs learning to use D3D or OpenGL)?
- why do you prefer DLL to scripting ? (close but not identical to the second question above)
- why creating an EXE with students providing the missing DLL instead of creating service DLLs (graphics, sound, ... DLLs) with students building the program (e.g.: a library built under the same concept as glut) ?

Here is what I have checked in my design:
The language used is C++. I wanted an API that loads up a DLL containing derivated classes of my abstract interfaces. The DLL only contains code: data is stored in files for ease of tweaking. The DLL only provide the scenario or game rules and modified agent classes. It does not contain anything about dialogs, sounds or sprites management. It focuses only on the gameplay.

The model used is the classic model-view-control. The model part holds the data descripting the map layout, the data descripting the agents. The view part holds the representation of the map, the sprite corresponding to each agent state the sound linked to each agent state. The control part holds the user input and the agent AI.

The API must provide the following basic services through abstract interfaces:
- Management of buffers: offscreen buffer and graphics pool.
- Management of sprites: with and without clipping.
- Management of sound.
- Management of a message center.
- Management of user input.
- Management of AI Scripts.
- Management of dialog boxes: font used, colors, appearance.
- Management of File I/O: File I/O and file parsing strategies.
- Management of DLL.

I had thought deeply about the use of DLL in that case. It does have drawbacks:
- DLL nightmare: how to control that the DLL will not crash the exe API in subsequent implementations ? (I had even read in the forums here that under MSVC a DLL compiled in debug mode does not have the same behaviour as the same DLL in release mode - perhaps it was regarding an ancient version of MSVC. For me I use BC++ 5.01).
- abstract interfaces included: the abstract interfaces used in the DLL are the same as the one in the API (graphics and sound to be able to display the agent sprite at the correct coordinates and to play the sound associated to the agent state).
- debugging: I add one more step in my debugging cycle-> compile, check compilation and linking errors, run the API exe and check the behaviour of the DLL (if the behaviour is weird, correction and back to compile). I hate waiting to compile.

I did not find any clear advantage that would outset all the drawbacks:
- to create a DLL for scenario rules or to reuse header files and to compile back a full program looks the same to me.
- the executable size is actually small. Why create a DLL to have smaller exe ?
- this design would not be easily ported to other OSes or architectures (DLLs exist only for windows)
- I do not need to hide implementation details inside a library.

I decided instead to have classes providing the basic services and to compile each time a full program.
This is a long post but I wanted to show why on a quite similar idea I finally abandonned the DLL idea. I also wanted to show that with or without DLLs the classes you need to provide your students will not change: these classes are the basic services I outlined above. In fact I provide all the tools that help me to define the behaviour of the app: with these classes, a few line of code can create an editor or a game since the underlying principles are the same.

I am looking forward to your answers.
Have a nice day.
Ghostly yours,
Red.

quote: Original post by superpig
Oluseyi: No, no! If you were hiring at a game company, what non-API-specific programming skills would you want in your people? Familiarity with COM-style interfaces? Knowledge of fuzzy logic? What?

Critical, analytical thinking. Comprehension of design paradigms. External, non-technical interests. Quick, creative thinking. If they possess these properties, they''ll be able to quickly pick up whatever I decide to throw at them.

Why not emphasize the use of one of the many frameworks already in existence? Python and PyGame might be a good combination (Never tried them, but I''ve heard fairly good things about them). By carefully separating game logic code from scaffolding, you can rapidly prototype games and later migrate the same code to a game engine that uses Python for scripting.