making a game-from-scratch tutorial.... help request

I spent a day trying to upload a wiki to my webspace in Panda Project, it didn’t end well. Right now I’m stuck with an error about safemode. Long story short, I made a new wiki on wikidot which is ad free. Check it out at: p3dgmfs.wikidot.com/ I already gave it a rough outline (which can be change, all suggestions welcome). I also gave it a basic forum which needs to be expanded.

I’d like to propose Smash Me Not as the first game in the series.

Game overview:

The player, a cube, tries to remain on a raised platform while avoiding cubes falling from the sky. The falling cubes will “cast a shadow”. The “shadows” increase in size the closer they are to the ground. Game ends if the player falls off the platform or gets smashed by a falling cube. Score increases with time alive.

Coding Introduced:
WASD character control:: Player control: w, s - forward, back; a,d - left, right; q,e - turn left, right.

Camera positioning:: camera remains at a fixed distance behind the player.

Loading a flat terrain and a model

Placing lights

Using a task to move objects and check for “collisions”:: if platform is from -5 to 5 along the x, and player’s X position is greater than 5, they fall (change Z)

Faking shadows

Making a splash screen:: not to sure about this one, maybe a large directButton with a image file (made in Gimp)??

Modeling a cube and exporting it

Just a minor niggle but shouldn’t the chapter on loading models come before moving the character about with WASD controls? Also, I know this may seem unreasonable after attempting to move twice but what about hosting this on Wikibooks instead? It could get a lot more traffic there, especially if the quality is high enough to get it a featured book status.

I’ll look into the wikibook. The list you’re referring to :

is not a list a chapters. Its a list a features (in random order) that would be introduced in the first tutorial/chapter

I’ve written some sloppy code for the game. I had to make some changes. I ended up using collision spheres. I also ended up using intervals for the motion. I will post the code on the wiki, eventually the code will be broken down into chunks and explained in detail. But first we need to work on it, rewrite it, expand it, discuss it.

I’m not at all sure that someone who’s never programmed a game before, even an incomplete one, should be encouraged to start off with a complete game. while they may well be capable of achieving it, I think that it will probably be significantly more beneficial to motivation and quite possibly success to start off with smaller projects. This way the tutorial series can provide “finished” products along the way, along, potentially, with the boost in confidence that this can provide.

I’m afraid that I disagree in turn. For a beginner (especially a beginner, I believe), I think that it’s important to get something that resembles gameplay - and in particular player control, I suspect - up and running as the first priority, after the basics of getting the engine up and running, and presumably an avatar loaded, of course. This gives the user of the tutorial something to play with quickly, hopefully encouraging them to continue, and reducing the chances of their losing motivation. At the earliest you might introduce a start screen once the tutorial-user has loaded some basic scenery and gotten a basic avatar moving, although I’m still inclined to leave it until later.

Additionally, I find that not having a start screen in place aids in early gameplay and prototype testing, as it allows one to jump into the testing more quickly.

Fair enough, but I don’t believe that this implies to any great degree the position of starting and closing screens in the process.

However, I if we want to aim this tutorial at people who have never created a game before, then I don’t think that as complete and (relatively) complex a game as you suggest is the best path to take.

In some of the cases that you list, yes, true. However, in the cases of start and conclusion screens, are they particularly hard to add in later in development when using Panda? As I recall, my experience outside of Panda has been that doing so is not a particularly great challenge, for reasonably simple functionality, at least. I’ll admit that I haven’t created a Panda menu or exit screen yet.

It can help to build with it in mind, however, I think. In that case, I would suggest having tutorial-takers create just the shell of the menu and exit functionality - no actual screen or input - and having the code just jump directly into the game and exit directly from it, with an explanation as to the reason for this, and the actual menu and exit code added in later.

Additionally, I feel that jumping directly into the game streamlines testing done during those parts of the development that lack the intervening menu.

Honestly, I think that these elements are probably better kept for a more advanced tutorial. They’re not called for in the scale of game that the first tutorial should probably, I think, produce. I still believe that this first tutorial should be kept simple, and not include much beyond starting the game, some simple gameplay, and concluding the game.

Again, by doing so we should find that taking the tutorial is a less lengthy task, producing a finished product more quickly, and, once again, hopefully keeping up motivation.

They are, however, probably very good topics for a subsequent tutorial, I think.

This I think that I agree with you on - I feel that it is possibly a good inclusion for the first tutorial.

Then it might be better to not touch anything more complex than starting up a game, loading some objects, moving about, some basic interaction, and exiting a game. Menu and ending screens might be included, but I would again suggest making them one of the later elements in the tutorial.

