Hello everyone,
I’ve decided to code a little project which I chose to be dice poker exploiting bullet and I got around the first difficulties which where to randomize the force throwing the dice and stuff. But now I’m facing a different problem. I don’t really know how to plan your code in the bge in advance. Because I guess my question is quite vague here’s an example.
If I know how a game works I might, depending on the language, code the objects and then implement the necessary attributes and methods and then I code the overall process of a game. Blender doesn’t seem to follow this way of structuring your programs since you can have individual scripts for every object and logic bricks. I get confused by the mixture of logic bricks and scripting on the other hand. Does it make sense to rely on scripting completely or is it better to have a mix of both.
I searched for a tutorial but couldn’t find any. I don’t know whether my question is too general or if it’s sth. you have to gain via experience.
Help is greatly appreciated. Happy blending
Personally I like to think of the ‘best’ way to do things as the most efficient both from a UI standpoint and execution in-game. The most efficient setup would be using a mixture. Theoretically, you could run pretty much your entire game (not talking about a massive AAA game of course :p) off one ‘always’ sensor with true pulse mode initiated on your script. But that wouldn’t be the most efficient way.
To explain better than I can have a look at some of Monster’s writeups in the game engine resources section, on pulse modes and controller execution off the top of my head. They talk about not triggering your script unecessarily and its a very interesting read.
Another thing and I could be wrong here but from what I’ve read on here the logic bricks are coded in C++ which is quicker than your Python scripts. So based off everything I’d say its a good idea to have a balance of logic bricks and scripts 
I agree with lambofreak.
The BGE is not designed that you “code” everything as other more “programmatic focused” engines. The BGE provides you with a lot of ready-to-use behavior “snippets” (logic bricks). You can easily connect them together to build a more complex behavior.
From BGE point of view logic is more or less “data” rather then code.
The “scripting” facility = Python controller allows you to extent the existing logic bricks with customized behavior. This is necessary if you want to work with complex data (e.g. working with lists) and complex logic.
While the implementation as Python controller indicates it should perform “controller” tasks (=translating sensor output into actuator activation/deactivation) the Python controller can perform actuator logic as well (= manipulating the scene).
You can find some guide regarding this topic in my signature (see guides).
I recommend to read
- BGE Guide to the GameLoop
- Sensors - A Word on Pulses
- BGE Guide to Python Coding
Thank you very much,
I feel kinda dumb since your tutorials are obviously hard to miss but I didn’t really understand which ones to look at. Pretty much answered my questions.
Well there is one major one left. If I got a linear process as you usually do have in a board-game-like game you might do it via a state property and AND sensors checking for the input and the state of the game? Implying of course you use modules and entry points? That’s how I understood it.
Greetings!
Do you mean a sequence of “tasks”?
Yes you can use
- the build in state system [(+) above the controllers.
- properties as “state”
- a Python FSM
- the ActuatorSensor to measure if an actuator gets activated/deactivated.
You can even mix this options 
Yes that’s exactly what I meant I just didn’t know the appropriate word. Thanks a lot I guess I can start to restructure what I got and start creating the rest of the framework. I think I’ll do it with the state property since I didn’t quite understand how the (+)-option there works but I’ll be fine doing it this way. After all it resembles more a program I’m used to write this way.
Happy blending!