In the past I’ve done a few tutorials, some video based, others I did with PDFs, both types were well received as there’s not a lot of good tutorials for the BGE. One of my most viewed videos on Youtube is a very old level building tutorial. It was supposed to be the first of a series but I didn’t have time to make the others.
How would people feel about organizing something to get some of the more advanced Blender Game engine users to band together and crank out a few tutorials? We could use kick-starter or one of those kind of things to see if there’s the right amount of interest.
I know there’s a bunch of us here who have been using the Game engine for years and could probably share a lot of helpful hints, practical knowledge, game templates or other things people would be interested in. But I also know that none of us have a lot of time, as most of us have full time jobs and/or families. Would setting up a method of getting payed for our time and investment be a good idea?
One idea I had was to do a team game project, with one experienced blender user working on each stage of the project (most of us have a specialty such as modeling, random generation, multiplayer support, inventory, AI etc…) and the whole thing documented through a series of tutorials. Is tarted doing something similar in the past, but without payment, it gets a little tiring after a while.
There would be a lot of ways people could help, either by contributing assets to the game, making tutorials, spreading the word and trying to get people to donate…
I have two series that cover the development of two relatively simple games, along with a batch of requested tutorials: Everything from basic mouse-look, to fundamentals of matrix math, to more involved networking demos.
If you’re looking for a tutorial, there’s a pretty good chance that you’ll find it there, or find something fairly relevant.
I have a suspicion that if different people help, we’ll end up with a mis-match of styles.
So if this is to go ahead, I’d suggest making a document outlining things like:
How objects are named
How textures are named
CamelCase or under_score in code
This has got me all fired up to write tutorials again. If people just put the tutorials from the resources forum to a single place, like the gameblenderwiki.
Hmm, maybe I’ll get in contact with some authors and see if I can simply move them there.
If you ask me that’s a very great idea.
Make a complex game one that would demonstrate at least 90% of the
things one has to know to make a semi AAA game and write a tutorial
explaining how you did each thing e.g. "how you made the character’s clothes’.
Note the problems one might come across when trying to do that and how to fix those problems.
Try to make the explanations as basic as possible.
I have seen a couple of great demonstration BGE blend files, but the creators did not explain how they made the file very well which makes it useless.
I personally prefer pdf tutorials as they are easier to save to your local hard disk for later viewing.
The idea has some great benefits which are drawbacks as well.
Creating a tutorial is a lot of work. And I mean a lot especially if it is supposed to be a good one. Usually there will be much more time spend in creating the tutorial than in what the tutorial is showing. (Example: my last tutorial: 10 minutes recording footage vs. 10+ hours tutorial generation (preparation, design, cut, text, comments creating, voice recording).
On the other hand, the time you spend on tutorial planning is time you investigate at this aspect of the game. If you are experienced you will avoid aspects that are not necessary in the later game or lead to a dead end. Unfortunately even experienced will create “wasted” resources (just look at the unused scenes delivered with a DVD - and that is just a fraction ;)). The result of that should be a quality piece of work.
So this idea is a great opportunity but has an high risk of failing due to the immense amount of work.
BTW: I suggest to use a versioning system (such as gid or subversion) with small files. This does not only support teamwork and keep things organized. It helps to get the resources for later tutorials too as you can easily access the old resources. Most essential is a bug/issue tracking tool (such as bugzilla or redmine). Here your can describe each single task to be developed which should include: what it is supposed to do, how it fits into the overall system, how it interacts with over aspects, why it is necessary, the chosen design and alternatives and why a certain implementation was used. This will help in a later tutorial as well.
Yes, I did a set of three PDF tutorials and while being less work than a video tutorial and giving more in depth info it was still a lot of work.
What I would really like is if someone could take on the role of organizer or planner and I can help out. I’ve got lots of areas where I can contribute, but my time is limited.
I had the idea before of remaking an old game using the Blender Game engine, and documenting all the steps involved.
Something easy like a 3d version of an old classic like double dragon:
or ghosts and goblins:
Or even the old classic DOOM:
Or if so, why not go the whole hog and make quake?
We wouldn’t have to make the whole game, just a single demo level, and a level editor so people can make their own levels ~and learn how to make a level editor too! It wouldn’t be a total copy either, just a re imaging, like “Shudder”, or “fate”, rather than doom or quake.
Someone could do the modeling and texturing, another person level design, someone else UI and another person could do the enemy AI. I’m at a stage now where I could do everything needed to make one of the above games and have it running fast and smooth in the BGE. Wouldn’t it be great if we could make a set of documents which could bring even a novice blender user up to that level in a couple of weeks? I think it’s possible.
An outline for such a project (using Quake for an example) would be:
Part 1: Fast Modeling and texturing basic game engine assets [no logic or python]
Part 2: Modular Level design [no logic or python]
Part 3: Mouse look and character movement [logic bricks for movement + basic mouse looks script as an intro to using plug-and-play scripts]
Part 4: Weapon #1 rocket launcher using added object and Weapons effects, sounds and animation. [logic bricks]
Part 5: Physical interaction (opening standard doors) [logic bricks]
Part 6: Ammo, keys, armor and health pickups. Changing levels. [logic bricks]
At the end of the Beginner level you will have a basic level and a character who can navigate around in it, pick things up and open doors.
Part 1: Rigging and animating Characters for the game engine. [no logic or python]
Part 2: Basic UI, showing health armor and weapons/ammo. [logic bricks]
Part 3: Zombie AI (most basic) tack to character and walk if LOS. Stand still otherwise. [logic bricks]
Part 4: Enemy Animation and interaction. Enemy can kill and be killed. [logic bricks]
Part 5: Weapon #2 laser gun using rays [basic python script introducing rays and setting properties remotely]
Part 6: Turret AI (a ceiling mounted gun turret; intermediate AI) [logic bricks]
At the end of elementary level you will have a couple of pretty dumb enemies (but good enough for a beginner type game) and three different kinds of weapons. You will have a working UI that can keep track of the player’s health and other attributes.
Part 1: Level editing and Creating a navigation mesh. [no logic or python]
Part 2: Weapon #3 single shot rifle using rays and leaving bullet holes [python script introducing adding objects and setting their position and orientation]
Part 3: Attack dog AI, attacks by biting (basic path finding AI using nav mesh) [basic python and logic bricks]
Part 4: Locked doors and keys, lifts, teleporters, [python introduction to checking for properties and environmental animations]
Part 5: Weapon #4 Shotgun (single and double barreled) [python script, using multiple rays, using a for i in range loop]
Part 6: Zombie Trooper AI, armed with ranged weapon, path-finding and shooting [basic python and logic bricks]
At the end of the Intermediate level you’ll be able to add several different types of semi smart AI characters to your game, you’ll have more confidence using python and you’ll be able to start adding puzzles and more interesting level designs.
Part 1: Dynamic lighting set up [python script using get closest and other useful things, showing how to use a small number of lights to fake a very dynamic illumination setup].
Part 2: Ogre AI, mixed AI using hand to hand combat (chainsaw) and ranged weapons as needed. [python and logic bricks]
Part 3: Weapon #5 machine gun, [python script introducing random bullet spread, rapid burst fire, clip reloading and others]
Part 4: Trooper AI, [an advanced AI using way points to get in to covered firing positions, armed with machine gun and grenades]
Part 5: Scripted events; having a door lock after you enter a room, wall panels lower to reveal hidden enemies etc… [python, triggers and states]
Part 6: Water and swimming, ladders and anti-grav shafts [python, reworking the player movement system to be more flexible in different situations]
Part 7: Save and load game [Python, accessing files, using pickle]
If you finish advanced level you’ll have pretty much everything you need to make the original game.
Part 1: Elite Guard AI, uses cover and teamwork, can patrol and do other intelligent things like run away [python, how to make a finite state machine]
Part 2: Custom monsters, add new monster types and give them different behavior depending on their intelligence and design function [python]
Part 3: Inset mini map and radar [python]
Part 4: Advanced inventory setup, replaces number based weapons, allows for things such as single use medkits, grenades, audio logs and other stuff. [python, more advanced usage covering dictionaries and other things]
Part 5: Buddy AI, will attack enemies but not each other and the player. [Python, introduce teams, target selection protocols, other things needed for a complex team based AI]
Part 6: Replace BGE navmeshes with custom navmeshes and custom A* algorithm. Make modular level editor. Place level sections and characters with the mouse. Save created levels to disk.
Part 7: Vehicles AI. Allow drivable vehicles. [python, vehicle wrapper and AI]
Part 8: Outdoor levels, flying bosses, stealth mode, anything that anyone could request as a feature they’d like explained.
Yoda level would be a stretch goal. If you’re doing Yoda level then you’re doing things far above and beyond what the original game was capable of.
Anyone got any suggestions for changes to the list? If multiplayer was included it would change the way things were done right from the start. But how exactly would things need to be done differently?
From my experience making 3 PDF tutorials in a row is about the limit anyone can be expected to do in a reasonable amount of time. Without Yoda level, there are 25 tutorial subjects there. If people did 3 or 4 each that’d need at least 8 blender heads to finish the project.
Could we find 8 people willing to contribute? Lower level tutorials have less content to convey, but they need to be more verbose and go in to more detail, because the people reading them will have less knowledge and experience.
When summer comes I’d be really interested in adding Multi-player. It would give me a chance to use it in a game (besides my own re-started project). However, there would come a point that using my multi-player system is quite encompassing - you attempt to use as little of the BGE API as possible - using wrappers wherever necessary. Understandably, some may wish to design a network library from scratch, but like most things I believe that it is first important to understand higher level concepts before looking at implementation details. For this reason, it might be best to design two tutorials:
Creating a multi-player game with PyAuthServer network library:
How to deal with network latency
How to reduce the amount of data sent over the network
How to support clients joining and leaving games
How to prevent clients from cheating
Creating a network library:
How to define a game state
How to serialise a game state to bytes
How to design an extendible API for new data types and game types
How to optimise networking and game state code
You’re correct in saying that this would require changes from the offset. The best way to achieve this would be to advise with whoever writes the tutorial on multiplayer so that the initial game is expressed in code wherever possible. Unfortunately, Logic bricks are best avoided wherever possible as they aren’t “networked”, though they can be used if needs be.
For example, take this “sample” of player logic. In a naive implementation, it may look something like this:
own = cont.owner
if bge.logic.keyboard.events[bge.events.WKEY] == bge.logic.KX_INPUT_ACTIVE:
vel_y = 1
elif bge.logic.keyboard.events[bge.events.SKEY] == bge.logic.KX_INPUT_ACTIVE:
vel_y = -1
# Open doors
if bge.logic.keyboard.events[bge.events.FKEY] == bge.logic.KX_INPUT_JUST_ACTIVATED and cont.sensors['Near_door'].postive:
door = cont.sensors['Near_door'].hitObject
door.playAction("Open", 1, 100)
In order to make code re-usable, it’s best to either write it in the multiplayer sytem first, or write it in a modular fashion like so:
This way, if we take my current multiplayer system as an example, it becomes easier to rewrite the code: replicables.py
Although my converted example is not synonymous with the BGE example, it’s just a case of having already written this code Essentially, code needs to be modular and avoiding hidden dependencies:
If a BGE API dependency exists, write it into a method (in my case, I created a Keyboard class and get_near_objects class)
If an object has a specific behaviour - like the door which has an on_interacted method, consider doing what I did and storing references on the object’s dictionary (I’d replace get_method(obj, name) with obj.name or use a Signal as my PlayerController does)
Avoid super-long methods. Methods need to be short and to the point. If you have a method which handles shooting, damage and all other possible events, you’ll find it hard to modify and create dependencies. Later on, we could (for example) disable shooting calculations on the client by disabling the raycast_shoot method (rather than writing an entirely new shoot_weapon function.
An interested PDF on multiplayer is the Meerkat approach. Whilst some of its features seem to be impractical, it’s interesting to read.
***I’d also be interested in AI , having worked on different AI techniques and navigation methods I would be interested in exploring this field further, and a tutorial would be a useful vehicle for achieving this.
If a video format were to be used, it would be interesting to see if we could further use my tutorial site: http://www.coldcinder.co.uk/bge/
Unfortunately, I lost meta information for existing content due to an uncooperative web host which wiped my database before I had time to back it up.
Thanks to all those who are considering doing this with their time, it means alot.
I think this project has great potential, every year more people - especially students - are using Blender to enter the game development world, be it for modeling ,texturing, as environmental artists, level designers etc. I think it’s safe to say there is a clear demand for a professional grade course covering these topics, Smoking Mirror’s above post is perfect - and quake is a fantastic first project.
I’d be willing to put $100 towards this if we could get a consistent team of people lined up - I think it could be a great course, presented in a professional way. One Presenter going over the assets and actual tutorials with a team providing assets/code/experience. I’d be willing to even make the team a website - heck you could even have an old school forum on there for communication.
That sounds like at least a “Jesus” level tutorial to me The object oriented approach of most blender games doesn’t seem like it would lend itself that well to an optimal multiplayer setup. That said, I think a lot of people would be interested in functional, rather than optimal multiplayer. The same with AI, once you know the basics you can start researching about finite state machines and weighted decision making and other interesting stuff. But a lot of people can’t even get a simple LOS rack-to AI up and running.
What would be needed would be a simple and clean functional set of systems, with as you say, as few dependencies as possible. It should be possible to rip out one system, like a movement system for the player, and replace it with something else, such as a system optimized for multiplayer, without that change spilling over in to shooting or the UI.
The increase difficulty level needs to be gradual, and it needs to be broken down in to stages or levels, so that for example if you already have an understanding of logic bricks and basic python you could skip the first two levels completely, download the example blend for the intermediate level and dive right in.
When I started making some tutorials in the past I made the mistake of thinking “how would I tackle this aspect of the game?” instead of “how should someone who is dealing with these things for the first time tackle this aspect of the game?” The important thing is not that it is optimal, but that it is understandable and digestible. Optimization can come later, once they understand what they’re doing. I made the mistake of saying, do this and do that and then you’ll have a finished function, without explaining what this and that do, or what we do this instead of that and that instead of this.
These days I’ve been trying to make my own scripts as modular as possible. If I make an AI script I want it broken up in to functions, and I want it so I can use those functions elsewhere if I need to. A “get_closest(origin,type)” function is a lot more useful than a “get_closest_enemy()” one. I think that’s a good habit to get in to from the start, but it needs to begin with very simple examples and it needs to be backed up with explanations and where possible examples, such as example blend.
Indeed, modularity is vital. For people who work on this, you will need to have a style guideline and some form of code review. I think having a GIT repo might be quite a good idea for this reason.
On the topic of Object Oriented programming, the reason that my examples use functional programming aspects is because it’s somewhat easy to convert between the two - the module would be a class scope, whilst methods which are defined as func(player, data) can be rewritten as player.func(data). By all means using OO throughout would be great, but It depends if you want to give tutorial readers that challenge from the offset, or introduce it later by performing the conversion as I said. Object Oriented programming lends itself to multiplayer for the API because you can leverage inspection and other tools to determine what data is to be sent.
The Multiplayer Library that I’ve written is simple in concept, more complex in implementation, simply because there are many different subsystems to contend with. It seems to remain relatively simple though.
In specific terms, many things are comparable - you have network objects, which can send and receive data. They have two different means of sending information, one of which is server-client only. Network enabled physics objects are called Actors, and Pawns are player -like physics objects. These are controlled by Controllers which implement the movement logic.
Ultimately, it should be relatively easy to modify the base “template” which I’m working on for a First Person Shooter. One could then continue to write tutorials to indicate how to branch out to other game types, but I digress.
With regard to API access, the general rule of thumb is that if any structure/method is BGE-specific, create an interface and then a BGE implementation of that interface. Later on you just write a new implementation of the interface: http://www.pasteall.org/50938/python
Shakedown raises a good point, if we are going to create a “Quake like” game - we will need a good GDD, anyone have any experience with creating one, after we have this I feel the project can slowly start to come together.
We’d also need one dedicated person to host/present the tutorials - I can do the voice overs if anyone lacks the equipment as long as they provide a script.
That sounds like a good idea.
My day job is as an English teacher, and I often have to teach complex grammar to people who are basically not interested in the subject (i.e. children). One of the best ways to do this is to “wrap” the grammar in a related subject and activity.
For example I usually use a class survey about experience (have you ever eaten frog’s legs?/have you ever ridden an elephant?) when teaching the present perfect. Students interview each other and get points for having the most interesting experiences.
It’s much easier to learn something as an activity or game than sitting through a dry lecture on abstract rules of grammar.
Thus for the tutorials I figured it would be good to include things such as vector math and arrays in a relevant section. For example; player movement using python or weapon trajectories.
I’m very against tutorials which just lecture about a subject, that’s why I think recreating a game is a good idea for a set of tutorials, it lets people learn by doing, which is what I do in my day job.
I also think tutorials should have lots of hands on examples such as example blend files, pictures and diagrams rather than a wall of text (like this one^^)
It’s good to hear we all on the same page and thanks for the links.
The tutorial creators will have to consider how they license the
scripts used in the tutorial. Because the licensing could make or break the whole project e.g. I found a tutorial on how to make a FPS cam but I could not use it in my game
because the terms of the license required my game be open source. As a result I am still trying
to come up with FPS cam script the does not infringe the terms of the CC license meaning the tutorial did not really help.
Basically the licensing terms should allow the tutorial user to use the scripts in what ever way they want to.
@adwitandrew - I elive all content used in this project will be CC license, using only my sometimes shady memory I belive you can do what you like with the assets as long as credit is given.
As smoking has said however - this project is literally going to be a case of “The user makes the game as complete as he/she wants”.
I think we are all hoping that you will gain the skills/knowledge within this course to create your own camera script so you won’t need to use others (Not that there is anything wrong with that ).