Game Development Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›622 »

Squido: May 21, 2005; Ask me about being a paedophile.

Danbo Daxter! posted:

If the camera is fairly static, have you considered having a 2D game with pre-rendered sprites (taken from 3D models) or is that not possible? It could save you a lot of trouble in the long run, but if that's not possible you could look into XNA.

It's certainly possible, we havn't got solid ideas down that need to be adhered to at the moment. Thinking about it however I think we'd probably prefer to do it in 3d as it would give us more options in terms of the camera and I think you could make it look alot nicer, i.e. in terms of lighting effects and perspective changes.

XNA looks pretty good from what i've seen of it and definitely something we're considering, especially with the 360 compatability.

# ? Jul 17, 2008 20:17

Adbot: ADBOT LOVES YOU

# ? May 9, 2024 21:31

Oae Ui: Oct 7, 2003; Let's be friends.

Ugg boots posted:

Pygame, then, is pretty much exactly what you want.

To throw yet another option out I'd recommend Pyglet. It lacks some features that PyGame has, like joystick input, but it's all OpenGL based and is much faster than PyGame. It also has no external dependencies which makes distribution a little bit easier. It's also easier to setup on a Mac because of that. Last I checked PyGame didn't have a Leopard compatible version. I've built some prototypes using it and it's been very easy to build binaries for Windows/Linux/Mac.

It also works very well with the Pymunk binding for the Chipmunk physics engine if you want to incorporate physics into your game.

# ? Jul 17, 2008 21:19

Sivart13: May 18, 2003; I have neglected to come up with a clever title

Oae Ui posted:

To throw yet another option out I'd recommend Pyglet.

Pyglet is definitely better than Pygame with regards to performance if you want to do something that updates large portions of the screen at once. If you want to interface with GL directly and actually be able to distribute your program as a binary without a pile of headaches, Pyglet is your only real choice.

Both libraries have their strengths and weaknesses, but given how slow Pygame develops and how its featureset is locked to that of the SDL I think Pyglet is going to keep skyrocketing forward.

# ? Jul 17, 2008 22:34

poemdexter: Feb 18, 2005; Hooray Indie Games!; College Slice

I've been using pygame for a roguelike I've started to develop and notice a little flickering everytime I update the screen. I might take a look at pyglet.

As for windows binaries, py2exe has been my best friend for showing off my work to my brother. All you have to do is write a small 10ish line setup.py file and then go to console with: "python setup.py py2exe"

It builds a distribution folder with all dependencies taken care of. My brother unzips the folder I send him and double click my .exe

# ? Jul 21, 2008 00:42

more falafel please: Feb 26, 2005; forums poster

poemdexter posted:

I've been using pygame for a roguelike I've started to develop and notice a little flickering everytime I update the screen. I might take a look at pyglet.

Either you're running that on a 386 or the problem is not with PyGame, it's with your code.

# ? Jul 21, 2008 08:49

StickGuy: Dec 9, 2000; We are on an expedicion. Find the moon is our mission.

It sounds almost like you're using a single-buffered mode.

# ? Jul 21, 2008 09:48

poemdexter: Feb 18, 2005; Hooray Indie Games!; College Slice

poemdexter posted:

Could be the code, but seriously, it's like 150 lines of code max. All I'm doing is placing strings on a surface, blit, and flip. Am I missing something to cut down on the flicker?

Figured it out. I was creating a new Surface everytime I wanted to print something to the screen. I moved my Surface initialization to my __init__ and reuse it to print to screen. Flicker gone.

quote != edit

# ? Jul 21, 2008 19:39

more falafel please: Feb 26, 2005; forums poster

poemdexter posted:

Could be the code, but seriously, it's like 150 lines of code max. All I'm doing is placing strings on a surface, blit, and flip. Am I missing something to cut down on the flicker?

I have some Python code that prints "hello world" 10 times but it's really slow, Python must be really slow.

code:

for i in range(1,10):
    print "hello world"
    for j in range(1,1000000000):
        pass

It's only 4 lines, it can't be the code.

I think this is a lot of the reason why people tend to think languages like Python and Ruby are so slow -- when complicated algorithms (regular expression matching, any string processing crap, etc) are hidden behind a really nice layer of abstraction, you don't realize when you're doing (for instance) n^2 operations n^2 times.

Here's a data point: the vast majority of gameplay code for Gears of War is either written in UnrealScript, expressed as data, or in Kismet, which is UE3's graphical scripting environment. You don't write AI in savagely optimized C.

