|
No Safe Word posted:Um, anything that can produce Barkley Shut Up and Jam: Gaiden is good in my book Pretty sure it was a person that produced that game, not a computer program!!
|
#
?
Apr 27, 2010 00:51
|
|
|
|
| # ? May 12, 2024 15:26 |
|
|
No Safe Word posted:Um, anything that can produce Barkley Shut Up and Jam: Gaiden is good in my book You could write it in Basic, that doesn't mean Basic would be a good choice.
|
|
#
?
Apr 27, 2010 01:18
|
|
|
Relax guys, it was a joke
|
|
#
?
Apr 27, 2010 03:06
|
|
|
Game Maker is as perfectly valid a tool in testing game design ideas as any other way of getting it done, if all you're interested in is design and you accomplish what you want to accomplish in Game Maker or MMF2 or whatever, then what does it matter that you didn't learn how to do it manually? I mean obviously if you want a job in the industry as a programmer it's not going to help but he (and like 90% of the people who ask about Game Maker) express no interest in that. There seems to be an idea perpetuated heavily here that you have to learn every caveat of every area of game programming before you can create anything more interesting that pong. When some of the most interesting game design is coming from people like Cactus and the experimental gameplay project where the entire point is end result over method, inferring that you should do it in a particular way despite it taking considerably longer and more than likely not working as well is retarded in my opinion. I'm not sure if it's programmers trying to validate their career choice or what but the attitude is usually 'Game Maker is cheating' and not based on the limitations of those products (because they're usually alot less limited than you think). That said if you want a job in the industry as a programmer you obviously need to do it the proper way, but transitioning from GML to C# to C++ is probably pretty smooth (I don't know i've never used Game Maker).
|
|
#
?
Apr 27, 2010 11:17
|
|
|
That has been my problem with trying to develop a game. I'm a VB.NET developer (but with lots of experience in C# as well) and XNA is very interesting but I have absolutely no interest in becoming a full-time game programmer nor do I find it fun to program a game engine. (eg. writing an input manager, collision detection routines, etc) I just want to make fun little games. That's why that tools (engines) like Game Maker and Unity3D are so appealing because they handle a lot of the "boring" parts for you. However, the trade-off is that you are limited in what you can do. For example, I really want to create a multiplayer isometric type of game but it seems very difficult unless you write the engine yourself. Anyways, it seems like if you just want to make a game and have no experience in the backend details then XNA might not be the best choice.
|
|
#
?
Apr 28, 2010 15:11
|
|
|
It depends on what tool you use, Unity is more of a typical middleware solution for professional developers than a Klik'N'Play style thing and can do anything that you want to implement in it while providing a series of handy helper classes, while Game Maker tends to do more stuff for you and therefore limit what you can do within the existing framework. XNA is essentially the same thing but does less (and therefore has more freedom) and doesn't come with its own scene manager and level editor. People can argue all day about what constitutes 'real' games programming, but unless we're all meant to write in ASM and manually support different processor extensions I don't really know where that concept came from. Again though for those interested in a career in the industry a good understanding of computer science and current C++ APIs is essential, atleast for the next few years.
|
|
#
?
Apr 28, 2010 16:41
|
|
|
Vinlaen posted:That has been my problem with trying to develop a game. If you like C# you should have a look around for some XNA engines or libraries. There's physics engines(Farseer), and more general ones like Ice Cream(http://icecream.epsicode.net/) which is in beta but obtainable if you join their IRC channel. This will probably improve in the coming years, XNA is getting very popular.
|
|
#
?
Apr 28, 2010 17:04
|
|
|
That IceCream engine actually looks really neat... is it still being developed? The news page seems to be old and the videos page is even older (2008). Are there any other good 2D engines for XNA? (besides FlatRedBall, which I already know of)
|
|
#
?
Apr 28, 2010 17:25
|
|
|
Anyone recommend any good books on XNA? I know a lot of material is available free online, but I really enjoy the format of a book. Plus my g/f gave me a $25 gift card to B&N. 
|
|
#
?
Apr 28, 2010 20:50
|
|
|
Iron Squid posted:Anyone recommend any good books on XNA? I know a lot of material is available free online, but I really enjoy the format of a book. Plus my g/f gave me a $25 gift card to B&N. If you are reasonably confident with the basic concepts of game development and C#, then the Reimer's book isn't bad. It's mostly a "How do I .... ?" kind of book, where he leads you things like shaders, height maps, camera control, etc.
|
|
#
?
Apr 28, 2010 21:46
|
|
|
Iron Squid posted:Anyone recommend any good books on XNA? I know a lot of material is available free online, but I really enjoy the format of a book. Plus my g/f gave me a $25 gift card to B&N.
|
|
#
?
Apr 28, 2010 22:22
|
|
|
Vinlaen posted:That IceCream engine actually looks really neat... is it still being developed? The news page seems to be old and the videos page is even older (2008). Yeah they're still working on it, they just don't seem to update the site at all. Here's a thread on the XNA forums about XNA engines. http://forums.xna.com/forums/t/12882.aspx
|
|
#
?
Apr 29, 2010 00:28
|
|
|
PDP-1 posted:I'd suggest Learning XNA 3.0 by Aaron Reed, published by O'Reilly. It goes through all the major features in a logical way, first building up a 2D game and then moving to 3D. I'll take a look at that. Do most XNA books presume a working knowledge of C#?
|
|
#
?
Apr 29, 2010 07:18
|
|
|
Iron Squid posted:I'll take a look at that. Do most XNA books presume a working knowledge of C#? Yes, you'll at least need to have basic programming knowledge. You said you know a little C++, so if you retained some of that you should be fine with a book like Aaron Reed's XNA 3.0.
|
|
#
?
Apr 29, 2010 07:49
|
|
|
jb7 posted:Yes, you'll at least need to have basic programming knowledge. You said you know a little C++, so if you retained some of that you should be fine with a book like Aaron Reed's XNA 3.0. O'Reilly makes a book on C# called "Head First C#" (or something like that) that looks interesting. I'm thinking having a stronger knowledge of C# couldn't hurt.
|
|
#
?
Apr 29, 2010 18:52
|
|
|
If you've got programming experience, I highly recommend Jesse Liberty's Programming C#. I've always found the Head First books too cutsy for their own good.
|
|
#
?
Apr 29, 2010 22:31
|
|
|
I'm writing a tile-based game using GDI that BitBlts hexagonal tiles onto the screen, however it's too slow when I try to BitBlt a whole bunch of tiles at once, so I've been pre-drawing chunks of the screen and pasting those onto the screen. However, my algorithm right now just pre draws the entire map and saves chunks into several bitmaps using CreateCompatibleBitmap. Should I be worried about running out of video memory or will those go into main memory instead?
|
|
#
?
Apr 30, 2010 01:34
|
|
|
Is there a way to get z-buffering to work when drawing something in wireframe mode? I have a terrain generator that works fine when drawing filled triangles, but when I turn on the wireframe mode I get this: As you can see the nearest hill is not blocking stuff behind it. What I want is to have the depth test notice that there is a triangle defined that is closer than the background stuff and block the background out. I suppose I could draw everything as solid black triangles and then re-draw the wireframe over it, but it seems that there has to be a better way. VVV Thanks for the advice. Guess that's what I'll have to do then. PDP-1 fucked around with this message at 16:33 on May 1, 2010 |
|
#
?
May 1, 2010 15:38
|
|
|
Sorry, that really is the best way (draw solid black and then wireframe). The depth test is only evaluated for a pixel when it's touched by a primitive, drawing outlines isn't enough.
|
|
#
?
May 1, 2010 15:52
|
|
|
Dijkstracula posted:If you've got programming experience, I highly recommend Jesse Liberty's Programming C#. I've always found the Head First books too cutsy for their own good. I second this as a good introduction to C#, especially if you have prior experience. Don't pick up Learning C#, also by Liberty, because it is literally just the first half of Programming C# and you don't want to waste your money on half of a book. brian posted:Game Maker is as perfectly valid a tool in testing game design ideas as any other way of getting it done, if all you're interested in is design and you accomplish what you want to accomplish in Game Maker or MMF2 or whatever, then what does it matter that you didn't learn how to do it manually? I mean obviously if you want a job in the industry as a programmer it's not going to help but he (and like 90% of the people who ask about Game Maker) express no interest in that. Even if you do not wish to be a professional programmer, if your intention is to be in the games industry it's probably important to assess how similar Game Maker is to tools for game design used in the industry. If you're not someone interested in working as a professional designer, you'd want to evaluate it based on how well it can allow you to achieve your specific game design goals. I haven't used Game Maker either, although I did look at some of the tutorial documentation. From what I saw of the interface for designing gameplay mechanics, their claim that you're not using a programming language is bogus. This is about as thin a visual wrapper for programming as you can get:  Using that tool for most of your work would be fine for small prototypes and simplistic games, but I think it would rapidly become a pain to use for the sorts of complex, experimental game designs you mention. Also on that, your point about Cactus is completely irrelevant, and any successful studio should be choosing results over method for the sake of it. Hamled fucked around with this message at 05:18 on May 3, 2010 |
|
#
?
May 3, 2010 04:57
|
|
|
haveblue posted:Sorry, that really is the best way (draw solid black and then wireframe). The depth test is only evaluated for a pixel when it's touched by a primitive, drawing outlines isn't enough. Better way:
This is known as a z-prepass. Most games do this even when rendering non wireframe because a lot of hardware supports fast-z which means that if you have no fragment shader enabled writing to the z-buffer is much faster. This in turn allows more pixels to get culled when you are doing your color passes so there is less total processing required.
|
|
#
?
May 3, 2010 05:02
|
|
|
Hamled posted:Using that tool for most of your work would be fine for small prototypes and simplistic games, but I think it would rapidly become a pain to use for the sorts of complex, experimental game designs you mention. Also on that, your point about Cactus is completely irrelevant, and any successful studio should be choosing results over method for the sake of it. It's exactly as you say, plus more. GM actually has a C-style scripting language built into it as well that can be used instead of the pictured drag-n-drop instructions. Learning how to make simple games with drag-n-drop, then transitioning to more advanced stuff in GML, then finally moving away from GM and towards C++ / SDL and C# / XNA is how I learned programming, and it really is a smooth transition. GML is pretty powerful. Implementing stuff like A*, perlin noise, etc isn't really any easier or more difficult than doing it in any variation of C.
|
|
#
?
May 3, 2010 18:17
|
|
|
GameMaker based its scripting language on C? 
|
|
#
?
May 3, 2010 18:18
|
|
|
I'm not sure I see what's wrong with that. GM does a poor job of introducing object oriented design, and once you're used to real oop then it becomes a lot more frustrating to use, but for learning how to program and getting a prototype thrown together quickly it's a fantastic program.
|
|
#
?
May 3, 2010 18:33
|
|
|
I think he's laughing because it's not really like C at all, aside from minor things like curly braces.
|
|
#
?
May 3, 2010 18:53
|
|
|
Mustach posted:I think he's laughing because it's not really like C at all, aside from minor things like curly braces. That and also the idea of scripting in actual C is hilarious.
|
|
#
?
May 3, 2010 19:11
|
|
|
Avenging Dentist posted:That and also the idea of scripting in actual C is hilarious. Its not actual C, just similar to it. Its not the first time a scripting language similar to C has been implemented. You should look up Unix's csh sometime! 
|
|
#
?
May 3, 2010 19:47
|
|
|
Iron Squid posted:Its not actual C, just similar to it. Its not the first time a scripting language similar to C has been implemented. You should look up Unix's csh sometime! QuakeC also comes to mind.
|
|
#
?
May 3, 2010 19:49
|
|
|
Iron Squid posted:Its not actual C, just similar to it. Its not the first time a scripting language similar to C has been implemented. You should look up Unix's csh sometime! csh bears almost no similarity to C. Being "more" like C than sh doesn't make something even remotely C-like. Also csh/tcsh are terrible. Also QuakeC isn't something I'd hold up as a standard of what's good from a language perspective either.
|
|
#
?
May 3, 2010 19:56
|
|
|
Avenging Dentist posted:csh bears almost no similarity to C. Being "more" like C than sh doesn't make something even remotely C-like. Also csh/tcsh are terrible. Agreed, but I'm not sure I see your point?
|
|
#
?
May 3, 2010 20:05
|
|
|
Hubis posted:Agreed, but I'm not sure I see your point? That trying to do common scripting tasks in C would be needlessly painful due to the language's simplicity?
|
|
#
?
May 3, 2010 20:13
|
|
|
QuakeC is compiled to bytecode or actual binaries you buffoons
|
|
#
?
May 3, 2010 20:18
|
|
|
heeen posted:QuakeC is compiled to bytecode or actual binaries you buffoons Python is compiled to bytecode too therefore it must not be a scripting language! 
|
|
#
?
May 3, 2010 20:25
|
|
|
Avenging Dentist posted:That trying to do common scripting tasks in C would be needlessly painful due to the language's simplicity? What kind of common scripting tasks are you referring to? It's worth noting that QuakeC was not replaced in later generations by Javascript or Lua or Python, but rather by full-fledged C DLLs (in both Quake2-through-IdTech4 and Source) so the implication seems to be that Carmack/Gaben felt it wasn't C-like enough rather than too C-like. I guess (unsurprisingly) the question of the appropriateness of a particular language has a lot to do with your definition of use-cases. Despite those above cases, a lot of developers working on serious AAA titles like Bethesda, Epic, and Bioware make heavy use of full fledged scripting languages.
|
|
#
?
May 3, 2010 20:45
|
|
|
Hubis posted:What kind of common scripting tasks are you referring to? Pretty much any numerical programming is at least moderately painful in C, as is object-oriented stuff (especially anything to do with runtime dispatch). One of the things C is worst at is rapid prototyping, and that's especially important for the non-engine parts of a game, since the behavior of game elements can change a lot during development. Hubis posted:It's worth noting that QuakeC was not replaced in later generations by Javascript or Lua or Python, but rather by full-fledged C DLLs (in both Quake2-through-IdTech4 and Source) so the implication seems to be that Carmack/Gaben felt it wasn't C-like enough rather than too C-like. All of the languages you suggested were extremely young when Quake 2 was released (Python was the oldest, but I don't think I'd recommend it for games), so it's no surprise that they didn't use one of them. I'd say the implication is more that "maintaining your own language takes too long", especially since using C would give you the benefit of decent optimizing compilers. Keep in mind QuakeC is the language where if not(foo) is slightly faster than if(!foo). Besides, it's not like games are at the forefront of language use/design. id Tech 3 still used C, despite Quake 3 coming out after C++ was ISO standardized. It doesn't pay to try out the latest, greatest language unless you have some evidence as to why it's better. Even now, the only language I'd actively recommend would be Lua, though Stackless Python might be doable too (I'd be more inclined to recommend that if CCP actually released their changes to the public).
|
|
#
?
May 3, 2010 21:07
|
|
|
Here's some context to what scripting looked like in 1999: Your best scripting languages at the time were probably Lisp offshoots, Tcl, and maybe Perl. Or maybe even PHP! Keep in mind that with ANY of these general-purpose languages, even today, any vector math "op" requires multiple ops and a heap allocation every single time which was a substantial performance hit. Basically everything that's "good" today sucked then for other reasons too: Lua had only had closure support for a year, would not get For loops for another year, and wouldn't get lexical scoping, booleans, or metatables for another 4 years. SpiderMonkey wasn't public (Mozilla Foundation wouldn't exist for another 4 years) and JavaScript sucked pretty hard at that point anyway. Python 2.0 (the one with the garbage collector) wouldn't exist for another year, and it would be more years until they pulled their heads out of their asses and started focusing on making it embeddable instead of telling developers that they should make their app run from inside a Python context. So basically, scripting languages were so abysmal and slow at that point. The only real options were C++, or rolling your own scripting language (more likely compiled language), which several companies (Epic, Blizzard) did. In fact Epic's gigantic Java ripoff was almost revolutionary at that point. id Tech 3 used C for a very simple reason: Because LCC lets you dump 32-bit IL code using its "generic" backend, and with exactly one line of code modification (which amounts to emitting a RET statement at the end of functions), it comes out in a format that's actually usable as a VM language. So basically the hard part was already done, and it gave them a way to write high-performance code that was completely portable unless you hosed around with byte order bullshit. Beyond that, C++ was probably your best bet, in fact basically every Quake 2 and Quake 3 licensed game used C++ gamecode, as did all of Valve's games. The landscape has changed a LOT since 1999, in particular the performance penalty for using scripted languages is no longer as huge when CPU is being hammered by rendering and physics instead. Also id Tech 4 did have a scripting system which it used for a lot of things, though it was admittedly pretty weak. Valve is still trying to catch up, but hey we got Squirrel scripting in L4D2 so maybe there's hope!! OneEightHundred fucked around with this message at 05:48 on May 4, 2010 |
|
#
?
May 4, 2010 05:23
|
|
|
How do you feel about the current state of scripting? I am disappointed with many of the 'mainstream' options we have. I find that when running them from an embedded context you often need to fall back to printf's to debug and that is very frustrating. I think what unity 3d is doing with mono is pretty good. In their next version they will have proper debugging of their script environment. In general though I'm not totally sold on the whole 'scripting makes things easier' front. Sure you may save some time compiling but I think it takes much longer to track down and fix bugs.
|
|
#
?
May 4, 2010 05:47
|
|
|
Strumpy posted:How do you feel about the current state of scripting? This is ignoring the fact that you can run arbitrary code while the game is running, which is a major boon for debugging. Mono has some major advantages especially in the performance department since it can put vectors on the stack instead of heap allocating them every loving time, but it seems a bit chunky for embedding. I'd have to look at it again though, especially since they just added the ability to compile C# code within the runtime (which essentially makes it a true scripting language). quote:In general though I'm not totally sold on the whole 'scripting makes things easier' front. Sure you may save some time compiling but I think it takes much longer to track down and fix bugs. If you want to have something behave a certain way in one particular level, for example, it's much easier to do that when you can keep that functionality completely separate from the core gamecode. Getting things up and running in the first place tends to be a lot easier just because the languages themselves are so ridiculously easy to work with. OneEightHundred fucked around with this message at 06:49 on May 4, 2010 |
|
#
?
May 4, 2010 06:04
|
|
|
OneEightHundred posted:but hey we got Squirrel scripting in L4D2 so maybe there's hope!! 
|
|
#
?
May 4, 2010 09:45
|
|
|
|
| # ? May 12, 2024 15:26 |
|
|
OneEightHundred posted:Your best scripting languages at the time were probably Lisp offshoots, Tcl, and maybe Perl.
|
|
#
?
May 4, 2010 09:54
|
|