teaching Python using the BGE

So, lately on facebook I have been teaching a few people python basics, using the game engine.

Right now I start off with gamelogic simple, and using sensor data to apply properties etc. I then use Ifs with ands,

And then I go into for loops.

At each step I use gameplay mechanics they are trying to impliment…

Since they solve there own problems, it really seems to stick…

So what are some use cases for more exotic things? Why do I need a class? When do you use a function? When the code repeats more then one time?

If I can create a gameobject and add a property to it, to adjust a behavior, why do I need a class?

Like
If ‘bullet’ in own: add bullethole on impact

Or if ‘rocket’ in own: add radius damage and explosion

What are some good lessons, that have direct applications?

Python is a programming language.
The BGE is a … an application that can be customized via the BGE API.

These are two different things. Obviously to use the BGE API you need to know Python. But you do not need to know the BGE to use Python.

While the BGE gives some practical experience I do not think it is the best way to learn the Python language. There are quite a lot of very good online courses and tutorials available. They allow to get into the language pretty fast (couple of days).
Beginners can’t easily distinguish between Python and BGE API. Beside of that they need to know how the BGE is dealing with the code they write. Nevertheless if the final goal is the BGE it is not a bad start.

Classes on the other hand belong to OOP. It does not matter if you learn the basics with Python or any other OO-language. Finally you do not need the complete OOP set when using the BGE. You are a user of existing objects. There is no urge to create own classes or dig deeper into OOP.

I strongly recommend to use online courses to learn about the OOP-methods. They offer the right ways to pick this topic up rather than balancing with BGE, Python and OOP at the same time. As said, this is not easy for beginners. They can’t even distinguish between them.

Just my opinion.

Along the lines of what monster said, I think that you need to answer for yourself this question:
Are you trying to teach them python, or are you trying to teach them python for use in the BGE?
if you are trying to teach them python then I think that you need to get away from the BGE fairly quickly.

Well, I think I would like to teach them how to make games, and in doing so teach them python.

I understand that the bge itself is not the most common use case for python, however to teach someone (for real)

you need to strike a nerve with their passion. If they want to make games, and are learning python for this purpose,

I am certain a ‘course plan’ could be made that taught the fundamentals via teaching them to write there own game,

Perhaps more then one course would be in order?

Basic fps - teaches - logic gates - Sensors/Controllers/Actuators and common usages

3rd person Rpg - teaches Lists, modular design and vector math and module mode

Mutiplayer - teaches networking, threading, and further instills a knowledge of bottlenecks and workarounds.

Using bge to teach python is a nice idea - it is an interactive environment, you can actually see stuff changing, i can’t see but advantages in doing it.
How to introduce function. This is easy.
Instead of using scripts use modules. Modules will force you to use at least one function. Now, why one should use a module instead of a script? Because modules are stateful in the game session and they are also shared, so one can use a module to let game objects talk to each other.
How to move on to classes. This is not so easy.
The point of classes is that you don’t need them… until you really do.
You can show how to use them attaching using an instance as the value of an attribute of a game object, for whatever purpose you may like - let’s say that the “player” has an attribute “weapon” that is the instance of a Weapon class which carries a name, a bullet amount and a “fire” function.
The problem is that if the system has not a certain complexity (being made of several interacting parts) classes will look like an unnecessary burden.

For the case you describe, I still have been using game logic,

check out my weapon system…

is the object -> weapon essentially a class that was made by hand, rather then via script?

I use a object (weapon manager) to spawn in weapons from a hidden layer based on a list,

the manager contains ammo, and a list of weapons,

colliding with a weapon_pickup item adds the name of the weapon to the list,

switching weapons cycles the index, spawning in the weapon, the weapon parents to the weapon manager, the system interacts with the weapon , via own.children, this also allows the manager to see if a weapon is equipped etc.

it can reload, and fire the weapon, by looking at properties in the item.

using the same system using classes, would mean I still need everything I mentioned, however the pick up item would need to contain all of the data about how to use the gun, rather then the object on the hidden layer?

spawning the gun in would actually mean creating a new item?

so the pickup item would need - Clipsize, ammoType, Mesh, Projectile,reload time etc?

then the spawned in item “morphs” into the weapon in question?

Classes, modules, packages and even functions are not a matter of necessity - we can live without them - but of madness management.
The bge bricks makes for a nice comparison. They start nice and pretty, then they become uncomfortable as the complexity of the logic grows and at the end they simply become an unreadable mess.
If you write the same logic with pure code, it starts ugly and remains ugly, but no more horrible than that. That’s because when things starts to get out of hand you can re-organize the code to work the same but hide unnecessary layers of information, with functions, modules, classes and whatever you can.
It is not a blender specific issue, there have been lots of attempts to change the text file paradigm for programming into visual components, and all have failed due to the “linear ugliness” of code compared to the “exponential horrendousness” of graphical nodes.
That’s what classes are for: build complex systems without going completely insane.
Is that brick mess complex enough, is it made of enough interacting parts to justify the translation into oop code? I have no idea, there are no metrics that tells us exactly when you should start worrying.

like this :smiley:


I think after a certain complexity, logic interconnections adds up to brain surgery

To deal with management you need to dig deeper into coding architecture and design. This is a huge and very complex topic. Beginners usually do not understand that. What they understand is a simple and easy to follow guideline.

Thinks will become complex during development. The trick is (even when teaching) to split complex things into small and easy to understand parts. Indeed each split requires a simple and easy to understand part at an higher abstraction level that brings the lower level parts together. This allows you to deal with small and easy to understand parts all the time.

When is a part not simple and easy to understand? This depends on you, as you are the one that is supposed to understand it. If you want to teach, you need to think about, what the others might find simple and easy to understand.

Examples of not simple:
video tutorial >10 minutes
text tutorial > 200 lines
Logic bricks > 10 lines (per state)
Python function > 30 lines
Python module > 300 lines
User guide > a visible page
title > 7 words
post > 5 paragraphs
school lesson > 45 minutes

Finally it depends what you want to achieve.