# ? Jul 22, 2008 00:22

krysmopompas: Jan 17, 2004; hi

Oae Ui posted:

It also works very well with the Pymunk binding for the Chipmunk physics engine if you want to incorporate physics into your game.

According to the internet you can use Pymunk with Pygame, too.

Edit: As far as AI goes, generally I've seen it important to use lower level languages so that we can allow more "AI frames" per second to be executed. The quicker it goes, the faster it can react.

# ? Jul 22, 2008 01:01

Scaevolus: Apr 16, 2007

krysmopompas posted:

The needs of Epic in Gears are vastly different from the needs of the general industry. Go ask someone from Midway about native vs. unrealscript performance.

more falafel please works at Midway Chicago.

edit: :downs:

Scaevolus fucked around with this message at 02:58 on Jul 22, 2008

# ? Jul 22, 2008 02:19

krysmopompas: Jan 17, 2004; hi

Scaevolus posted:

more falafel please works at Midway Chicago.

That was my point, he should already know this.

# ? Jul 22, 2008 02:32

ValhallaSmith: Aug 16, 2005

Keeping with the scripting flame war. If you guys need more performance you could stick with c++ for the majority of your program and host an instance of .NET in the program for scripting. You can use CorBindToRuntimeEx to load it and run any AI etc scripts in there. Its pretty advantageous since the scripts would be executed rather than interpreted. Plus you can use various languages (C#/Python/Lua). I was considering using it for my own game. Although I am leaning to a more complex solution now using LLVM. Actually I'm not sure what the hell I'm going to do yet. For me its quickly turning into a redesign the way games are distributed thing.

ValhallaSmith fucked around with this message at 03:12 on Jul 22, 2008

# ? Jul 22, 2008 02:53

krysmopompas: Jan 17, 2004; hi

ValhallaSmith posted:

Keeping with the scripting flame war.

I'm not trying to contribute to a scripting flame war, I'm only taking issue with the assertion that "You don't write AI in savagely optimized C" since it's quite apparent that AI does in fact ship in many games in some savagely optimized low level language all the time.

krysmopompas fucked around with this message at 03:44 on Jul 22, 2008

# ? Jul 22, 2008 03:42

StickGuy: Dec 9, 2000; We are on an expedicion. Find the moon is our mission.

krysmopompas posted:

Christ, I thought all this Kynapse stuff I've been staring at had something to do with AI...no wonder these bugs never get fixed.

The needs of Epic in Gears are vastly different from the needs of the general industry. Go ask someone from Midway about native vs. unrealscript performance.

Kynapse is middleware, which completely changes the discussion.

And I realize the native vs. script performance, that was my point. It works for Epic because they have lots of technical designers and gameplay programmers who can write UnrealScript. We don't really use UnrealScript for gameplay for a number of reasons, but we use gobs of Kismet and some other homebrew stuff. It isn't fast, but it doesn't have to be, it's barely even on the list of things that should be optimized/parallelized/etc. My point was that it's generally unnecessary to make gameplay code crazy fast -- it's usually much better to make it so designers and gameplay programmers can quickly iterate on it, ideally without rebuilding every time they try something.

# ? Jul 22, 2008 19:06

more falafel please: Feb 26, 2005; forums poster

StickGuy posted:

I think you missed some of the point. Your example has terrible performance because scripting languages just can't handle huge numbers of operations that are actually in the scripting language. If they are hidden away in "savagely optimized C", you won't notice it that much. Python et al. are good for games because you can let them deal with a number of game objects as individual objects and let the hidden C/C++ deal with the hundreds of thousands of individual triangles and vertices.

No, my example has terrible performance because it's algorithmically horrible. My point was that a lot of times perceived performance issues in languages like Python come from the language/library obscuring the algorithmic complexity of what it's doing under an awesome interface. This was in reference to someone saying that PyGame was taking a huge and noticeable amount of time to draw each frame. It wasn't PyGame that was the problem, it was that he was essentially reinitializing the entire surface every frame.

# ? Jul 22, 2008 19:09

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Centipeed posted:

Also, why is OpenGL for Windows not available for download anywhere? There are a few links here or there, but they all seem to be third party links as opposed to links from whoever actually produces OpenGL for Windows.

The libraries and headers are licensed off to developers of development tools. Visual Studio comes with the OpenGL .lib files and headers, for example. You can get the latest extension headers here:
http://www.opengl.org/registry/

If you really need the main headers (i.e. GL.h), download Mesa, the headers are compatible. If you want the library, then I think Mesa includes it, if not, just use LoadLibrary, GetProcAddress, and wglGetProcAddress which you should be doing anyway.

If you mean the runtime, there is no standard one, implementations of the spec are produced and distributed by implementors of it. In other words, it comes with your video card drivers.

OneEightHundred fucked around with this message at 21:00 on Jul 22, 2008

# ? Jul 22, 2008 20:55

StickGuy: Dec 9, 2000; We are on an expedicion. Find the moon is our mission.

To get the OpenGL libraries and headers for windows you have to download and install the platform SDK from Microsoft. It's free, but it's a big install.

MasterSlowPoke posted:

I'm pretty much done with my 3d model importer, so now I'm off to the next step: the levels. Can anyone recommend a format and/or editor to use? Really anything could help, it's probably far more complex than I think.

Dealing with level editing is the biggest pain in the rear end of any 3D engine. If you want something easy to start with, then Quake 3 BSP is probably your best bet. It's a straight-forward format, the stock tools are very easy to extend, and the editor is reasonably functional.

Not to say it's good, Radiant is a train wreck of code and I try to avoid dealing with it as much as I can, and adding features to it is an exercise in frustration. That's not to say you can't make it dance to your tune if you try hard enough.

The alternatives are not good. There's a reason there are hardly any good level editors out there, and that's because it's extremely time-consuming, especially if it does convex solid editing and doesn't just do what most 3D engines do now, which is import a model from Maya and just use the editor to place lights, portals, and entities.

The only alternatives I'd even consider:
- Quark, which has a generally confusing interface and is written in Delphi and Python. Last time I tried, it was also buggy, with random crashes and geometry corruption.
- Getic, which looks promising and may be going open source soon
- BSP, which has a steep learning curve and doesn't have Quake 3 support, but does have a sane code base.

Don't bother with GtkRadiant, it's bloated as hell, is frustrating to even get to compile, and even more frustrating to modify due to severe overengineering. Don't bother with q3map2 either, it's also bloated and it's slow.

# ? Jul 28, 2008 01:21

Vinlaen: Feb 19, 2008

If somebody wanted to create a multiplayer tower defense game, what would the best option be?

I'm asking this because I think what I want simply doesn't exist which is a library/engine that provides collision detecion, particle effects, built-in GUI, and "automatic" networking support.

I'm mostly considering XNA but it seems like "Easy-Mode" DirectX with a handful of helper functions for managing input, etc, but it doesn't provide any kind of built-in GUI or networking support (other than allowing you to send reliable/unreliable order/unordered packets).

I'd really like some type of game library/engine that will let me create some sprites on the screen, move them around (providing collision detection) and keep everything in-sync across multiple players on the internet.

I guess nothing like this exists, huh?

What is the closest option available? I've actually purchased TGE (no idea why I did this), TGB (too difficult to do ANYTHING besides what is built-in espicially since the sourcecode is very advanced C++), and BlitzMax.

BlitzMax seems quite popular and not a bad choice (built-in windows, mac, and linux support!), but it doesn't have too many "intermediate/advance" features like using render targets or stencil buffers. It also doesn't have any sort of GUI and it forces you to use BASIC (with a tiny, tiny bit of OOP thrown in)

# ? Jul 28, 2008 03:19

MasterSlowPoke: Oct 9, 2005; Our courage will pull us through

Vinlaen posted:

multiplayer stuff

I don't know of anything out-of-the-box that does that, but for an XNA networking library I've heard of a lot of people using Lidgren.

OneEightHundred posted:

level editor stuff

I'm assuming you like Getic the most? You don't have anything good to say about Quark and BSP looks like it's far too ancient (it not being updated in almost a year is a bad sign too). Have you tried DarkRadiant? I've heard some good stuff about it.

# ? Jul 28, 2008 08:08

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

MasterSlowPoke posted:

I'm assuming you like Getic the most? You don't have anything good to say about Quark and BSP looks like it's far too ancient (it not being updated in almost a year is a bad sign too). Have you tried DarkRadiant? I've heard some good stuff about it.

I haven't tried DarkRadiant, but it's based on GtkRadiant which means I have low hopes for it. I haven't actually tried Getic yet, but it looks stable.

Quark may have resolved the major bugs since TGE uses it for a lot of stuff. It can't hurt to try it, but it wouldn't be my first pick.

Vanilla Q3Radiant is probably the best starting point if only because it works and it compiles without a problem. The options for level editors right now are not very good, but Q3Radiant gives you convex solid, parametric curve, and polygon mesh primitives which is enough for most purposes. The only thing it's lacking are portals, and you could hack those in with brushes if you really wanted to, and the entity editor is really bare-bones.

On the tools side, q3map IS very good, particularly the severely underutilized -vlight option, which basically lets you increase your lightmap resolution for free.

OneEightHundred fucked around with this message at 17:16 on Jul 28, 2008

# ? Jul 28, 2008 17:04

more falafel please: Feb 26, 2005; forums poster

Vinlaen posted:

and "automatic" networking support.

This doesn't exist, and likely never will.

# ? Jul 28, 2008 20:01

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Vinlaen posted:

and "automatic" networking support.

MasterSlowPoke posted:

I don't know of anything out-of-the-box that does that, but for an XNA networking library I've heard of a lot of people using Lidgren.

Holy crap, this looks like a slick library. I'll have to play with this and possibly tear out all the networking garbage I've written.

# ? Jul 31, 2008 14:49

tripwire: Nov 19, 2004; _{ghost flow}

Has anyone had any experience/luck combining Box2d (specifically the python bindings, pyBox2d) with pyglet? The guy who did the python bindings for box2d included a testbed that uses pygame, but since everyone keeps mentioning the various limitations with pygame I'm wondering if I should just use pyglet instead. What would I have to do differently if I wanted to package the binary for windows/osx/linux?

# ? Jul 31, 2008 22:03

SheriffHippo: Jul 18, 2002

I am trying to create a FPS-like mouse input system in C#.

*(This is a 2D top-down game. I do not need to do matrix/transform stuff)

I simply wish to record mouse movement input that is not inhibited by the constraints of the screen, or window.

For every mouse movement, the program should force the mouse back to the center X/Y point of the game. Each mouse movement is measured in terms of distance from the game's center point.

C# has some mouse functions that can get/set the cursor position, but they all exist in terms of the program window. (This won't do if one is playing in a window)

Because of this, I am importing win32 functions in C#. For example:

code:

[DllImport("user32.dll")]
public static extern bool SetCursorPos(int X, int Y);

This gives me more low level access to the mouse. I am now able to get and set the mouse position in terms of screen coordinates.

However, I am experiencing various problems.

I think I want the following rules to exist:

1. For every mouse movement, record the distance and duration of movement. Set the mouse back to center X/Y.

2. Hide the cursor. The cursor should be invisible even when it leaves the program window. I am currently unable to do this. Both C#'s Cursor.Hide() and win32's ShowCursor() do not keep the cursor hidden if it leaves the game window.

3. If the cursor happens to leave the game window, clicks should not register. I am having a problem with this too.

I don't know if I should:

A. Intercept all mouse input and keep it from passing to the OS.

Or..

B. Sample the mouse input often enough to keep it inside the game window.

Ultimately, I would like to use an OnMouseMoved event as opposed to a timer loop. I am attempting to use a mouse-moved event, but I am having problems with win32's SetCursorPos() function, when this event is fired. (Perhaps there is an issue that requires a Delegate. I am lost here.)

In conclusion, this has become retardedly hard.
Should I continue blindly trying things, or can DirectInput, XNA, GLUT, SDL, or some other library make this easier?

edit: I have written a Direct3D/C++ 2D game before, so C++ is an option. I would prefer to use C# though, as it is much easier to deal with.

SheriffHippo fucked around with this message at 10:26 on Aug 3, 2008

# ? Aug 3, 2008 10:06

MasterSlowPoke: Oct 9, 2005; Our courage will pull us through

SheriffHippo posted:

1. For every mouse movement, record the distance and duration of movement. Set the mouse back to center X/Y.

What API are you using? XNA? Managed DirectX? SlimDX? GDI (is there even GDI for C#)? If you're not using XNA, it would probably be best to use DirectInput for this.

SheriffHippo posted:

2. Hide the cursor. The cursor should be invisible even when it leaves the program window. I am currently unable to do this. Both C#'s Cursor.Hide() and win32's ShowCursor() do not keep the cursor hidden if it leaves the game window.

When you create a window there should be a flag to hide the mouse, I'm not quite sure as I haven't dealt with window creation in years.

SheriffHippo posted:

3. If the cursor happens to leave the game window, clicks should not register. I am having a problem with this too.

If you're sampling the mouse once a frame (1/60th of a second) this should never happen.

# ? Aug 3, 2008 10:42

StickGuy: Dec 9, 2000; We are on an expedicion. Find the moon is our mission.

The Windows API provides functions to "capture" the mouse so that a window receives all mouse events, even if they're generated outside of it.

# ? Aug 3, 2008 11:22

excitebike: May 18, 2003

SkankerX posted:

Fixed point is still necessary for most portables, including the iPhone (for OpenGL ES) and for the DS (for everything). Having a nice, type safe fixed point class which overloads the standard mathematical operators would go a long way in keeping other dependent code platform agnostic (typedef real numbers as float or fixed, depending).

This is from a few pages back, but I just wanted to point out that the iPhone is optimized for floating point throughout, it is not advisable to ever use fixed point on the iPhone. While this may be the case on other platforms, don't try to deal with fixed point. I'll even go so far as to say that if you are porting strictly fixed point code from other platforms, you need to rework it all to be floating point.

:science:

# ? Aug 3, 2008 12:26

SheriffHippo: Jul 18, 2002

MasterSlowPoke posted:

What API are you using? XNA? Managed DirectX? SlimDX? GDI (is there even GDI for C#)? If you're not using XNA, it would probably be best to use DirectInput for this.

I am not using a gaming API. The game consists of a Flash swf embedded in the form. I tried XNA, but it doesn't seem to use forms, and input relies on a built-in game loop, something that C# programs don't seem to have exposed.

MasterSlowPoke posted:

If you're sampling the mouse once a frame (1/60th of a second) this should never happen.

I've set up a timer that runs every millisecond. The mouse still escapes the window.

StickGuy posted:

The Windows API provides functions to "capture" the mouse so that a window receives all mouse events, even if they're generated outside of it.

I am having terrible problems with SetCapture(). Perhaps I will keep trying that.

edit: I've also been trying to do this in C++/MFC. I am having all the same problems. It seems that if anyone has ever done this, Google has decided not to record it.

# ? Aug 5, 2008 02:34

MasterSlowPoke: Oct 9, 2005; Our courage will pull us through

SheriffHippo posted:

I am not using a gaming API. The game consists of a Flash swf embedded in the form. I tried XNA, but it doesn't seem to use forms, and input relies on a built-in game loop, something that C# programs don't seem to have exposed.

Why not forgo the whole program and run your flash application in a web browser?

# ? Aug 5, 2008 02:44

SheriffHippo: Jul 18, 2002

I wish to have FPS-like mouse control and UDP support.

I've just posted this question in the .NET thread. I may be fairly close to a solution.

Solved. Please see solution here: http://forums.somethingawful.com/showthread.php?threadid=2262300&pagenumber=77&perpage=40#post347255779

(I used a C# class I found on CodeProject.com which uses a system hook to trap all mouse input)
http://www.codeproject.com/KB/cs/globalhook.aspx

SheriffHippo fucked around with this message at 04:16 on Aug 5, 2008

# ? Aug 5, 2008 03:04

Adbot: ADBOT LOVES YOU

# ? May 9, 2024 21:31

Annoying Jerk: Feb 19, 2004

I want to learn a programming language and learn about game development at the same time. I know a small amount of Java, and feel I have a basic understanding about some basic programming fundamentals. On the plus side, I have a strong background in math (Up to Vector Calculus). Can anyone recommend me a book or site that would teach me a programming language and game development at the same time? From reading around a little bit, it seems as if C# is the language to learn, and something about XNA (Not sure what this is), is this correct?

# ? Aug 6, 2008 03:18

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›622 »

Danbo Daxter! posted:

Ugg boots posted:

Oae Ui posted:

poemdexter posted:

more falafel please posted:

poemdexter posted:

poemdexter posted:

code:

more falafel please posted:

Oae Ui posted:

krysmopompas posted:

Scaevolus posted:

ValhallaSmith posted:

more falafel please posted:

code:

krysmopompas posted:

StickGuy posted:

Centipeed posted:

more falafel please posted:

MasterSlowPoke posted:

Vinlaen posted:

OneEightHundred posted:

MasterSlowPoke posted:

Vinlaen posted:

more falafel please posted:

Vinlaen posted:

more falafel please posted:

MasterSlowPoke posted:

code:

SheriffHippo posted:

SheriffHippo posted:

SheriffHippo posted:

SkankerX posted:

MasterSlowPoke posted:

MasterSlowPoke posted:

StickGuy posted:

SheriffHippo posted: