Thank you all, especially Red Ghost.

Just to get a couple of things out the way:

I''ve solved the problem about version differences between the DLL and EXE. When loading in the DLL, the EXE passes it a value, defined in the shared header files. The DLL compares it against the value from the headers it was built with. If they''re not the same, it returns an error.

I''m using C++, and am teaching C++. I don''t want to use a scripting language, partly because I don''t know any, partly because scripting languages are always limited. If my pupils are used to working with the package and are beginning to learn Win32, for example, they can easily begin throwing up other windows, loading other DLLs, opening files, and so on; all of which, I wouldn''t expect from a scripting language. Also, as I said, I''m teaching C++, not something like Python. While the language isn''t necessary to understanding the game concepts, it makes sense to me to try and teach them a language they''ll be more able to use outside the package - when they want to take the concepts they''ve learnt and want to apply them in their own, from-scratch games.

deClavier: thanks, I was already thinking about paths, at least. The worrying thing is that *I* don''t know what half of those mean, let alone my students.

Oluseyi: OK, we''re getting closer. Which design paradigms, or did you mean paradigms in general?

Red Ghost:
It''s pretty much what you''ve described, but a whole lot more, too. It provides functions for handling common game objects - such as sprites and triggers - or more abstract ones, such as the ''game state'' object (around which it seems to be revolving at the moment).
I''m not really asking what I need to implement - I know most of that already - more I''m asking what I *shouldn''t* implement, or only partially support. What I should force the student to use? They don''t have to deal with the game loop, but I have provided an interface for working with event-driven input, for example.

Answers to your questions:
- To be able to create a game, without necessarily knowing all the nitty-gritty of loading bitmaps, managing external files, or dealing with APIs such as Win32 or DirectX. As such, it''s going to be a fairly simple game they can create - but something of the level of Mario shouldn''t be beyond their grasp.
- They''ll need to know a little C++, and understand the concepts of program flow. The learning curve will be fairly shallow - to begin with, they only need to implement about 6 functions (excluding DLLMain) to get the thing to compile, and those functions only fill out a couple of structures with information about the game, so that the package can set them up properly. After that, addings things can be done one step at a time, till they''re comfortable.
- C++, but concepts which should be applicable to all languages.
- There''s usually a lot of math, particularly in graphics work. I don''t want them to have to deal with setting up sound channels, creating network sessions, or setting up Direct3D8 for 2D graphics *shudder*
- A DLL is compiled code, and is faster. Plus, they''d be able to release their games on the web, with little or no fear of people messing with them. Finally, because it keeps the game code explicity separate from the engine - something they need to learn.
- I don''t want to have them handling the entry-point function. I can guarantee, if I handle it in my .exe, that everything will be set up correctly by the time their code is executed.

Thanks for that list. I''ve already done sound, user input, and buffer management (automatic garbage collection included). I''m working on sprite support, as soon as I can fix this stupid alpha blending problem in D3D.





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

Your design seems to revolve around a game server processing requests for services (the States of the game object) and powering an event manager accessible to your students' DLL. Am I on the right track ? The Game API would be responsible for the View part of the model (graphics & sound) and the system management(File I/O, message manager) while your students would be responsible for the Model and Control part.

In my project, I was working along a similar track. I was providing for the Scenario DLL three virtual classes:
- An Agent class: it stores the game stats of the agent (attack, defence, XP, ...). It stores a pointer to its graphics and a pointer to its AI script.
- A Map class: it stores the map description, AI triggers and pointers to the tile graphics.
- A Context class: it stores the general scenario definition, the objectives and has in charge the initialization of the game.

I had seen two design stumbling blocks (since I do not know precisely your design, I will make a parallel to the system I had worked on. Maybe I had seen these stumbling blocks because of my faulty design ? Let's read on ...):
- To have a working DLL, I needed to include a virtual class for the Sprite and for the AI scripts (so that my pointer references be valid). However nothing could prevent anybody using that architecture to derive classes from the virtual Sprite and AI classes: a bad implementation of these classes without knowing the underlying structure of the server would be likely to cause a crash of the game. Moreover the Sprite virtual class does not presuppose of the Gfx API used (Win32 GDI, OpenGL or DX for 2D): thus a derived Sprite class could be incompatible with some or all Gfx API used (e.g. Sprite class derived for win32 GDI in the DLL incompatible with the OpenGL based API).
- I am using STL to manage my list of agents (it is a vector). Of course vectors only work with underlying objects that strictly are the same size: so the vector was based on smart pointers, therefore adding complexity to some calls (e.g. AI modifying agent stats, or maps triggering on certain agents). If this system was to be used by somebody else, he/she would need to have a solid grasp on STL vectors and smart pointers: quite difficult if this person is a C++ beginner.

As to what concepts could be put forward, I would suggest of course the use of templates(monster template anybody ?) and STL (your project lends itself well for it and this resolves one stumbling block), and the use of design patterns applied to games(This is a good start to learn factory, interface, flyweight, abstract factory and some other patterns). Both concepts can be reused within any project without any link to underlying hardware or language (as to the latter, implementations of patterns may differ depending on the language used - see the book on design patterns). However, I think the prerequisites are higher since the student must fully understand what are pointers and their limitations, and the inheritance concept in C++.

Another concept that could be put forward is that it takes as much time to code as to create all the graphics and sounds resource. It can even be extended to practising team management: you give a tight schedule and force your teams of students to come with a design document and realize within that schedule (could give a feel of industry pressure).

Hope that helps.
Ghostly yours,
Red.

[edited by - Red Ghost on July 8, 2002 6:50:18 AM]

quote: Original post by Red Ghost
Your design seems to revolve around a game server processing requests for services (the States of the game object) and powering an event manager accessible to your students'' DLL. Am I on the right track ? The Game API would be responsible for the View part of the model (graphics & sound) and the system management(File I/O, message manager) while your students would be responsible for the Model and Control part.

Pretty much. I''m going to provide a few more services than what you''ve mentioned - sprite management, input, and so on, but yeah, that''s the basic idea.

quote:
In my project, I was working along a similar track. I was providing for the Scenario DLL three virtual classes:
- An Agent class: it stores the game stats of the agent (attack, defence, XP, ...). It stores a pointer to its graphics and a pointer to its AI script.
- A Map class: it stores the map description, AI triggers and pointers to the tile graphics.
- A Context class: it stores the general scenario definition, the objectives and has in charge the initialization of the game.

I''m not quite being that specific. Tetris doesn''t need attack/defence stats; Moving blocks don''t really need full-scale AI scripts. I''m going to let the students work out what info they need to store for each ''agent,'' and will provide mechanisms for managing their agent stuff.

quote:
Maybe I had seen these stumbling blocks because of my faulty design ? Let''s read on ...):