Simply put, don’t give someone that’s never programmed a game before too much to learn in their first game! They’ll probably have plenty to learn anyway.

Shouldn’t this be the other way around? :stuck_out_tongue:

While an increase in size could perhaps convey an increase in danger, I think that in this case it will more likely conflict with the player’s internal expectations of shadow mechanics, in which shadows should, I believe, grow smaller as they approach the ground.

Otherwise, I for the most part like your idea for a first game. :slight_smile:

No, it is more than that, it provides both a webspace and a wiki. One can add and edit pages like in any other wiki.
And yup, by default you’re the only one who can edit stuff. Its just a matter of throwing open ACL’s over a certain namespace, though, so just tell me and I’ll throw stuff open.
I could open up your personal wiki, but Im not sure thats a good idea, so I could add a separate namespace, if you want. Just give me a shout (e-mail/PM) if you want it.

PS. Oh, just read your other post. You shouldn’t try to upload your own wiki, the system automatically sets one up for you. More info is in your getting started page.

a complete game as a first tutorial will not necessary overwhelm readers. the chapter (game tutorial) can be structured in such a way as to build up the game slowly so that at first all the reader is doing is loading an environment, some lights, and then a character. As the chapter progresses more is introduced.

I started to re.format the first chapter and think more about the wiki. I don’t think there is a need to cover material that is covered by the manual. Loading an environment is already covered by the manual. I also don’t think its necessary to go line by line and explain the code. The manual does a great job of explaining the theory. The focus I was hoping for was on ‘how to use the code given in the manual to write a game’. Things the manual doesn’t touch upon.

Perhaps (if it’s a short and simple game, such as you suggested in your falling-blocks game), but even if it doesn’t, I think that during the early stages having relatively short intervals between “finished projects” is valuable in terms of motivation.

I very much think that it’s a good idea to give newcomers a short, fairly easy project, and thus hopefully a quick, fairly easy success, as their first project, in order to encourage them.

As to commenting line-by-line, true, that is probably superfluous, but on the other hand I wouldn’t suggest relying on readers having looked at the manual before tackling the tutorial, since the tutorial may well be the more attractive of the two.

I suggest small sections of code, preceded by text explaining what the code does, why you’re doing things the way that you’re doing them. Code comments should, I think, include section headings for various tasks and any suggestions, observations, etc. that you consider to be better-placed in the code itself (this is useful for strengthening the association between the two, for example, I think).

For example, you might have something like the below:

(I think that my information is correct, and the comment on the “while” line could probably kept to one line in a real tutorial; I’ve spread it over two for the sake of decent formatting in the code block. It might also be better to trim the preceding text a little for so short a code segment.)

...

Now we come to loading our various terrain objects.  Since these have no animations, we won't be creating Actors, and thus won't be using Actor.Actor.  Instead, we'll be using loader.loadModel.  You may notice that we keep calling loadModel, regardless of whether we've already loaded that particular model before.  This may seem inefficient, but in fact Panda already checks for us, and handles the matter in the background, meaning that models are in fact not reloaded where not called for.

def loadTerrainObjects(self):
     """Docstring goes here"""

     #Open a file using Python's file-handling commands,
     # read in the items, and load them.
     object_list = []
     file = open("cat.txt", "r")
     input = file.readline()
     while not input == "": #readline returns "" when it
                            # hits the end of the line
          new_object = loader.loadModel(input)
          object_list.append(new_object)
          input = file.readline()
     return object_list

One suggestion… IF this thread gets its own wiki I think the link should be added at the very first page because we are adding so many things to the “making a game from scratch” that a newby might get confused and start adding these code snippets in their own code…I think we should start saying “hey this is just an example” because some ppl, including myself sometimes, just expect code to work but forgets to setup the code for their/your own needs and specifications…just a thought for organization. Oh and good luck with the making the game from scratch :slight_smile: I would love to see a complete game on the three levels of beginner intermediate and advanced leves.

ONe more thing if we break the games down into those categories, I’de like the advanced section to include networking games together not only on the Lan but on the internet as well…the tutorial for networking panda is quite…well…odd :slight_smile: I’m working on a script that passes all networking codes onto another python program and that handles everything

I believe that BrianInSuwon is indeed working on that (and may in fact have it up and running; I’m not sure, I’m afraid). My impression is that this thread is a discussion thread for the tutorial wiki, not the tutorial in itself. ^^;

lol yeah I should have read/understood more clearly when ppl started talking about wiki it didnt dawn on me about hey maybe they’de organize it into a wiki? lol but where is the link?

