Python Based 3d Game Engine

Tell me how I can make it more efficient, shorter. How I can make it adhere more to convention? Is there some stuff I'm doing that you would do in a better way?The main gist is that I create and populate a 2d-array with objects, and use PyGame to display it graphically. We have a Hero, who is a Character object, that can move around the grid. The hero, internally, keeps track of his coordinates.The update function scans the grid and checks for disagreements between the hero's internal coordinates and his place on the map (as a result of the move function). If there is a disagreement, it destroys the hero and resurrects him in the new location that agrees with his internal coordinates. Import random as randomimport pygame as pygamepygame.init #start up dat pygameclock = pygame.time.Clock #for framerate or something?

Still not very sureScreen = pygame.display.setmode(650, 650) #making the windowDone = False #variable to keep track if window is openMapSize = 25 #how many tiles in either direction of gridTileWidth = 20 #pixel sizes for grid squaresTileHeight = 20TileMargin = 4BLACK = (0, 0, 0) #some color definitionsWHITE = (255, 255, 255)GREEN = (0, 255, 0)RED = (255, 0, 0)BLUE = (0, 0, 255)class MapTile(object): #The main class for stationary things that inhabit the grid. StylingPython has its own official style guide (written by the author of Python) called. It has some things to say about your code. By the way, you can check your code against PEP 8 by installing the or by trying it. NamingIt's great to see that you have constants instead of using those numbers manually.

I am also happy to see that your constant names are ALLCAPS. I do notice, however, that some of your constants do not have that. For example, TileWidth is in PascalCase. I can see why you might consider it different: colors always have the same rgb values, but the tile width could change; but the important thing is that it doesn't change within the program. It starts as 20 and is always 20.Many of your variables are in PascalCase, but not quite all of them ( Map.update, for example).

Above all, be consistent. Okay, not above all; PEP 8 does mention that. It also recommends snakecase for method names and instance variables. That means, pretty much everything except constants and classes. Constants, as I mentioned before, are ALLCAPS. Classes are actually supposed to be how you have them: PascalCase. ImportingWhen you import random, you are importing a module called random.py that is somewhere in your Python path.

What is done with that module? It is called random. If you want to give a different name, you can do import random as rand, for example. You don't need to do import random as random. Your imports are still not how PEP 8 recommends:Imports should be grouped in the following order:. standard library imports.

related third party imports. local application/library specific importsYou should put a blank line between each group of imports.(Emphasis mine.) Comparisons to booleansAll that an if block needs for a condition is something that can be interpred as Truthy or Falsey. It doesn't necessarily need to be the actual boolean values True and False.

In fact, a common way to see if a list is empty uses that: if mylist:print('It is populated!' )else:print('Nothing in here.' )You see, the , , 0:self.row -= 1.I would expect a method with the name Location to return the location of the hero, but it prints it instead. It is a lot more versatile if you make it return it and let whatever calls it print it however it wants to. If you really want to print it inside this method, I would recommend a more appropriate name such as printlocation.Your pygame.draw.rect(.) lines are a little long.

I would suggest wrapping them more like this: pygame.draw.rect(screen, color, (tilemargin + tilewidth). column + tilemargin,(tilemargin + tileheight). row + tilemargin,tilewidth, tileheight)My preference is for the closing brackets to be on their own lines. That way, they serve as a sort of break between this group and the below lines. $begingroup$ @Kos: There are many places that give excellent answers to why you shouldn't use global variables. Just Google 'global variables are evil'. It's actually such a common search term that the words 'evil' and 'bad' are suggested when you type the rest of the search term.

A good explanation that I found is on. My mention of initializing the map object was because you are creating the map at the definition of the class. Your class becomes more easily reusable if you create the map when a map object is instantiated. $endgroup$–Aug 19 '16 at 20:38. $begingroup$ Thanks about clarifying the flip function! The dictionary is definitely something that I will implement. I planned on moving the check for boundaries into the collision check today.

Python 3d Game Engine

In the case of holding a key down, I have no idea how to make it so that the hero simply doesn't shoot across the screen when the key is pressed. I have to find a way to create some sort of time interval between the use of the move function when it is held down. Thanks alot for your response! $endgroup$–Aug 19 '16 at 15:17.

Python Game Engines

This is not so much an answer rather than an interesting suggestion for the 'reasoning of objects' moving within a 'shared environment'. The suggestion is AOP (Agent Orientated Programming). This has been widely used for modelling complex adaptive systems (SWARM).Essentially you create an encapsulated program (Agent) with its own logic about how to manouver in an environment (Grid world), and then launch it within an environment that it will share with other Agents. The beauty of this is that each Agent will judge where it will move next based on the environment it is in, the reasoning you can apply can be advanced or simple and different agents can have different properties (heterogeneous agents) and communication between agents is easy (an agent can broadcast propoerties of itself to change behaviour of surrounding agents. If your hero character is holding a weapon, other charaters may want to go to grid spaces further away!)You can also make agents have meaningful movement rather than them moving around aimlessly, without having to implement complex and computationally demanding functions (you can supply a grid space end point which may be a shop or somthing in your environment, and the agent will navigate the environment to get there whilst dealing with obsticals on the way!).I am not so familiar with python these days. More of a java person, for which there are really good AOP frameworks and Agent Development Environments (JADE, SARL, etc).

Python Based 3d Game Engine Download

But there is too.To give you an understanding of Agent based modelling, have a look at. NetLogo is an educational simulation software for agents with embedded rules.For something directed towards implementation checkout RepastPy Agents I think there is a Grid agent already made with it;).