I''m sure it wasn''t.

quote:
- To have a working DLL, I needed to include a virtual class for the Sprite and for the AI scripts (so that my pointer references be valid). However nothing could prevent anybody using that architecture to derive classes from the virtual Sprite and AI classes: a bad implementation of these classes without knowing the underlying structure of the server would be likely to cause a crash of the game. Moreover the Sprite virtual class does not presuppose of the Gfx API used (Win32 GDI, OpenGL or DX for 2D): thus a derived Sprite class could be incompatible with some or all Gfx API used (e.g. Sprite class derived for win32 GDI in the DLL incompatible with the OpenGL based API).

I think I found a way around this. In the header files, I can add ''class CSprite;'' and not define it (define it in another file). Everything is happy with references to it, but if anyone tries to derive from it, they get ''base class undefined'' errors. The code that actually needs to work with the class includes the ''real'' class header, and so access is totally restricted to the insides of the object to any code that doesn''t have the header included. Then of course, I just don''t give them the header.

quote:
- I am using STL to manage my list of agents (it is a vector). Of course vectors only work with underlying objects that strictly are the same size: so the vector was based on smart pointers, therefore adding complexity to some calls (e.g. AI modifying agent stats, or maps triggering on certain agents). If this system was to be used by somebody else, he/she would need to have a solid grasp on STL vectors and smart pointers: quite difficult if this person is a C++ beginner.

With some well-placed typedefs and the like, they hardly even have to deal with pointers. In my code, of course, I can be as complex as I like - but when it gets passed to them, they''re just deal with ''sprite'' (actually a CSprite *) or ''sound_ref'' (CSound**). Of course, they''ll still have to deal with pointers to their own stuff eventually, but they can get started on simple stuff without needing to touch them.

quote:
As to what concepts could be put forward, I would suggest of course the use of templates(monster template anybody ?) and STL (your project lends itself well for it and this resolves one stumbling block), and the use of design patterns applied to games(This is a good start to learn factory, interface, flyweight, abstract factory and some other patterns). Both concepts can be reused within any project without any link to underlying hardware or language (as to the latter, implementations of patterns may differ depending on the language used - see the book on design patterns). However, I think the prerequisites are higher since the student must fully understand what are pointers and their limitations, and the inheritance concept in C++.

I''m not too familiar with design patterns, so I''ll have to read up. The idea of templates is one I''m going to use - at least in the sprite engine, when you load in a single sprite ''template'' and create ''instances'' of it (shared graphics and resources).

quote:
Another concept that could be put forward is that it takes as much time to code as to create all the graphics and sounds resource. It can even be extended to practising team management: you give a tight schedule and force your teams of students to come with a design document and realize within that schedule (could give a feel of industry pressure).

A good idea, but I need to implement the package before I think about how I make them use it.

Some people may be getting the idea that I''m not the best person to teach these kids. You''re right, I''m not. I''m pretty much totally unqualified (well, by August I''ll have some GCSE''s, but they don''t count). But there''s no-one else, and these are the kids who find themselves stuck in lessons where they have to use Word or Paint, when those are programs they learnt to use to a high standard many years ago.

No real need to justify myself, I guess.. but never mind.

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

Well your project seems well defined, I do not see any reason it would not work for these kids.

If you are concerned about your teaching methods, I would suggest you to write down your teaching program. Then you could give it to read to someone of your family so that they can outline every concept they do not understand and that you may need to explain. From my own experience, it is never detailed enough; but the basic proofreading method avoids any troubles you may have when, after explaining how to use a pointer does for half an hour, a student asks "but sir, what is a pointer ?".

Another difficulty in teaching is to captivate the people you teach: generally I try to identify what do the students fear. Generally, my first lesson is to remove that fear and to give a sense of acomplishment to the student. An excellent example is given by Nigel Thompson in 3D gfx programming for windows 95 (MicroSoft Press): he had identified that his students were fearing the complexity of doing 3D gfx on a computer; he thus created a first lesson where the students would write in 1 hour a small 3D API with a sun and two planets orbiting (no textures, just lighting and object movement). To quote Nigel Thompson: "By the end of the day, I had a lot of pumped up apprentice [...] programmers who didn''t want to go home."

The last difficulty in teaching is to keep that motivation. To each his own method: you can check on Michael Abrash way of starting each article by telling a little story close to the subject of his article (some are in GameDev resources).

Anyway, way to go SuperPig ...
Hope that helps.
Ghostly yours,
Red.