Title: SENSO - A fighting game Post by: onpon4 on June 23, 2010, 01:31:11 am I have just finished the first (incomplete) version of my first game in Python, SENSO. It's only 2-player right now, though I intend to add 1-player (among other things) soon. It's already fun to play with friends and relatives. :)
Download and more information can be found here: http://onpon.weebly.com/3/post/2010/06/senso-an-original-fighting-game.html (http://onpon.weebly.com/3/post/2010/06/senso-an-original-fighting-game.html) Title: Re: SENSO - A fighting game Post by: RTyp06 on June 23, 2010, 02:44:13 am I tired it. I thought it a bit strange to need an installer for such a simple game. I had to turn off Norton completely to install it on my PC.
I make games too, but I use Game Maker. I currently have 4 games uploaded at yoyo's site: http://www.yoyogames.com/users/RTyp06 And no you don't need to install any of my games, just choose run from the DL link (recommended) or install the plugin for instant play. Title: Re: SENSO - A fighting game Post by: onpon4 on June 23, 2010, 02:56:29 am I made it an installer just because I needed to compress it anyway (because of all the files). Sorry, I'll put it up as a ZIP next time. :)
Of course, though, if you have Python 3.1 and Pygame installed, you can just download and run the source code, which is only a single text file. Title: Re: SENSO - A fighting game Post by: RTyp06 on June 23, 2010, 03:28:32 am I just checked properties > file location from the desktop icon of your game ... Over 40 files?!? I see why you added the installer now.
My games have one file apiece. A single .exe file. Two of them create their own save game files and that is it. Man you should download the free Game Maker application and check it out. For noobs it has Drag n Drop programming that is so easy a caveman can do it and a robust coding language for the more advanced users. The Game Maker Language (GML) is almost identical to C++ syntax. Check out this video of a Game Maker game called Darkverse: http://www.youtube.com/watch?v=mkQtRCIacnM It shows just how powerful GM is. Title: Re: SENSO - A fighting game Post by: Alvarin on June 23, 2010, 04:14:48 am It refuses to run on WINE and closes without any error...
Title: Re: SENSO - A fighting game Post by: onpon4 on June 23, 2010, 02:36:43 pm I just checked properties > file location from the desktop icon of your game ... Over 40 files?!? I see why you added the installer now. My games have one file apiece. A single .exe file. Two of them create their own save game files and that is it. Man you should download the free Game Maker application and check it out. For noobs it has Drag n Drop programming that is so easy a caveman can do it and a robust coding language for the more advanced users. The Game Maker Language (GML) is almost identical to C++ syntax. Check out this video of a Game Maker game called Darkverse: http://www.youtube.com/watch?v=mkQtRCIacnM It shows just how powerful GM is. Those files are various parts of Python and Pygame required to run the game. They are necessary to run if you don't have Python installed. However, if you have Python 3.1 and Pygame 1.9, you can simply download and run the source code. P.S. I already have GM 8 Pro, but I prefer Python for various reasons, mostly because GM is so cluttered and restricted. Limitations on scripts is especially annoying, and the loading time is ridiculous. Not to mention, GM isn't cross-platform at all. It's OK for prototyping, but not really that good for anything else. I did make one game in GM before moving to Python, however, and you can take a look at it here (http://www.yoyogames.com/games/116764) if you're interested. It refuses to run on WINE and closes without any error... You should download Python 3.1 (python.org) (if you don't already have it; many Linux distributions come with some form of Python) and Pygame 1.9 (pygame.org), then download the source code. You don't need to compile it (and, in fact, it's not supposed to be compiled); this is one of the great things about Python. Once you have Python 3.1 and Pygame 1.9, just run senso_0.1.0.py as if it was an executable text file (or, you may need to tell the OS to run it with Python if it hasn't yet associated the file type, which is easy). The "Frozen" EXE download is more for layman Windows users who probably won't play the game if it looks "complicated". Unfortunately, I could only create a Windows EXE build, so users of other OS's just have to download and run the source code. Title: Re: SENSO - A fighting game Post by: RTyp06 on June 23, 2010, 05:42:01 pm Quote Those files are various parts of Python and Pygame required to run the game. They are necessary to run if you don't have Python installed. However, if you have Python 3.1 and Pygame 1.9, you can simply download and run the source code. P.S. I already have GM 8 Pro, but I prefer Python for various reasons, mostly because GM is so cluttered and restricted. Limitations on scripts is especially annoying, and the loading time is ridiculous. Not to mention, GM isn't cross-platform at all. It's OK for prototyping, but not really that good for anything else. I did make one game in GM before moving to Python, however, and you can take a look at it here (http://www.yoyogames.com/games/116764) if you're interested. I agree about the lack of cross platform but how is GM cluttered and restricted? All the resources can be neatly organized into seperate folders within the editor. Scripts can have up to 16 arguments and return a value just like a function in C++ so what makes Python's scripts superior exactly? GM games have a two meg overhead not exactly huge in the 21st century. After trying your bowser game, it looks like you used Hello's mario engine and modified it. Still it loads in under 2 seconds for me. Besides you don't have to preload resources in GM which is what usually causes longer loading times. All you have to do is uncheck preload and GM will pull the resources from the .exe as needed. Title: Re: SENSO - A fighting game Post by: onpon4 on June 24, 2010, 12:06:49 am I agree about the lack of cross platform but how is GM cluttered and restricted? All the resources can be neatly organized into seperate folders within the editor. Scripts can have up to 16 arguments and return a value just like a function in C++ so what makes Python's scripts superior exactly? GM games have a two meg overhead not exactly huge in the 21st century. - Scripts cannot return arrays - Many canned functions and variables are stuffed in, many of which are never used by experienced users simply because they're so simple. - Like C++, code is not well-organized. This is one of the biggest advantages of Python over any language. - Loading time is annoyingly long. - Since arrays can't be returned, many functions instead just return the first object, which can be annoying for collision detection. - GM can't do anything good with 3D. - Only DirectX (no SDL, no OpenGL, etc) That's the big list I can come up with right now. Not to mention, all the great things that Python has: - Lists - Dictionaries - many extentions (modules) - Etc... After trying your bowser game, it looks like you used Hello's mario engine and modified it. Still it loads in under 2 seconds for me. Besides you don't have to preload resources in GM which is what usually causes longer loading times. All you have to do is uncheck preload and GM will pull the resources from the .exe as needed. No, I didn't use Hello Engine. I have no idea how you could have drawn that conclusion, though I did take some MUSIC from Hello Engine. As for not preloading, that only accomplishes so much. Title: Re: SENSO - A fighting game Post by: RTyp06 on June 24, 2010, 02:21:27 am Well it's obvious python is better suited for your needs and I agree that GM has limits, just not the limits you're listing.
- Scripts cannot return arrays Scripts can easily manipulate arrays , ds_lists and ds_maps. - Many canned functions and variables are stuffed in, many of which are never used by experienced users simply because they're so simple. Uhh? If you mean there are redundant functions, perhaps. Which canned functions and variables are you referring to? if you mean all objects have variables like x,y coordinates or image_speed when you want to make an invisible object, unselecing the visible option disables those variables. - Like C++, code is not well-organized. This is one of the biggest advantages of Python over any language. Organization is up to the individual programmer. - Loading time is annoyingly long. Yes it can be "annoyingly long" if you design it that way. it mainly depends upon the resources you use. - Since arrays can't be returned, many functions instead just return the first object, which can be annoying for collision detection. Functions don't "return objects". ds_lists have a whole host of specialized functions for manipulating them and are recommended for their faster execution than common arrays. What this has to do with collision detection is beyond me and makes it sound like you really don't know what you are talking about here. - GM can't do anything good with 3D. LoL. Ok... http://www.yoyogames.com/games/120852 http://www.yoyogames.com/games/128004-magnetico - Lists GM has lists. - Dictionaries I don't know what a "dictionary" is in programming terms. - many extentions (modules) http://gmbase.cubedwater.com/ is one of many sites with many GM extensions. GM has extensions like room transitions and can utilize .dll files. Title: Re: SENSO - A fighting game Post by: Alvarin on June 24, 2010, 04:30:58 am Oh cut it out you two!
Seriously, didn't it occure to you that neither can convince the other one? Everyone has his own preferences and convenienses. If you continue like this your good internet relations will possibly be ruined, what for? Title: Re: SENSO - A fighting game Post by: RTyp06 on June 24, 2010, 05:07:41 am We were just having a friendly discussion here, no harm done. He's tried GM ,doesn't like it and Phython meets his needs better. Cool.
I'm leaving for vacation out of state tommorow, perhaps I'll DL Python and give it a try when we return. Title: Re: SENSO - A fighting game Post by: onpon4 on June 24, 2010, 07:43:34 pm Well it's obvious python is better suited for your needs and I agree that GM has limits, just not the limits you're listing. - Scripts cannot return arrays Scripts can easily manipulate arrays , ds_lists and ds_maps. - Many canned functions and variables are stuffed in, many of which are never used by experienced users simply because they're so simple. Uhh? If you mean there are redundant functions, perhaps. Which canned functions and variables are you referring to? if you mean all objects have variables like x,y coordinates or image_speed when you want to make an invisible object, unselecing the visible option disables those variables. - Like C++, code is not well-organized. This is one of the biggest advantages of Python over any language. Organization is up to the individual programmer. - Loading time is annoyingly long. Yes it can be "annoyingly long" if you design it that way. it mainly depends upon the resources you use. Let me just say this: having to work around obstacles is a horrible inconvenience. - Since arrays can't be returned, many functions instead just return the first object, which can be annoying for collision detection. Functions don't "return objects". ds_lists have a whole host of specialized functions for manipulating them and are recommended for their faster execution than common arrays. What this has to do with collision detection is beyond me and makes it sound like you really don't know what you are talking about here. Your GM days might have taught you that "objects" refers to special game classes, but the term is actually much more loose. In this usage of "object", I am referring to any set of immutable data, i.e. an integer, string, or class instance. I am of course referring to the collision detection functions in GM, which (if you take a look in the manual) return either the first detected instance or 0. There is also place_meeting(), but this only tells you if an instance of a certain class collides with the current class if moved to a particular location. - GM can't do anything good with 3D. LoL. Ok... http://www.yoyogames.com/games/120852 http://www.yoyogames.com/games/128004-magnetico GM, being already loaded with many canned functions, offers almost nothing for 3D, requiring (almost) everything to be done by hand. - Lists GM has lists. - Dictionaries I don't know what a "dictionary" is in programming terms. No, GM doesn't have lists. It has arrays, which are an ordered set of data all of the same type. Lists, on the other hand, can have multiple data types. You can also have lists of lists. Not to mention, the way GM handles arrays is quite questionable. Dictionaries (also called associative arrays) are a data type containing a collection of keys each associated with a certain value. For example, in python, I could create the following dictionary: price = {'bread':5, 'hamburger':2, 'crackers':2, 'pie':10} I can then call on price['bread'], which will return the value 5. EDIT: I've updated the game. More info here (http://tinyurl.com/2dvoya3). Title: Re: SENSO - A fighting game Post by: onpon4 on July 01, 2010, 10:43:15 pm Update, now 0.2.0. More info can be found on my blog post here (http://onpon.weebly.com/3/post/2010/07/senso-update-020.html).
Next update will be creation of a GUI for editing game text files, followed by creation of a much-needed AI. Title: Re: SENSO - A fighting game Post by: RTyp06 on July 05, 2010, 11:51:07 pm A couple of things to clear up.
Quote Your GM days might have taught you that "objects" refers to special game classes, but the term is actually much more loose. In this usage of "object", I am referring to any set of immutable data, i.e. an integer, string, or class instance. For me an object is derived from "object oriented programming" a format of data storage and manipulation with which most modern programming languages use. So from my point of view you are using the terminology incorrectly. http://en.wikipedia.org/wiki/Object-oriented_programming I only mention this because your usage of the term may be misunderstood by others in the future. You also seem misinformed about lists in GM. Lists can have different calsses of information contained within the data structure in GM because GM uses a universal variable structure that can contain any combination of strings, reals, floats, integers and booleans. Unlike say C++ where you have to define what a variable will hold before using it. C++ is much more efficient in this manner becuase you only set aside enough memory space to hold the variable data you intend to use, where GM sets aside the same (realitively large) amount of memory regardless of the type of information contained within the variable. Title: Re: SENSO - A fighting game Post by: onpon4 on September 07, 2010, 10:33:52 pm Senso has now been updated. Here is a link to the game:
http://onpon.weebly.com/4/post/2010/09/senso.html (http://onpon.weebly.com/4/post/2010/09/senso.html) From now on, that page will be updated with the latest download of Senso. I'm not able to modify my original post anymore. Are mods able to edit it? If so, can a mod please put the link above in the original post, and change the title from "SENSO" to "Senso" (un-bold the title)? It would be greatly appreciated! :) Anyways, I would very much appreciate some feedback. This version is MUCH better than 0.2. Title: Re: SENSO - A fighting game Post by: SweetSassyMolassy on September 08, 2010, 04:39:34 am For me an object is derived from "object oriented programming" a format of data storage and manipulation with which most modern programming languages use. So from my point of view you are using the terminology incorrectly. http://en.wikipedia.org/wiki/Object-oriented_programming I only mention this because your usage of the term may be misunderstood by others in the future. Wait..what? It seems like onpon is more correct in his interpretation. I thought the objects were the data structures or sets. I don't know what the data storage itself really has to do with the name. Title: Re: SENSO - A fighting game Post by: RTyp06 on September 08, 2010, 07:53:28 pm Object-oriented programming (OOP) is a programming paradigm that uses "objects" – data structures consisting of data fields and methods together with their interactions – to design applications and computer programs. Programming techniques may include features such as data abstraction, encapsulation, modularity, polymorphism, and inheritance. Many modern programming languages now support OOP.
That's straight from Wikipedia. Perhaps i'm not understanding your objection but onpon said: Quote Your GM days might have taught you that "objects" refers to special game classes, but the term is actually much more loose. In this usage of "object", I am referring to any set of immutable data, i.e. an integer, string, or class instance. Object doesn't refer to a special "game class" and an object, as I understand it, is not refferring to any particular variable which is what he seems to be saying an object is. An object is a collection or set of data manipulated by a single object name and that contains it's own coding instructions to manipulate the data held within the object. Game Maker, which I've been toying around with for several years now, is a scripting language based around object oriented programming (OOP). Objects in GM act much like objects in any modern programming language. GM is just less flexible and all objects in GM have alot of overhead because they are universal. So if I need, say, a simple object to draw a head's up display on the screen, there are alot of unnessicary variables not being used such as image_angle, image_speed or hspeed etc.. Title: Re: SENSO - A fighting game Post by: onpon4 on September 08, 2010, 09:37:26 pm Object doesn't refer to a special "game class" and an object, as I understand it, is not refferring to any particular variable which is what he seems to be saying an object is. Actually, you're off about what I said. I was saying that "object" refers to ANY class, not just classes which GM calls "objects". In fact, I was a bit too specific previously, because I stated that I was referring to only immutable data types, when in reality mutable data is still an instance of a class. For example, in Python, there is the int class (for integers), the float class (for floating-point decimals), the str class, the list class, the dict class, and so on. All of these are in fact objects. When I was talking about "returning objects", I was specifically referring to the canned collision detection functions, i.e. collision_point(), collision_circle(), and collision_rectangle(). The word I should have used is instance, because these functions return either 0 (if there is no collision) or the first instance ID, which is actually not an object, but an instance of (I believe) GM's float data type. What I was saying is that because these functions only return the first instance ID, and not a list or array of all instance ID's which pass the collision test, collision detection is MUCH more difficult. I encountered serious issues with half-solid platforms in Bowser Engine which could have been easily solved if I were able to act on ALL collisions, rather than just the first one the game detected. Of course, this problem could have been averted by using a custom script instead of the canned function, but the problem is, Game Maker's ONLY advantage is that it's supposed to do these things for you. Game Maker, which I've been toying around with for several years now, is a scripting language based around object oriented programming (OOP). Objects in GM act much like objects in any modern programming language. GM is just less flexible and all objects in GM have alot of overhead because they are universal. So if I need, say, a simple object to draw a head's up display on the screen, there are alot of unnessicary variables not being used such as image_angle, image_speed or hspeed etc.. Actually, GM isn't a scripting language or even a language at all; it's a special program designed to help you create games. GML (the Game Maker Language) is a scripting language. Python is also commonly used as a scripting language; in fact, I learned of Python when I saw users suggesting using Python as GM's scripting language instead of GML. "Objects" in GM don't really serve the same function as classes in a programming language. In GM, all objects inherit a base class which is designed to be the framework of any game object you might create. In addition to the many built-in variables you mention, this base class also does a lot of work for you that you don't even notice, such as being managed in the background (created, drawn/redrawn, collision detection) without you having to lift a finger, and having an established loop structure and a set of "events" for you to use. Therefore, objects in GM are made to serve a much more specific purpose than classes in, say, C++ or Python. Title: Re: SENSO - A fighting game Post by: RTyp06 on September 08, 2010, 10:37:48 pm Quote When I was talking about "returning objects", I was specifically referring to the canned collision detection functions, i.e. collision_point(), collision_circle(), and collision_rectangle(). The word I should have used is instance, because these functions return either 0 (if there is no collision) or the first instance ID, which is actually not an object, but an instance of (I believe) GM's float data type. Except collision_point(), collision_circle(), and collision_rectangle() are not objects or instances of objects. Those are called functions or procedures. You provide the arguments and they return a value after the arguments you provide have been run through an algorithm. They are designed so that you can simplify repetitive tasks in your code and don't have to recode the same algorithm time and time again. In GM you create your own functions with scripts. You pass arguments into the script and the script call returns a value. You are correct that those functions return the id of an object if that's what you mean. 0 for false, the returned id equals true. objects are just a collection of data or variables that relate to itself and are accessed through the object name.. object_tree object_tree.species object_tree.color object_tree.age object_tree.height So surely you can understand my confusion of your use of the word object previously. Title: Re: SENSO - A fighting game Post by: onpon4 on September 08, 2010, 10:48:35 pm Except collision_point(), collision_circle(), and collision_rectangle() are not objects or instances of objects. I hate to call your entire post pointless, but I never even implied that those were objects. The only way I can conceive you misinterpreting my post in this way is if you stopped reading right after the list of functions. I even used the word "function" in the next sentence. I was talking about the functions' return value. Title: Re: SENSO - A fighting game Post by: RTyp06 on September 08, 2010, 10:56:19 pm Yes I got that part but look what you are saying.
Quote For example, in Python, there is the int class (for integers), the float class (for floating-point decimals), the str class, the list class, the dict class, and so on. All of these are in fact objects. integer, float and str are classes assigend to variables. They indicate the value that those individual variables will hold. I've never heard them called objects before... Call me crazy I guess. I don't know what they are teaching you over at Python school. :) Title: Re: SENSO - A fighting game Post by: onpon4 on September 08, 2010, 11:07:10 pm Yes I got that part but look what you are saying. Quote For example, in Python, there is the int class (for integers), the float class (for floating-point decimals), the str class, the list class, the dict class, and so on. All of these are in fact objects. integer, float and str are classes assigend to variables. They indicate the value that those individual variables will hold. I've never heard them called objects before... Call me crazy I guess. I don't know what they are teaching you over at Python school. :) So, you can't assign an instance of your game's Player object to a variable? Strange... I remember doing that all the time when I used GM. On a more on-topic note: Has anyone tried Senso, perhaps with a friend? I haven't seen any feedback yet. Title: Re: SENSO - A fighting game Post by: RTyp06 on September 08, 2010, 11:19:26 pm Quote So, you can't assign an instance of your game's Player object to a variable? Of course you can. The variable will hold the id number of the object. That doesn't mean the variable itself is an object or instance of an object. Look, I was just trying to tip you that your use of the word might be confusing to others. That's all. Title: Re: SENSO - A fighting game Post by: onpon4 on September 09, 2010, 12:25:09 am Of course you can. The variable will hold the id number of the object. That doesn't mean the variable itself is an object or instance of an object. Have you ever used a language other than GM? Other languages don't store a number "id" referencing an instance. The variables point to the instance itself. Let me demonstrate with Python. Take a look at this script: Code: class foo(object): pass x = foo() print('Variable: {0}'.format(x)) print('ID: {0}'.format(id(x))) If we run this little script, we get this output: Quote Variable: <__main__.foo object at 0x02A0ABB0> ID: 44084144 Whoa! That doesn't look like a number at all, does it? But it gets even better: see, I can actually manipulate exactly what converting it to a string does! By adding the __str__ method to the class foo, as seen here: Code: class foo(object): def __str__(self): return 'Class foo(d!): ID - {0}'.format(id(self)) x = foo() print('Variable: {0}'.format(x)) print('ID: {0}'.format(id(x))) We get a different output: Quote Variable: Class foo(d!): ID - 44084432 ID: 44084432 This is because, in Python, what gets stored in a variable when you create an instance isn't a number, but a reference to the instance itself. In Python, what happens when you convert an instance into the str class is determined by the special __str__ method. On the other hand, if the variables only stored numbers (integers), printing the variable would always result in printing the "id" of the instance. Game Maker works a little differently. It actually stores the "id" of the instance. Not having seen the source code, I can only guess, but it looks like if a variable is a "real" (float) value, and is followed by a dot, GM assumes it must be a reference to an instance and searches for that instance. Look, I was just trying to tip you that your use of the word might be confusing to others. That's all. Being inaccurate causes MUCH more confusion than being accurate. Title: Re: SENSO - A fighting game Post by: ziper1221 on September 10, 2010, 12:51:50 am "real language" sounds a little harsh.
Title: Re: SENSO - A fighting game Post by: Lukipela on September 10, 2010, 08:36:14 am "real language" sounds a little harsh. Indeed. Onpon4, by all means continue debating programming languages, but tone it down a bit. Your last message contains a lot of attitude that can be left behind. Lets keep it friendly in here, eh? Title: Re: SENSO - A fighting game Post by: Novus on September 10, 2010, 10:01:36 am Good grief. I should have looked at this thread earlier. To make this discussion a bit saner:
All of the above are "real languages" in the sense that there are lots of people who use them commercially and academically. Never assume all programming languages work like your own favourite. Title: Re: SENSO - A fighting game Post by: onpon4 on September 10, 2010, 12:35:58 pm "real language" sounds a little harsh. Indeed. Onpon4, by all means continue debating programming languages, but tone it down a bit. Your last message contains a lot of attitude that can be left behind. Lets keep it friendly in here, eh? I'm sorry, you're right. I've tried to tone it down a bit. For the record, my point does not still stand.
Really? I've never heard that. In GM, objects are classes (the term "class" doesn't even show up anywhere in GM). In fact, newbies to GM are often scolded on the forums that an object is not an instance, and to stop referring to instances as objects. Title: Re: SENSO - A fighting game Post by: Novus on September 10, 2010, 10:14:12 pm
Really? I've never heard that. In GM, objects are classes (the term "class" doesn't even show up anywhere in GM). In fact, newbies to GM are often reminded on the forums that an object is not an instance, and to stop referring to instances as objects. Title: Re: SENSO - A fighting game Post by: RTyp06 on September 11, 2010, 06:22:10 pm Thanks Novus. It's nice when a knowledgable programmer shows us the error of our ways. My background comes from object oriented programming, Visual C++ which uses pointers to access an object's memory location and Visual Basic which uses "object variables" for the same purpose. Esentially I thought onpon was discussing the equivalent of object variables here.
Symantics aside, if you open up the hood and look at the nuts and bolts of what's going on behind the scenes of any language that has an object class, I'm willing to bet you'll see a similar scheme taking place. All object's are a collection of data that resides at a predefined memory location. Then you access that data through a pointer, variable or other sort of "handle". GM wasn't confusing for me at all. With GM an object is like any other resource such as a sound or a sprite. When you create an object in GM you are esentially building a resource which acts as a template. When you want to use an object in the game you do so by creating an instance of the object which will then behave according to the programming of the template. This is why they make a distinction between an object and instance of an object. |