Sign in to follow this  
babalak

need feedback for a 2d game engine

Recommended Posts

hi all. i'm working on a high-level 2d game engine with python. input, sound, graphics, etc. will be handled by one of the popular game libraries (pygame, pyglet, cocos2d), but my aim is to use it minimally and separate game logic from game library (at cost of performance). this game engine will be basically for top-down action or rpg type games, but with some tinkering it may be used for all kinds of games. i designed the engine on most basic level, and before starting to really coding, i wanted to ask you more experienced ones about it. (i made 3 different half-working engines in the last week, but i had to halt it each time because of some bad decisions i have made in the beginning). so every post is appreciated... here is a short explanation: - this engine runs object oriented, but without using patterns too much. just to the point that developer has optimum control and development time. aim here is not to make "perfect architecture" - game has a many scenes, which can be paused, switched, copied, killed. only one is active at a time. (example: scenes can be main_menu, ingame, quit_game, etc.) - each scene has several layers - each layer has several objects. everything in the game is an object. including all characters, items, even the floor tiles, text, or walls - each object has a parent (which may be None), position, angle, radius, scale, ai, flags, data, animation, animation_frame - a scene must have a camera object set. that means, displayed screen will be centered on this object. - an object may have on_screen property = 1, which means this is not on game area, but in front of camera. in this case, position is actual screen position - each image drawn is actually an animation, if its static, then its an animation with only 1 frame - there is an animation bank which is accessible in all engine. it gives correct images for objects depending on their animation and animation frame - so a possible animation value may be "object:player_walk", and animation_frame may be 4. this would mean currently shown image of this object is player_walk animation on 4th frame. - each object ai checks input and game variables, and makes a decision. remember, everything is a game object, and it has to have an ai. for example, a bullet should have an ai which says 'go forward' all the time. or a wall should have an ai which says 'do nothing' - ai makes a decision based on game variables, and runs an event. this event may be walk, die, hit, etc. but possibility of the event is never guaranteed. this means, object decides to run this event by its ai, but it may not be possible due to collision or some other limiting logic. - object event runs and makes the changes to object/world - after all objects runs object events, an output is made. its a low level description of scene, which consists of images and their positions only. this is given to library's drawing function. if you would like more info, i think this may give some more details: class game: #singleton configuration #type:configuration scene #type:scene current scene data #type:dict data, separated for each scene input #type:list, queue of new inputs. each input is deleted after read. fifo. output #type:dict, should contain only raw data with images, positions, scales, rotations, etc. (+sounds) def begin: #init def run: #main loop #get input #step scene #scene creates output def end: #exit class configuration: screen_size #type:tuple full_screen #type:bool resources #type:dict, images, sounds, etc. each 'name':'filename' class scene: #to be extended #scenes can be main_menu, game, pause_menu, level_selection, quit, etc. layers #type:dict camera #type:object, camera object should be set as a dummy object. and if it needs to follow an object (like player), its parent should be set to that object def begin: #init def step: #not loop, check inputs, do ingame things, give output #for each object, check if it has control (stunned object should not have control, or maybe in mid-jump player should not have control) #if it has control, run its ai, ai has access to everything #ai should run object_events, like move, die, shoot, etc. they may succeed or fail #object event has access to everything, and should set object and world variables according to the event #create output and update screen def end: #exit class layer: #to be extended objects #type:object class object: #to be extended parent #type:object or None position #type:dict, position on layer, not screen angle #type:int on_screen #type:bool, if true, position is on screen radius #type:int scale #type:float ai #type:ai flags #type:dict, damageable, walkable, visible, stunned, projectile, has_control, etc. (+collision flags, identifier flags, attack flags) data #type:dict, like hp, mana, class, etc. animation #type:animation animation_frame #type:int class ai: #to be extended #this should have ai functions which uses all game variables for decision #every object should have an ai, for example a bullet should have an ai which always says 'go forward' #player also should be an ai, which checks input for decisions pass class object_event: #to be extended #ai makes a decision, and runs event. but event may or may not be possible. like walk, shoot, die, etc. class animation_bank: animations #type:dict class animation: #static images are animation with 1 frame frames #type:dict loop #type:bool class frame: sprite sound scale #type:float angle #type:int class image_bank: #will only create each sprite once, after that it will be copied to use images #type:dict, file_name, image, image is graphic engines native object type to draw sprites #type:dict, name, sprite, sprite is graphic engines native object type to draw map #type:dict, sprite_name, (image_name, (position), (size)) -------------------------------- there are certain decisions, which may seem like a bad idea. for example, collision will be tested using objects position and radius. this means, all objects will have a circle collision box. this is to prevent asking image library for collisions (i think it should be made in game logic, regardless of image it has). in the future it should be possible to add multiple collision points and radiuses so it will not be so bad. another example for trivial design decision is: all positions are center coordinates of that objects. of course it will be translated to library's data of choice before being sent. so, what do you think?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this