The temporary website is at p3dgmfs.wikidot.com/

But there will be a wiki on the Panda Projects webspace soon.

We are working on the general tutorial and code structure now. I’m proposing to present and discuss individual functions/classes/tasks early in the tutorial and then the complete code at the end. Talking in depth about game making concepts that aren’t covered in the manual. From the code, hyperlinks can be made linking to the manual.

Here is a list of some of the functions I would pull out from the first game.
Character Control Code
Rain Making Code
Floor-Color Code
Camera Control Code

I was thinking about replacing the shadow code. Maybe place a grid on the floor, 8 by 8. And have the blocks/raindrops fall to overlap a grid cell (64 possible spots). When a raindrop is falling to hit a particular cell the color of the cell would change from red to orange, yellow, blue, green based on the height of the block. So the grid would be quite colorful and dynamic.

I uploaded the rough code for the game in the code snippetts section. No one has stood up and re.formated the code or made any suggestions to improve it. For this wiki/tutorial to really work, we need help from those that have actually made a game from scratch.

Your colour-based “shadow” idea sounds cool - I like it. :slight_smile:

My only qualm is that I’m not sure of how well it would work for people with one degree or another of colour-blindness. It may well still work if the pattern of apparent luminance changes is recognisable enough, but it might be a good idea to include some sort of secondary cue - a countdown of some sort, perhaps. Numbers might be too obvious, but having the cell change in size, or including some sort of filling or emptying bar might be a useful idea.

well i can help with importing and exporting I’ve had to change a few coding in the 3ds max area to get my stuff to work lol so if anyone has some questions about that I could maybe help them or find an answer

One other small suggestion for the creating the game from scratch idea…

  1. Make a format standard for your contributers

I say this because each programmer may have a different ‘style’, i think i can put it that way, of programmer their methods and getting their ‘style’ of results. Having a KISS methodology and keeping in mind that you are teaching beginners how to create something! KISS for those who dont know is Keep It Simple Stupid a method of well…keeping it as simple and least complex as possible.

  1. with that format comes commenting commenting and commenting your code

Again programing can be complex so why not break it down into small bite sized treats even if YOU know what your talking about WE may not so comment those lines and give us some input on what your thinking in your mind!

  1. The format albeit beginner friendly must also be efficient and usable in real life situations

now dont go crazy and create commercial quality code but create a coding method that is both simple and efficient to be ran many many times without having to rework everything overtime. I think OOP should be implemented early but thats just my opinion. Also, having usable and stable code, along with re usable coding, will teach foundational skills that will help in the long run!

  1. Concept to reality

this is something that I would love have came in contact with before I had to almost figure out 3ds max exporting scripts myself! What I mean by concept to reality is helping beginners with more than just programming. Having a tutorial on model exporting and creating animations is essential to games as well. Again the KISS and efficiency method should be used here! I wish someone would have said “hey, you dont need blender, 3ds max, and maya to convert your work”! But we all dont have blender abstractive skills or the money to fork out for maya but we can use 3ds max learner edition! Not saying Max is better but one must agree that its FAR more user friendly than blender…yet its the least supported by panda :frowning: sad really. Anyway…another solution is to have someone who has maya to maybe be dedicated to converting or help to convert models for someone.

sorry if this has been outlined before but you have to admit there is a LOT of long posts in here and reading all of them is quite the adventure in itself :slight_smile: I think this basically sums up what I would like to see in a wiki tutorial for beginners like myself

So is this thread dead?

lol looks like it! i think it may have moved to wiki! search through the posts and find the link!

Yeah but the wiki is just in the early construction phase. I don’t think anything been done on it for weeks.

I signed up to the site to help contribute material but so far the creator of the site is the only one that can do anything.

so what has this basically died then? I am a newb to Panda and coding so this sounded very promising, I think peoples biggest deterrent is exactly what your trying to fix, pieces of info not in a unified tutorial. I for example am a person who needs to know how things work not just “here use this and you’ll be fine” which helps long term so I know how to code stuff on my own basically. I really do think this is by far the most promising engine out there but the info needs to be more unified. Oh and I say blender over wings :stuck_out_tongue: (set it up w/ 4 windows and boom you got 3ds max lol)

Just an update. We never got the wiki set up on the Panda3D web space. I requested some web space and a user editable wiki . We got the web space but I never received any follow up to my request for an open wiki.

We have a wiki at p3dgmfs.wetpaint.com/

The biggest stumbling block was getting users with experience involved. I wrote some basic code for a game. But no one stepped forward to re.structure it.

There seems to be two levels of Panda users. Beginners and programmers with mad skills.