|
tbradshaw posted:Consider pyglet. In conjunction with rabbyt
|
#
?
Jan 4, 2009 15:02
|
|
|
|
| # ? May 9, 2024 20:33 |
|
|
I think I might have asked this already.  I just finished writing a real time lighting engine in C++; I'd like to port it to Python for game logic. Is it more advisable to write it again in Pyglet or to build it on top of PyGame?
|
|
#
?
Jan 4, 2009 16:36
|
|
|
not a dinosaur posted:In conjunction with rabbyt I just gave this a cursory look through, but other than having some handy helper functions what benefit is it over using pyglet.sprites?
|
|
#
?
Jan 5, 2009 13:42
|
|
|
Lord Uffenham posted:I just gave this a cursory look through, but other than having some handy helper functions what benefit is it over using pyglet.sprites? It's way, way faster
|
|
#
?
Jan 5, 2009 16:42
|
|
|
I'm currently involved in the creation of a game development student club at my university. For a starter event, I've invited the other interested in a "weekend microgame challenge" where everyone is asked to create a simple game within a 48 hour period. I participated last weekend, and I ended up with a neat minigame I like to call "Fire Coming Out Of The Monkey's Head". It's a single player game for the PC and Xbox360 that uses Microsoft XNA framework to thrust players into the role of a stranded villager during a volcanic eruption. Players must stay clear of the surrounding lava and from the falling molten boulders that can push them away from safety. The game uses the Farseer Physics Engine for XNA. Here's some footage: http://www.youtube.com/watch?v=DSwD7ddqzw4 I couldn't get the sound to work in the video, my apologies on that. The game begins at an easy pace, but becomes incredibly difficult as the levels increase. Each level lasts 30 seconds, and with every level comes a great amount of boulders to avoid. It’s incredibly addictive. If the game’s development was to be continued, many things could be added to improve the overall experience. But to respect the idea of the challenge, I've closed the book on it. It was definitely fun and I cannot wait to do the next challenge. I was amazed on how I could make an enjoyable game in a short amount of time. Granted it's not that great, but this was my first finished game. Fun stuff.
|
|
#
?
Jan 7, 2009 01:11
|
|
|
Are there currently any Xbox360-supported framework that are available at a good price for me to use? My team has been using Torque's Game Builder stuff for some time for our casual titles on the PC, but quite recently, we've just got funding to do an XBLA title, and a 360 dev kit. I understand that the current XNA Game framework that comes on XNA Game Studio is catered for the XNA Community Games marketplace, so is this a correct assumption? Hence we've been looking at stuff like Torque360 from Garagegames for XBLA-licensed titles. Are there any others we should be looking at, as we're generally aiming at creating 2D-based side scrollers for our initial XBLA title. Torque360 was soemthing that came up for us, as we're familiar with the tools from previous products.
|
|
#
?
Jan 8, 2009 07:43
|
|
|
not a dinosaur posted:It's way, way faster Pyglet is a great library with a very comfortable and easy-to-use API. Its epic fail is that it is all in pure python, I have no idea why Alex decided to do it that way. It lets you distribute your source along with pyglet with no need to recompile anything on a per-platform basis, but honestly, you can accomplish the same thing by just distributing the proper pre-compiled .dll / .so files for each platform, or by letting setup.py do it for you. Jo posted:I think I might have asked this already. It is most sensible to create a Python wrapper for it, depending on what you are trying to accomplish and if your API is decently clean. Try ctypes or Py++. Pyglet or a Pygame OpenGL surface can create an OpenGL context for any old library (like Rabbyt) to render on. It's just a matter of how much you like the rest of the features of Pyglet vs. Pygame. nihilocrat fucked around with this message at 22:14 on Jan 9, 2009 |
|
#
?
Jan 9, 2009 18:00
|
|
|
Despite being a newbie to both coding in general and Python, I have been trying to make a game and would appreciate some advice. So far I've been using Pygame. This is a turn-based strategy game. The actors only move when a player individually selects them and directs them to move, so speed is not important. (If you have ever played Warhammer, this would be very similar.) So, I need a grid for the playing field. I need to make this gridded surface zoomable, in order to accomodate large battles. And because it will be zoomed, it needs to be scrollable. Each unit would able to move a certain number of grid boxes per turn. However, the major wrinkle is that the units will be able to turn 360 degrees and move at any angle when the player directs. So it will be the case that units will only be partially inside certain grid boxes. This leads me to think that the measurement to use is pixels. Meaning, give each sprite X amount of pixels worth of movement each turn. I am not sure how to maintain the integrity of "each unit gets 10 pixels to move with each turn" when I am zooming in/out on the battle map image and also scrolling around. Should I be using wxPython for this (The sprites do need to know when they are colliding, as that will mean melee combat)? Or, can anyone point in the right direction to look at otherwise?
|
|
#
?
Jan 11, 2009 23:21
|
|
|
Pixels are a terrible unit for pretty much anything gameplay related.
|
|
#
?
Jan 11, 2009 23:26
|
|
|
Avenging Dentist posted:Pixels are a terrible unit for pretty much anything gameplay related. Alright, thanks for the advice. As I said, I am a complete newbie at this. Can you suggest something that I should be looking at instead?
|
|
#
?
Jan 11, 2009 23:27
|
|
|
Make some meaningful in-game measurement unit and either define your world coordinates in terms of them, or convert to screen coordinates.
|
|
#
?
Jan 11, 2009 23:37
|
|
|
I'm a little confused on basic game class design... How should I design my classes so that certain classes can be drawn and other can't, etc? It seems like two options are using interfaces (eg. IDrawable, ISpellCasting, etc) or to use components (XNA seems to be designed this way I think). One other option is to have something like a DrawableEntity base class and descend from that but that seems to get tricky when you have an object that is both drawable and can cast spells versus one that cannot. The component architecture seems nice but then you need a way to communicate between components (eg. the spell casting component may need to tell the drawable component that the character is now blue-tinted). How is this accomplished? Also, how does collision detection fit into this? I've read some of the comments from the previous pages and they are helpful but I'm also looking for more opinions.
|
|
#
?
Jan 12, 2009 00:10
|
|
|
Avenging Dentist posted:Make some meaningful in-game measurement unit and either define your world coordinates in terms of them, or convert to screen coordinates. I think this is what is confusing me. As far as I understand it, screen coordinates in Pygame correspond to pixels. If I start at 0,0 on a Pygame display and I move position to 10,0, didn't I move 10 pixels? That is what I'm getting from docs like this: quote:Screen Coordinates I apologize for dumbing down the level of discussion in this thread, but I think it is the most appropriate place to ask. Thanks.
|
|
#
?
Jan 12, 2009 09:38
|
|
|
I'm not going to pore over the PyGame docs, but in general 3D rendering libraries (and PyGame uses OpenGL via SDL, so it's included) go through a "transformation pipeline". Basically, given a model (either 3D, or a sprite a.k.a. textured quad), you start with a set of coordinates. These are in "model space", that is, the origin is in the middle of the model (or something). To place this model somewhere, you have to supply a matrix transform, called the world transform, to put it somewhere in worldspace. From there, you need to transform the coordinates again into something based on the viewer/camera, called the view transform. From there, you continue on into the projection transform, which sets near and far clipping planes and does perspective. Then you transform it again into viewport coordinates, and draw it. There's more info about this here, but that's the idea. I am going to assume that PyGame supports some kind of transformation pipeline like this because otherwise, it's completely loving retarded and couples the position of the camera with the position of objects in-game. If Python doesn't support anything but screen coordinates, you can make a transformation pipeline yourself, which really is just doing some matrix multiplication on every relevant coordinate.
|
|
#
?
Jan 12, 2009 10:03
|
|
|
Vinlaen posted:I'm a little confused on basic game class design... Honestly I'd just forget about XNA Game components, they're more trouble than they're worth for someone without any experience. For your first question, in your Draw method, only draw the objects you want to draw?
|
|
#
?
Jan 12, 2009 10:13
|
|
|
MasterSlowPoke posted:Honestly I'd just forget about XNA Game components, they're more trouble than they're worth for someone without any experience. I'm just wondering if interfaces are best or components, or...
|
|
#
?
Jan 12, 2009 13:09
|
|
|
In general you don't want a huge amount of GameComponents, so that working out their behaviour with respect to each other is simpler. If you're going to use them, have a GameComponent that manages moving entities, rather than a GameComponent for each moving entity, for example. Yes, if you want a list of objects you're going to want to make them the same type. Deciding whether to use an interface or a base class to tie them together depends on whether you want to implement default behaviour (easier with a base class) and whether you want to have objects that fit into multiple categories, like an entity which is Drawable and Movable. If you want both, you can take a middle ground by having a base class that implements several interfaces and provides default behaviour for objects that fit into all those categories.
|
|
#
?
Jan 12, 2009 13:55
|
|
|
The other (and in my experience easier to work with) system to use "has-a" over "is-a" as in, an entity has a pointer/reference to a renderable object that can render itself, which means it'll cut down dramatically on both code and memory redundancy when the vast majority of your entities use the same mesh/plane/textures etc. It also allows you to be a bit more black-boxy when it comes to platform implementationy stuff like graphics libraries, since all your rendering code is contained in the rendering/scenegraph files of your code.
|
|
#
?
Jan 12, 2009 15:30
|
|
|
brian posted:The other (and in my experience easier to work with) system to use "has-a" over "is-a" as in, an entity has a pointer/reference to a renderable object that can render itself, which means it'll cut down dramatically on both code and memory redundancy when the vast majority of your entities use the same mesh/plane/textures etc. It also allows you to be a bit more black-boxy when it comes to platform implementationy stuff like graphics libraries, since all your rendering code is contained in the rendering/scenegraph files of your code. I was coming here to post exactly this. I believe that an IDrawable interface is generally a mistake. Here's a rough idea of how I usually set myself up: Every object has one or more drawable pointer objects (I usually call them Sprite). In the object's constructor, I get values for those pointers from SpriteFactory.GetSprite(name, params, etc.) My objects don't have a draw method at all, instead, when the factory fills a request for a new sprite object, it also registers that object with the drawing manager. The drawing manager maintains a list (or map, or whatever it needs) to draw its sprites in order. That way, my game objects don't have to implement Draw(). And my main game loop can just contain DrawingManager.Draw(deltaTime). It's very clean once it's up an running.
|
|
#
?
Jan 12, 2009 17:50
|
|
|
Where could I find a collection of art assets for games that are free to use? (Sprites, Backgrounds, etc.). I've known of https://www.lostgarden.com, but are there any other packs out there? I ask this because I'm going to propose a prototyping challenge to the student club I'm working with, and instead of sending them off in different directions I'd like to narrow the scope a bit.
|
|
#
?
Jan 13, 2009 05:58
|
|
|
I'm very interested in the production and assembly of video games, but I'm not a programmer at heart. I'm more an animator. While I do understand the basics of most languages, programming really is not that fun or appealing to me. How can I produce a small game using my 3D models without the use for Intensive programming? Not a giant "Half-life 2 mod ohmygod" thing, but something more akin to a 10 minute demo? I really want something where I can play around with all the stuff I make. I've lately been making small mods for Fallout 3, like buildings, guns, armor, and other crap, but it isn't satisfying enough. I want to be able to play around with the giant space ships, aircraft carriers, all of my trucks and tanks, all of my cars, and other various stuff too.
|
|
#
?
Jan 13, 2009 06:47
|
|
|
Since you're already modding, try having a look at Tribes 1 + 2, since they span the whole range from small personal equipment to huge vehicles. The only other game with a larger scale i can think of is Universal Combat. 
|
|
#
?
Jan 13, 2009 08:43
|
|
|
Bizarro Buddha posted:In general you don't want a huge amount of GameComponents, so that working out their behaviour with respect to each other is simpler. If you're going to use them, have a GameComponent that manages moving entities, rather than a GameComponent for each moving entity, for example. For example, I have a TextRenderComponent that renders some text. If I want five entities to render text then I need five TextRenderComponents, right? Right now I have a hash table for entities attributes for things such as current position, etc. The TextRenderComponent has a pointer to it's parent entity and looks up attributes using that. Although, I'm just fooling around with .NET and GDI+ and I am already having CPU issues. I'm maxxing a core on a Pentium D 3.4 GHz CPU even with 500 entities with TextRenderComponents attached to them. However, I'm just using .NET with GDI+ and nothing fancy like SDL or DirectX or anything. (I'm staying away from XNA for now)
|
|
#
?
Jan 13, 2009 13:21
|
|
|
SDL and DirectX are hardly fancy.
|
|
#
?
Jan 13, 2009 14:05
|
|
|
Fancier than GDI+, right?  One last question... Are there any good alternatives to XNA for .NET? I'd like to create a simple game that doesn't require the user to install any additional runtime packages (eg. XNA) besides .NET 2.0. I really like XNA but the runtime packages are the dealer breaker. I just want to distribute a zip file with a couple of DLLs and have the user go from there without any installation required. I've found SDL.NET (which hasn't been updated in over six months) and OpenTK (OpenGL). OpenTK seems nice since it appears to be actively updated, etc, but it doesn't provide any of the utility functions like XNA, etc.
|
|
#
?
Jan 13, 2009 14:27
|
|
|
Vinlaen posted:Are there any good alternatives to XNA for .NET? I use SlimDX for this reason. It's new, but it is very well written.
|
|
#
?
Jan 13, 2009 14:59
|
|
|
Thanks for the suggestion. However, it looks like it requires an end-user redistributable package just like XNA. (...or can you just include the DLLs with your executable and not require the redistributable?)
|
|
#
?
Jan 13, 2009 15:31
|
|
|
Why not just make an installer and have it install the dependencies?
|
|
#
?
Jan 14, 2009 00:48
|
|
|
Vinlaen posted:Thanks for the suggestion. It's under the MIT license. You can do whatever you want with it.
|
|
#
?
Jan 14, 2009 01:17
|
|
|
I'm working on my first game (DirectX/C++), and just starting to crack the issue of timing. I have a copy of "Tricks of the Windows Game Programming Gurus" that basically tells you to use GetTickCount() and that's the end of that. However, this book is a)old and b)aimed at beginners (of which I am one, admittedly). On the other end of the spectrum, we have this little number, which gets into polling multiple timer sources, determining tick rates, building a "voting" system with multiple timers, etc. in order to get a timer that you could use in quantum mechanics simulations. Or at least, that's what it looks like. My question is, which one is closer to what I'm likely to need? My game is going to be single-screen 2D without scrolling or anything fancy. The really, really accurate high-resolution timer solutions seem to be aimed at games where a few ms of error could royally screw things up, like in a networked game. Or is it a good idea to tackle this early on, if this is something I'm likely going to need to know down the line?
|
|
#
?
Jan 14, 2009 02:26
|
|
|
Sure someone will correct me if I'm wrong here, but I think the method of using high res timers has fallen out of favour bigtime since multi-core CPUs came along, which have problems with it, also CPUs that have dynamic speed throttling. You want to be using whatever API call it is that gives the number of milliseconds since some date... the equivalent of time.GetTime() or whatever.
|
|
#
?
Jan 14, 2009 13:28
|
|
|
DiscoSkinhead posted:I'm working on my first game (DirectX/C++), and just starting to crack the issue of timing. I have a copy of "Tricks of the Windows Game Programming Gurus" that basically tells you to use GetTickCount() and that's the end of that. However, this book is a)old and b)aimed at beginners (of which I am one, admittedly).
|
|
#
?
Jan 14, 2009 17:51
|
|
|
HauntedRobot posted:Sure someone will correct me if I'm wrong here, but I think the method of using high res timers has fallen out of favour bigtime since multi-core CPUs came along, which have problems with it, also CPUs that have dynamic speed throttling. OneEightHundred posted:Set timer precision with timeBeginPeriod (and close it with timeEndPeriod when your program exits), then use timeGetTime to get the number of milliseconds since Windows started. Null Pointer fucked around with this message at 18:27 on Jan 14, 2009 |
|
#
?
Jan 14, 2009 18:19
|
|
|
Null Pointer posted:QueryPerformanceCounter has issues with Windows XP and some AMD processors or BIOSes when the scheduler assigns your thread to a different core than the previous call. There's a hotfix for that (I think this is the one): http://support.microsoft.com/kb/895980
|
|
#
?
Jan 14, 2009 22:32
|
|
|
If you are crazy about timing then here's Stepmania's Win32 GetMicrosecondsSinceStart()/InitTimer() etc... on google code search which is pretty cool. It also has implementations for many other platforms.
|
|
#
?
Jan 15, 2009 03:17
|
|
|
very posted:If you are crazy about timing then here's Stepmania's Win32 GetMicrosecondsSinceStart()/InitTimer() etc... Without going into too much detail, the Programmable Interrupt Controller is programmed with a time duration - this is where the value you input into timeBeginPeriod goes. When the PIT rolls over this duration it fires off an interrupt. That interrupt is handled by the Windows kernel. When this happens a number of operations are performed: this is where all of the scheduling, context switching, synchronization, alertable thread and IPC magic happens. The kernel also increments a tick counter and adds the interval length to the system time - this is where the value you get from timeGetTime comes from! Reducing the periodic interval of the PIT will directly result in more context switches, more overhead and reduced performance system-wide. Just the interrupts by themselves - ignoring all Windows-related interrupt and synchronization overhead - will use up about 1.5% of your CPU's power at a 1 ms interval. Windows also has about a ~2000 cycle penalty for context switching, but I don't have exact information on how this is affected (I'm guessing around double the system overhead). The only reason to do this at all, ever, is if you're writing an application that absolutely needs 1 ms resolution for synchronization - which basically means if you're writing a video player. Never for any other reason that I can think of. Definitely not for a game. Fortunately Microsoft was smart enough not to give people direct control over the actual time increment value. Windows internally supports 100 nanosecond precision on the kernel's equivalent of timeBeginPeriod. Imagine how much worse this advice would be. Avenging Dentist posted:There's a hotfix for that (I think this is the one): http://support.microsoft.com/kb/895980 Vista's QPC automatically uses the HPET (High Precision Event Timer). It's higher-precision than the PMT, it's higher resolution than the PIT and it's multiprocessor safe unlike the TSC.
|
|
#
?
Jan 15, 2009 07:48
|
|
|
Thanks for all of the help with my other questions but now I have some about networking... I'm trying to create a "simple" networked/multiplayer 2D game and so I've been trying to a read a lot about networking principles, player synchronization, etc. However, it seems like most articles (eg. gaffer.org) tell you to send keyboard/mouse inputs to the server, have the server process them, and send the results back to the client. Why? Is this only done for cheat protection? What is the disadvantage to sending actual player position to the server and doing a sanity check? It seems like this way is better because then players will know their position even while moving and won't require interpolation or prediction. Keep in mind that I'm talking about a simple 2D game with different objects moving around, etc. I'm going to have a bunch of other networking questions I'm sure, and I thought about starting a new thread but hopefully you guys can help me out here.
|
|
#
?
Jan 15, 2009 14:17
|
|
|
Vinlaen posted:I'm trying to create a "simple" networked/multiplayer 2D game and so I've been trying to a read a lot about networking principles, player synchronization, etc. However, it seems like most articles (eg. gaffer.org) tell you to send keyboard/mouse inputs to the server, have the server process them, and send the results back to the client. For example, in your hypothetical 2D sprite based game, you can probably compress all of the relevant inputs (up/down/left/right/jump/fire) into a byte or two. Depending on the size of the play area, you may need anywhere from four to eight bytes just to send a single player's 2d position.
|
|
#
?
Jan 15, 2009 14:54
|
|
|
Does size really matter though? I can see if you're talking about a 3D FPS where there is constant, fast-paced action but in a Mario Brothers or Legend of Zelda game (simple 2D) then I'd assume that you only send position information when the player is moving. While the player is moving then constant updates are being sent but since it's only 2D it seems like the data wouldn't be all that bad. It also seems a LOT more simple to have players send position rather than input. By sending position then each player knows where their own character is currently located and doesn't need to wait for the server to tell them and thus you don't need client side prediction (or anything) for your own character. Sending inputs instead of position seems very complicated  I really appriciate the help though! I'm just trying to understand everything...
|
|
#
?
Jan 15, 2009 16:16
|
|
|
|
| # ? May 9, 2024 20:33 |
|
|
The problem with only sending positions is that you need to send EVERY SINGLE pixel change. That can, depending on your game speed, mean > 60 updates per second. That's a lot of poo poo to send. It's much better to have the client catch the input, send it to the server, perform the input locally as an estimate while the server calculates the gamestate changes, and then receive the coordinates on the next update from the server and adjust the local gamestate.
|
|
#
?
Jan 15, 2009 16:40
|
|