|
yellowjournalism posted:Almost purely portfolio building, with the option to release some free indie bullshit to the public if I feel any of it ever gets good enough for me to be openly proud of. I am extremely passionate about getting into game design and unlike Dude-With-Ideas guy, I have the technical talent and the experience of putting hard hours into software development to put my money where my mouth is. I don't really know the exact position you're aiming at here, but I can tell you from experience that if you want to be a level designer/game designer, don't underestimate the value of doing a public mod for an already existing game. Sure it's good to have level design skills and show them in a portfolio/demo. But that's only part of it. In the end, the most important part of game design is FUN. If you have a mod on your CV that a couple of hundreds/thousand people play, that will give you much more bang than a single demo level. Then again, if you're looking for a more technical job in the games industry it might not be as necessary. Just keep in mind that comboed programmer/designer jobs are scarce though.
|
#
?
Nov 6, 2010 14:33
|
|
|
|
| # ? May 12, 2024 14:09 |
|
|
Zerf posted:I don't really know the exact position you're aiming at here, but I can tell you from experience that if you want to be a level designer/game designer, don't underestimate the value of doing a public mod for an already existing game. Great advice. I want to be a game designer, but I'm not dumb/naive enough to think I can just get there, entry-level, without "doing my time," in my case with technical work. I'm aware that a programmer/designer job doesn't really happen, and that there is no (or ridiculously rare) entry-level game designer job. From what I understand, my In's are entry-level programmer, and entry-level level designer. So I will be applying to both. So as sort of an ambitious idiot, I'm taking two simultaneous tracks: I want to work on my content creation skills (mapping, modeling, animation), and then I want to work on my technical "designer" skills (modding, scripting). So, Vino posted:Okay. You're a programmer, or a technical artist? Unreal is used in a shitload of places so having experience with it on your resume may be useful. Unity is getting more popular, so same there. Code up something cool and novel in those engines, and it'd look pretty good on a resume. Keep it focused though, it's easy to get away with yourself and code up a storm and never finish it. I'm a programmer who also wants to sharpen his technical artistry chops. Unfeasible? Maybe. But as an aspiring game designer I want to get my hands dirty in as many areas as possible. The 2D/more conceptual route is absolutely something I am already pursuing on a different front with a creative partner of mine. I totally agree that the best way to display game design skills is something a little more abstract, with less reliance on (and taking less burden with) 3D pizzazz. So that advice is great, but not what I'm asking for here. The art-faggy design part is handled on another front (and I may come back here asking for opinions/advice on that later) I'm sort of tapping into my RAAAH COuNTerSTRIKe brah MW2 BLOW poo poo UP love for First Person Shooters here, so it's a mode I'm very familiar with and I feel like it would be easy to mod something already existing so I can concentrate on making a couple cool weapon/enemy models and scripting/coding within a framework that's already had a lot of the heavy lifting done (I actually considered taking my Ogre3D FPS engine and taking it to the next level, but I'm really afraid of hitting ceilings, graphically and engine complexity-wise). Aside: I also want to do some cinematic "machinima" cutscene work. I know I'm asking for a lot. But the very reason why, despite being relatively in the dark, I'm flooding you guys with these requests, is because I don't want to get cornered in an engine and realize, when I'm far down the road, that I need to switch. Honestly at this point, it seems it's a toss-up between Unreal and Unity. If you guys have opinions, share them, and in the meantime I'll be studying their dev kits. Any advice on current-gen FPS engines that are well suited for modding?
|
|
#
?
Nov 6, 2010 23:42
|
|
|
I should have mentioned before, your most important goal is to get your name on a shipped title. There's other stuff you need too but you won't get a job in the industry without being able to show that you contributed to a team who shipped a title, even if the team is only just you. Your goal is to either find a team who looks like they're going to finish and offer your services, or make a project small and interesting enough that you can finish it yourself and it looks good on your portfolio.
|
|
#
?
Nov 7, 2010 01:25
|
|
|
Also note, you don't have to actually ship a bunch of boxes with your game to stores, places like Steam are very very useful for this, since to get your game on Steam where people can buy it, the process goes a bit like this: You submit your game to Valve for reviewing for free They accept your game if good enough, deny if not They place the game on the store at a specified price You get 100% of profits from the game Valve supports indie games a lot, so they don't take the profit! 
|
|
#
?
Nov 7, 2010 03:13
|
|
|
I'd really recommend getting started with Unity, the choice of languages and structure in general support getting started better than Unreal which has a scripting language that can be hard to get to grips with (and it was badly documented back in UT2004/UW2.5 era but has probably significantly improved on that front). Unity is much more open and easy to use, the editor is more straightforward in a lot of respects as it doesn't have to conform to some of the performance centric parts of unreal levels. That said you won't be able to achieve the same level of visual fidelity without doing a lot of it yourself, although with Beast lightmapping and a load of other new features as of Unity 3.0 it's a lot easier to get there. I know a lot of people who used to be purely artists get to grips with Unity and produce pretty amazing stuff and the ability to publish to iPhone (when you pay for the necessarily licenses) and other platforms can be handy if you produce something you feel is worth it. Valve have changed rather recently but getting them to even acknowledge you used to be a real issue and I really wouldn't expect to use it straight away. There are alternatives like the delivery system by IndieDB/ModDB and i've heard good things about Impulse by Stardock. Really if you're looking for realistic publishing and monetisation advice of personal and independent projects, TIGSource.com and the business forum there is going to be your best bet for getting advice from people who've been through it all. That said I wouldn't do anything when starting out with the intention of it being a profitable venture, it takes a lot of time to get good enough at everything to produce work people will want to pay for, but you seem to be aware of all of this. In general if you want a job in the industry as a whole being able to show a fully complete project with all the little extras that make it look professional is going to be more valuable than any series of half completed projects. Obviously if you're going for super specific roles a series of tech demos could be better (and the equivalent portfolio work for artist positions) but the ability to show you can commit and complete a full project is incredibly important. I've become a big fan of Flash via Flashpunk (or flixel, whatever floats your boat) lately, with FlashDevelop and Flex I don't deal with the Flash IDE at all and it's very much like writing in java/C#, with a slightly less well formed language. The routes to market for flash projects are somewhat easier too, with sites like Flashgamelicense.com providing the ability to auction off your games to flash portals like Armor Games/Kongregate/Miniclip/etc. Again consulting the TIGSource forums will be your best bet for information on that. It's probably worth noting that it may not be viewed as favourably on your resume because of ingrained ideas of flash development though, although the lines are becoming so blurry that the ability to implement everything in flash is pretty much the same as anything now. One thing i'd really not recommend is trying to do 2D stuff in Unity without integrating a 2D physics library such as Box2D for it, the joints used for 2D physics in Unity are temperamental at best and the collision system essentially requires you use it. With regards to machinima it really depends on the level you go into, if you provide a lot of custom animation and you want to get into animation and you're using it as a showcase great, if you're just doing it to show off your ability to create set pieces within a specific engine you're limiting yourself somewhat and people are more likely to hire animators who can do both over someone specialising in that. With regards to OGRE, I'm not a huge fan, the rendering engine is very well made and incredibly extensible, but the community (or lack thereof) is atrocious and at best it's obtuse and at worst it's a bloated mess. Now I'm sure some people will disagree and I haven't used it in about a year, but when you have options like Unity which probably has the single best development community in existence (especially the IRC channel), the only benefit of using OGRE is to prove you're capable of developing in C++. It abstracts all the graphical API and input usage so you don't really learn anything about that either. Torchlight is great and all, but as I understand it they wrote a huge toolset for their engine that isn't publically available for use in other OGRE projects (nor would it necessarily make sense). Hope this gigantic wall of text helped.
|
|
#
?
Nov 7, 2010 05:01
|
|
|
Bizarro Buddha posted:Bear in mind that updating positions and then checking for intersections will let entities tunnel through things if the timesteps or speeds are large enough. Yeah, I had started to do collision checking based on the motion vector, but forgot that I don't give enough of a poo poo to go through the hassle. Simple collision checking at the end will make it easier to manage in the future, I think. Plus sometimes bugs and neat glitches can be fun, if they're not game breaking. 
|
|
#
?
Nov 7, 2010 05:19
|
|
|
Tw1tchy posted:Also note, you don't have to actually ship a bunch of boxes with your game to stores, places like Steam are very very useful for this, since to get your game on Steam where people can buy it, the process goes a bit like this: What? Sorry but I don't think this is how it works. For one you don't have to ship something over Steam for it to be worth putting on a resume. For two, you act like it's a given that Valve will put your stuff on Steam, very few games get on there. For three, you do not get 100% of the profits and Valve does take a cut, even from indie games. They're not a charity.
|
|
#
?
Nov 7, 2010 05:23
|
|
|
brian posted:Hope this gigantic wall of text helped. It really did, thanks. I certainly understand the value of delivering a completed product, but as I said I'm working on another project (probably going to be Flash-based) with my friend where we want to deliver an end-product. My questions here have been more about developing for 3D engines, so that side of the portfolio is going to be made up more of pieces than finished projects (I do want to make a complete mod eventually, but I gotta start slow, ya know?) You guys have pointed me in the right direction and it's time for me to get my hands dirty and do my own research, so no more questions from me. Greatly appreciate the help. mellowjournalism fucked around with this message at 07:53 on Nov 7, 2010 |
|
#
?
Nov 7, 2010 07:46
|
|
|
I took the last two days to make the effort to port my project to EASTL, that being EA's custom template library. It's awesome. It's poo poo-tons better than std. My game actually runs smoothly in debug mode now and isn't brain crunchingly slow. It was also much easier to standardize on 16 bit unicode strings even though Microsoft hasn't gotten on the ball with the new C++09 string literals yet. Strings in general are much better, with the += operator and an sprintf function. Also the novelty of getting to steal EA's base code for the low low price of an entry in the credits is fantastic.
|
|
#
?
Nov 7, 2010 10:49
|
|
|
I'm kinda' embarrassed by the half-assedness of the code, but it may be of some interest to those in the thread. It's nowhere near finished, but may help inspire those working on something not far off. TileGame: A 2D Tile-based Java Game http://bitbucket.org/JosephCatrambone/tilegame Will load maps from TilEd and sprites from SpriteEd. Entities are hard coded now, will probably change this in the near future. EDIT: Fixed. Jo fucked around with this message at 01:09 on Nov 8, 2010 |
|
#
?
Nov 8, 2010 00:48
|
|
|
brian posted:
I've been using OGRE for developing a CAVE rendering framework and having access to the underlying source of the whole engine has helped a whole lot, especially when it comes to coding in some low-level rendering features that the engine originally might not support (such as quad-buffered stereo for instance). Also I don't think it's fair to compare OGRE to Unity. OGRE is a RENDERING engine (as the R suggests) while Unity is a complete game engine with support for networking, input handling, etc. Heck, in the last 2 revisions of OGRE they even got rid of the tight integration with the CEGUI renderer, if I am not mistaken.
|
|
#
?
Nov 8, 2010 21:17
|
|
|
I was only comparing the surrounding communities in terms of support, I've used both heavily in various projects. It was in response to him talking about his OGRE based FPS engine and I was merely pointing out it's probably not going to be the best option for making a full game on your own due to the lack of tools (intended or otherwise) for stuff like scene management. Also when referring to OGRE it's kind of implied that you'd be using one or more of the many OGRE ready implementations of various physics, sound and GUI libraries. Also it's kind of strange to assume that someone who know enough about OGRE to know the community and code structure would not know what the R stood for.
|
|
#
?
Nov 8, 2010 23:18
|
|
|
My problem with Unity3D is the fact that the client is Windows/Mac only. With the client being integrated in browsers, it gives the impression of web-based games like Flash - but you can't play them on Linux. 
|
|
#
?
Nov 9, 2010 16:19
|
|
|
It's sad but Unity Tech's position on it is that the cost of doing it way outweighs the benefit, with all the testing that would need to be done to satisfy such a tiny amount of users, it doesn't really make financial sense. It may have changed since they got all this success but it didn't a year ago. Either way the lack of a linux plugin won't effect any financial venture really so it'll probably be on the back burner for a while even if it does get worked on.
|
|
#
?
Nov 9, 2010 17:34
|
|
|
I can understand that, but as a Linux developper and sysadmin, I have to forget about that platform entirely, since my desktop runs Linux. Hell, I can't even test the Unity gameservers made by the devs since I can't run the client - and I'm in charge of making sure those servers work.
|
|
#
?
Nov 9, 2010 19:08
|
|
|
Senso posted:I can understand that, but as a Linux developper and sysadmin, I have to forget about that platform entirely, since my desktop runs Linux. Hell, I can't even test the Unity gameservers made by the devs since I can't run the client - and I'm in charge of making sure those servers work. If that's your *job*, why don't you have a separate Windows install for this? For Unity, making a Linux version would probably be more of a PR move than anything else, to be honest. The percentage of people who'd buy a Linux version of a game but wouldn't buy a Windows version, is seriously tiny.
|
|
#
?
Nov 12, 2010 03:00
|
|
|
There's some added irony in that Wine has made it worse. It's gone from "Linux users are probably not a large enough market" to "if they want to play it, they have Wine."
|
|
#
?
Nov 12, 2010 03:07
|
|
|
From what I've read online there's really no way to prevent decompiling pretty much anything. If this is the case, though, then why don't we ever see people decompiling games and modding them? Are these large scale multi-million dollar programs just too complex for a few people to do this on their own?
|
|
#
?
Nov 12, 2010 05:23
|
|
|
hayden. posted:From what I've read online there's really no way to prevent decompiling pretty much anything. If this is the case, though, then why don't we ever see people decompiling games and modding them? Are these large scale multi-million dollar programs just too complex for a few people to do this on their own?
|
|
#
?
Nov 12, 2010 05:27
|
|
|
roomforthetuna posted:there's no human-readable function names or variable names, You'd be surprised how often commercial software gets released with debugging info left in the binary  Also, you're generally going to know what syscalls and library function calls are being made (although you'd know this from the assembly itself, just less legibly)e: for clarity, it's still a colossal bitch to work with compared to actual source code Blotto Skorzany fucked around with this message at 06:35 on Nov 12, 2010 |
|
#
?
Nov 12, 2010 06:31
|
|
|
And games tend to have particularly nasty transformations applied to them in order to prevent you from understanding and removing the DRM.
|
|
#
?
Nov 12, 2010 06:37
|
|
|
Question: I'm going to the University of New South Wales soon, which has the second greatest engineering Uni facilities in the world. I love robotics, and I love programming, but I cannot do them both. Do you recommend I take robotics, or should I take programming and electronics, since that lets me make games and robots if I want to. I'm just wondering if anyone has much experience, and whether robotics, electronics, or programming will get me a job that pays more and hires easily (well, more easily than most things). Anyone have any ideas?
|
|
#
?
Nov 12, 2010 06:41
|
|
|
Tw1tchy posted:Question: robotics, for the most part, is programming. Unless you're talking about the hardware side of things, in which case it's mechanical and electrical engineering. Basically, this question doesn't make sense without context -- what's involved in the robotics degree? In general, I always recommend the less specialized degree, while doing projects that interest you on the side (there's likely a robotics club there as well, and possibly a game development one). As far as marketable skills go, in my experience good programmers never have trouble finding jobs (and on the other end of things, are impossible to find and hire). I've never been involved in hiring an EE so I don't know about those. PS. I majored in CS in school, have worked on cell phone, Xbox360 and PS3 games, and now work in robotics. My only prior robotics experience was a couple classes in college, and work on a robotics simulator using a bunch of game technologies.
|
|
#
?
Nov 12, 2010 08:35
|
|
|
cronio posted:robotics, for the most part, is programming. Unless you're talking about the hardware side of things, in which case it's mechanical and electrical engineering. Basically, this question doesn't make sense without context -- what's involved in the robotics degree? I mean that I can choose Electronics + Programming to have two specializations which I could then use to make robots if I so chose to, OR just Robotics. So I guess I'll choose Programming + Electronics, since I can still create robots and whatnot since I'd have the knowledge.
|
|
#
?
Nov 12, 2010 08:54
|
|
|
Unity announced the asset store, and it's pretty brilliant: http://unity3d.com/unity/editor/asset-store
|
|
#
?
Nov 12, 2010 10:17
|
|
|
Another newbie question: are there any decent (Free/free) programs/libraries/engines for Android? Cross-platform stuff is highly preferred 
|
|
#
?
Nov 12, 2010 10:52
|
|
|
seregrail7 posted:Unity announced the asset store, and it's pretty brilliant: http://unity3d.com/unity/editor/asset-store Do you know if you can use and test the assets in your game before you buy them? If not, I don't really see myself buying anything from this, because I have no idea if anything looks good or not until it's in game. edit: Lutha Mahtin posted:Another newbie question: are there any decent (Free/free) programs/libraries/engines for Android? Cross-platform stuff is highly preferred It can run air stuff, and I've seen flashpunk and flixel games being run on Android, but I'm not sure how viable it is.
|
|
#
?
Nov 12, 2010 14:47
|
|
|
Vinterstum posted:If that's your *job*, why don't you have a separate Windows install for this? Because I'm a Linux sysadmin? Producers decided we were going to make Unity games without checking if the gameservers ran on Linux, so we suddenly have to port our maintenance code and all that to Windows, it was quite unexpected.
|
|
#
?
Nov 12, 2010 16:30
|
|
|
Lutha Mahtin posted:Another newbie question: are there any decent (Free/free) programs/libraries/engines for Android? Cross-platform stuff is highly preferred Also, jMonkeyEngine is in the process of adding the ability to build in jMonkey for the Android. According to the conversation on the forums the commit of the code is about to happen soon.
|
|
#
?
Nov 12, 2010 16:32
|
|
|
Can somebody explain to me why so many game engine proposals you hear about (say, on Gamedev.net) involve some sort of 'entity' framework and inevitably some 'EntityManager' class? To elaborate, is there some sort of established practice where every item (enemy, powerup, wall, ground, etc) is of some class 'entity'? To me this seems to fly in the face of good OO design, because 'entity' becomes meaningless. Does it mean renderable object? Something that has a model? Something that needs updating every frame? What if it's a combination of these things? Having a static renderable tile that doesn't need to update and has no model (for example, part of the ground that is below the surface and doesn't need collision detection) seems very common. Am I missing something about 'entity' design or are game programmers just not very good at OO?
|
|
#
?
Nov 12, 2010 16:50
|
|
|
Lutha Mahtin posted:Another newbie question: are there any decent (Free/free) programs/libraries/engines for Android? Cross-platform stuff is highly preferred I found Andengine to be a bit too heavy for my purposes so I ended up using libgdx, it's simple, has everything i've needed as well as a really really fast sprite batcher. Plus it's easy to have it run multi-platform (includes guides and whatnot).
|
|
#
?
Nov 12, 2010 17:25
|
|
|
Orzo posted:Can somebody explain to me why so many game engine proposals you hear about (say, on Gamedev.net) involve some sort of 'entity' framework and inevitably some 'EntityManager' class? Yes.
|
|
#
?
Nov 12, 2010 17:25
|
|
|
Yes what? My question was an 'or' question.
|
|
#
?
Nov 12, 2010 17:29
|
|
|
Hubis posted:Yes. (OK, seriouspost) It's sometimes one or the other or both -- although it's unfair to assume that they're necessarily trying to do "C++ style" object orientation. Entity usually refers to the basic functionality needed for an object in the world. Perhaps they all have an "UpdatePhysics", "GetRenderInfo", and "CheckCollision" function. This may be a single class that encompasses all possible states, with methods determining which functionality (rendering or collision) is enabled on a per-entity basis. Other times, Entity may just be a base class, from which is derived "ItemEntity", "MonsterEntity", "BackgroundEntity", etc, which all have different functionality, either through overloading virtual functions in the base class, or using some sort of run-time type system. The point is, however, that whether you have one class with modal sub-sections, or several classes, they're both basically trying to achieve the same design goals. Usually a flat entity structure is easier to implement and sufficient for most game code -- plus, it's easy to branch out into sub-classes at a later date if complexity requires. It's still "Object Oriented" however, in that the data and functionality are encapsulated at a sensible object level. Python programmers might look down on even the most fleshed out entity class hierarchy as primitive because it doesn't take advantage of duck typing. e: Usually "EntityManager" is a souped-up container class, responsible for holding all the entities in the world and managing their addition/removal, iterating over them with some function (Find the entity nearest to Pos(x,y), run all the UpdatePhysics callbacks, etc). You could see bad OO here if you end up with too much coupling with internal Entity functionality, but usually there's a clear delineation between entity functionality and "meta"-entity functionality. Also, often times entities take a "Has-A" approach instead of an "Is-A" approach, especially with a flat Entity architecture. So you'll have a bunch of Entity classes with a pointer to a "RenderData" object if they're renderable, and a "CollisionData" object if they're collidable. This essentially gets you multiple inheritance without all the headaches involved. Hubis fucked around with this message at 17:39 on Nov 12, 2010 |
|
#
?
Nov 12, 2010 17:34
|
|
|
I'm pretty much dead set on Has-a instead of Is-a (I almost never use class inheritance, except from interfaces), so I understand what you're talking about, but I feel like you didn't really answer what I was looking for. I guess the core of it is this: what is an entity? Alternatively, how can the entity class exist and obey the single responsibility principle? Although I prefer composition over inheritance, it's also a design smell when you have an interface where implementors have half of the methods unsupported. For example, let's say IEntity has an UpdatePhysics method, a GetRenderInfo method, and a CheckCollision method. If you have an entity with no collision (say, a particle effect), you're now performing a noop on CheckCollision. Or if you have an invisible wall, now you're talking about returning a NullRenderInfo, or something similar, on GetRenderInfo.
|
|
#
?
Nov 12, 2010 18:01
|
|
|
Orzo posted:I'm pretty much dead set on Has-a instead of Is-a (I almost never use class inheritance, except from interfaces), so I understand what you're talking about, but I feel like you didn't really answer what I was looking for. I guess the core of it is this: what is an entity? Alternatively, how can the entity class exist and obey the single responsibility principle? Just because you have an "entity" class in your game, you don't have to model everything from it. From my experience, an entity is an object in the game which has a logical coupling. For example, imagine a car. A car consists of several renderable objects(chasis, wheels(must be able to transform relative to parent), doors(they must be able to open separately), maybe a mounted gun on top of it). The car also have some separate collision objects which it uses. The entire car would then be a single entity, because you never spawn parts of it, only the whole car. The entity in itself could of course contain sub-entities such as the mounted gun atop of it. As you say, a particle system with no collision is not desirable to model as an entity. But a particle system showing the exhaust fumes from a car or plane could very well be part of a vehicle entity, since it depends on how the vehicle moves etc. It just makes sense for level designers to first design an entity from lots of objects, both graphics and physics(and maybe even make custom scripts specifically describing behavior for those), and then spawn these entities(which are collection of engine objects) in the game world.
|
|
#
?
Nov 12, 2010 18:33
|
|
|
Orzo posted:Although I prefer composition over inheritance, it's also a design smell when you have an interface where implementors have half of the methods unsupported. For example, let's say IEntity has an UpdatePhysics method, a GetRenderInfo method, and a CheckCollision method. If you have an entity with no collision (say, a particle effect), you're now performing a noop on CheckCollision. Or if you have an invisible wall, now you're talking about returning a NullRenderInfo, or something similar, on GetRenderInfo.
|
|
#
?
Nov 12, 2010 18:36
|
|
|
roomforthetuna posted:How would you do it instead? Have the manager have separate lists of objects-that-can-collide-and-don't-render, objects-that-can't-collide-and-don't-render, objects-that-can't-collide-and-do-render and objects-that-can-collide-and-do-render (and double the lists again for every other trait that can lead to an unnecessary function call)? I think his concerns are legitimate, you don't want to execute function calls if they just nop. You have multiple options to this problem though, set a state flag on which updates to run for each entity or keep objects which needs physics objects in one list and renderable objects in another(and if both are needed, in both lists). One list for each state permutation seems like worst solution you can come up with, but I think we all agree that it's not an option.
|
|
#
?
Nov 12, 2010 18:54
|
|
|
Is-A makes sense even when you're using Has-A if you have very common groupings of functionality. It doesn't mean everything needs to be shoehorned into one one-size-fits-all class. i.e. you can have a "BasicEntity" class for example which is always a single object with no attachments that corresponds to one renderable model, one physics hull, and only supports some trivial event responses, there's a lot you can do with that. There are other groupings of functionality that cover a lot of possibilities, like "Projectile" or "TemporaryEffect." When that doesn't work, like if you need to make something more complex like a vehicle, then you can build off of lower-level classes and compose them.
|
|
#
?
Nov 12, 2010 19:09
|
|
|
|
| # ? May 12, 2024 14:09 |
|
|
Zerf posted:I think his concerns are legitimate, you don't want to execute function calls if they just nop. You have multiple options to this problem though, set a state flag on which updates to run for each entity or keep objects which needs physics objects in one list and renderable objects in another(and if both are needed, in both lists). One list for each state permutation seems like worst solution you can come up with, but I think we all agree that it's not an option.
|
|
#
?
Nov 12, 2010 19:13
|
|