Jump to content
  • Advertisement

Patrick B

  • Content Count

  • Joined

  • Last visited

Community Reputation

210 Neutral

About Patrick B

  • Rank
  1. Patrick B

    OOP design question

    As a game developer who has faced this decision in the past I would recommend making generic classes, like Bullet, that encapsulate all of the generic functionality and data of all the game's bullets, and then extending the classes for any custom bullets that need it. The alternative is to have one class that contains large branching structures, something that will become a nightmare to maintain as the game continues to grow. Additionally, the multi-class structure allows you to easily determine which ammo is usable with what weapons. For example, a "BFG" type gun might support explosive shells and regular bullets so in the gun class' header you would define an "allowableBullets" array that has a reference to all of the allowable bullets:   var allowableBullets = [ExplosiveShell, RegularShell];   Here the two array items are references to the actual classes that you can use for comparison when "loading" the gun later:   function loadBullets (bulletType) {    for (counter=0; counter<allowableBullets.length; counter++) {       if (bulletType == allowableBullets[counter]) {          putBulletsInGun();      }    }    bulletsNotAllowed(); }   This should also work with class instances but you'll need to see exactly how that's handled in your language of choice.   Finally, most programming languages have functions that will allow you to dynamically find classes at runtime (usually using a standard string), so this should be extensible to allow you to match guns and ammo via external data like XML.   If you take some time to ensure that your top-level classes encapsulate as much generic functionality and data as possible it should be easy to create numerous extending classes that change the data or functions only slightly. Should you choose to go with the single-class approach you'd still need to write all of this various functionality, etc., but will also have to contend with managing it in the ever-growing file - unless this is a one-off, quick-and-dirty project I would highly recommend going full OOP; you'll be glad you did later!
  2. Patrick B

    actionscript udp chat program

    Something like this may be useful: http://patrickbay.ca/blog/?p=307
  3. I'm by no means an expert in Unity so I'd like to recommend a little sodium chloride with this reply, but in my experience using 3D graphics for a top-down or side-scrolling (parallax) 2D game is unlikely to affect performance much. In fact, the effect would probably be an improvement. Here's my reasoning:   In any robust game engine or environment, graphics are usually mixed along alpha channels (etc.) during game play -- characters & obstacles layered on a separate background, etc. In 3D, this is complicated with the addition of a Z axis which requires additional depth management including clipping, occlusion, and so on.   At the same time, any 3D engine worth a spit will be efficient, meaning it will not waste too many cycles trying to figure out things like clipping when the graphics blocks are basically just flat planes perpendicular to the Z axis. In effect, the game is simply shifting around postcards on which you probably don't want to apply lighting effects, meaning much of the complexity of a full 3D environment is reduced.   Additionally, 3D engines tend to boast their polygon rendering abilities so you know roughly what kind of performance you're likely to get. And beyond this, 3D engines often make direct use of graphics hardware which can greatly increase both rendering speed and free up the main processor for other functions (handling A.I., collision detection, etc.) 2D engines usually use the main computer/device processor so they can boast greater compatibility, but at the cost of raw power and speed.   In Adobe Flash, for example, we have had robust 2D graphics since pretty much the inception. Many optimizations have been made to the software to make it efficient, and it was pretty darned good until Adobe introduced direct GPU support. As a result, frameworks like Starling popped up that boasted the same capabilities as Flash 2D but with the ability to handle a lot more while simultaneously freeing up the CPU. In other words, Starling is a 2D game engine that uses Flash's newer 3D capabilities, analogous to your question. The answer that Starling provides is quite clear: 2D games can realize significant performance enhancements (plus easier code/effects), by using a 3D engine.   Back to Unity, I'm fairly certain that the same GPU acceleration is used which would lead me to believe that you would be better off using the full 3D engine to create a 2D game; the performance improvements alone would be worth it. Also, as you mentioned, 3D engines tend to have a lot of functionality pre-built -- physics, collisions, etc. It's nice to know how these work but if you're more concerned with actually building the game, these topics are probably best saved until later.   My two cents
  4. Patrick B

    OK, so... what now?

      Not exactly.   A scripting language is what in the old days used to be called an interpreted language. This means that the instructions, whether kept as plain text (BASIC) or translated to some custom byte code (ActionScript, Java), are read and executed by a virtual machine (the Java VM, Flash Player, etc.) The VM takes care of translating the instructions to native functionality. In practical terms, if the computer/device has the VM, it'll run your scripts.   This puts some natural limits on scripting languages: Even with something like Just-in-time compilation, instructions still require an extra step before they're actually executed. Often this can take up quite a bit of overhead, so a scripting language will never be as fast as a compiled language. Scripting languages are restricted by the width of their ecosystem. That's a fancy way of saying that the language will support the lowest common denominator of any system that the VMs support. For example, there's no native access to the Windows Registry from ActionScript, even from AIR. Since AIR also runs on Android, iOS, OSX, etc. this makes sense -- trying to access the Windows Registry on any of these operating systems would fail miserably (they have no Windows Registry!) A robust language will have enough power to allow developers to work around such limits, but the language can't impose these internally otherwise it will be greatly limited in where/how it can run. The other type of language is the compiled one (the traditional "programming" model). Here the instructions are translated directly to native machine code; once compiled, the application runs by itself, no VM required. This limits the application to the native hardware and operating system -- something compiled for x86 won't won't run on a mobile device, and even if it will it's likely that a mobile x86 processor will only support a limited subset of one found on the desktop. This is precisely why software often comes out in a Windows version, an OSX version, and so on.   While compiled languages are very limited in where/how they can run, they are considerably more free to really use the power of the machine -- native 3D graphics, for example, can be used much more efficiently. Also, since the language is already compiled, there isn't that extra interpretation overhead so for sheer speed, compiled is about the best you can get besides going pure Assembler / machine language.   The line between the two language types is being blurred (JIT, for example), but that virtual machine vs. real machine aspect is still the fundamental dividing definition.
  5. Patrick B

    OK, so... what now?

        Let me start off with ActionScript since that's my bread and butter (so, obviously, take with a grain of salt)...   ActionScript is the language used to produce content for Adobe's Flash Platform which is a set of technologies that, as the name implies, evolved out of (and includes) Flash. Besides the Flash plugin (estimated to exist on 90%+ of all browsers regardless of OS), ActionScript is the language powering Adobe AIR. This is really just the Flash player beefed up with extra functionality so that your content can as a desktop or mobile app -- reading/writing to the file system, for example; something that a web plugin must never be allowed to do.   When I started, Flash was proprietary (first owned by Macromedia, then Adobe), but it has since gone through many facelifts and open-sourcery. These days you can go 100% open source if you want to create Flash/AIR content but the commercial version of the Flash IDE (the old-school, original editor), still has many features that make life a lot easier -- nothing you can't reproduce with clever ActionScript, but a time-saver nonetheless.   Even if ActionScript isn't your final destination, I highly recommend checking out FlashDevelop. Yes, it's best when used to produce Flash/AIR content, but it understands JavaScript, PHP, HTML, and a bunch of other languages and markup too. It also comes with useful plugins and is under regular development...your time learning it won't be wasted.   That being said, it's really important that you define what you want to do with the language rather than defining the language first and the project second.   For example, if you need to be able to store data locally on the user's computer (game progress, for example), you will be limited by the use of HTML5/JavaScript. Simply by virtue of being web technologies, they are greatly limited in what (if anything) they can access from the user's computer. This makes sense -- would you want some random web page reading your hard drive when you load it?   Context is also important. HTML5/JavaScript can be packaged into desktop/mobile applications similarly to the way Flash content can be packaged into AIR apps. Flash is also limited when running in a browser and for the same reasons, so whenever I start up a new project I start by identifying what I want it to actually do and only then do I start to plan around how that functionality can be achieved.   Eventually you'll know the language well enough to be able to produce content that runs both on the web and as a desktop/mobile app, so these dividing lines will start to blur more and more. This is true for both ActionScript and HTML5/JavaScript (you can use something like PhoneGap to package such apps as native/mobile). In fact, I'm pretty sure that clever coding can do this in many languages, I'm just extolling what I know best.   So...what now?   Identify your project (often this is preceded by identifying the audience and the "problem" that you want to solve or address). Compile a list of technologies that can support what you want to do. Be sure to include drawbacks too (though it's a good idea to verify them as some people just seem to have an irrational hate-on for ________). Nothing wrong with C#, but it'll only run on iOS -- are you okay with such a limit? HTML5/JavaScript are a good option, but they are far from being a standard across browsers -- are you okay only running the newest 3D content in Firefox, for example? Are you okay with performance issues in Internet Explorer? Do some exploratory work. Your chosen language shouldn't be cryptic or obtuse -- is your aim to learn the language or to make something with it? If you spend more time working out the kinks in the language than creating the project, you're probably on the wrong course. Despite my support for ActionScript, as someone who's trying to learn I would actually recommend HTML5/CSS/JavaScript. I say this because JavaScript is an ECMAScript language, as are ActionScript and Java. This simply means that the programming languages are formatted after the ECMAScript standard so they all look and feel very similar. Moving from JavaScript to ActionScript, for example, is about learning more advanced concepts, not learning a whole new language -- what you know about JavaScript transfers almost verbatim to ActionScript and Java. Moreover, the HTML/JavaScript combination is often mirrored in derivative technologies like Adobe Flex / Flash Builder which uses MXML for markup (like HTML/CSS), and ActionScript for control (like JavaScript).   Conversely, if you want to put the time in up front, you can learn ActionScript and then work backwards to JavaScript. I do this often and moving from ActionScript to JavaScript requires simply tamping down some of the more advanced concepts that I've learned. In fact, JavaScript can often be used almost verbatim as ActionScript code, that's how similar they are.   Good luck!
  6. Patrick B

    Game development - where on Earth to start?

      HTML5 is either web-only or app-only.   When not running in the browser, technologies like PhoneGap can turn HTML5/JavaScript content into apps. However, the custom JavaScript calls used in PhoneGap (etc.) are only used in such technologies, so these apps simply won't run correctly, or at all, in the browser. Performance or broad compatibility are simply not there yet. This is sometimes a necessary situation -- PhoneGap can't support something on a Windows phone that can't be supported on Android and iOS, for example -- but there's no low-level workaround at the moment (see ActionScript's Native Extension system, for example).   This situation is reminiscent of Flash circa 2007 when ActionScript 3 was being formulated and third-party technologies like NothCode's SWF Studio were providing app functionality to otherwise web-only Flash content. This is why I'm not against HTML5 or JavaScript -- I can see where it's heading, it's just clearly not there yet. If you learn the advanced stuff first and work backwards, I estimate that you'll be in a much better spot in a few years than someone having to climb the knowledge mountain for the first time.
  7. Patrick B

    Game development - where on Earth to start?

      WebGL is not supported by most browsers. Only 33% of browsers fully support it, another 33% have partial support, and the remaining 33% (most mobile browsers), don't support it at all: http://caniuse.com/#feat=webgl
  8. Patrick B

    Game development - where on Earth to start?

    Your choice of tools will be informed by the type of game you want to make. For example, if you're looking to so something with 3D or something that requires broad audio support, you would be wise to steer clear of HTML5 -- lessons learned when I was building Teletoon's Toon Feud game. However, if you're building something simpler that doesn't require excellent audio support and synchronization, across-the-board 3D support or peer-to-peer networking, and are willing to work around occasional browser incompatibilities, HTML5 is a good choice. I have no doubt that HTML5 will continue to evolve so in a few years we can expect it to have the capabilities of Flash 8 -- just not there yet. I broke it down in greater detail here: http://patrickbay.ca/blog/?p=153   If you're looking for a broad platform (your game can run on as many devices as possible without having to alter your code), I highly recommend Adobe Flash/AIR. I've developed nearly 90% of the games I've worked on in Flash or AIR and have no regrets. Keep in mind that your audience probably won't care what underlying technology is being used so the important take-away is that you work backwards from them -- what are your audience looking for? How will your game achieve these things? How can your choice of technology make this happen? Most successful developers don't tout the underlying technology (except to interested nerds), they tout what their product does for you.   Full disclosure: People have been paying me to develop games for about 10 years (I did it for fun for about 25), and I have a real soft spot for Adobe Flash / AIR. Yes, I'm deeply biased. I've worked in ActionScript, HTML5/JavaScript/jQuery, PHP, Java, C#, Assembler, and in the early days Pascal and BASIC. In my opinion, Flash gives you the biggest bang for the buck in terms of flexibility, power/abilities, and platform coverage. Of course, being interpreted means that ActionScript will never run quite as fast as C++ or to-the-metal Assembler, but ever since great Java-inspired concepts like Just-In-Time compilation were implemented, the Flash/AIR virtual machines have improved significantly. These days, Java and ActionScript are close cousins (though Java is still a few steps above and beyond).   You can go entirely open source and free (FlashDevelop or Apache Flex, supplanted with GIMP and InkScape), so costs are not a barrier. And, frankly, I think you'll find that ActionScript is close enough to Java to make the transition easy. Transitioning to JavaScript afterwards is even simpler -- just cut out the useful features and advances of languages like Java or ActionScript (strong data typing, for example), and you end up with JavaScript. Your skills will definitely transfer to other browser-based technologies so even if you end up dropping Flash/AIR in the future, knowing how frame-based animation is achieved, for example, comes in real handy when dealing with things like HTML5 (again, personal experience).   Ultimately, if you stick with one of the dot-notation languages you're probably safe in the long run, and when HTML5 is advanced (and actually standard) enough, you should be able to seamlessly transition your code. If you start with HTML5/JavaScript first, however, you'll be immersing yourself in a somewhat stagnant "standard" that, in my opinion, will limit you more than free you. But, of course, this is entirely dependent on what your actual limits are.
  9. I just realized that I missed the part about using the Accelerometer, but the concept will be exactly the same. Only difference is that you won't be using Keyboard or Mouse events to capture the user's intentions.   I also realized that I used a little more nesting to accomplish this effect...the track itself (with the pieces in it), should nested within one more parent clip to allow you to move the X/Y coordinates...   currentTrack.rotateY=30; currentTrack.container.y+=10;   In the above example, currentTrack contains a "container" clip which itself contains the road, grass, etc. clips. When you rotate the parent, all children are also adjusted. However, adjusting the X/Y properties of the "container" will move the track around within the rotated parent, which is what we want.
  10. I think for your game you could probably get away with Flash's built-in "postcard" 3D system. This is the approach I used for a game named FloorPig (look it up on Google Play store if you're interested). It's not true 3D in that it doesn't do any culling, etc., so you will be limited in what you can do, but it's also the path of least resistance and simple to implement.   To accomplish FloorPig's functionality, I first created the tile "floor" using XML coordinates to map individual tiles. In your case you can probably make the entire track one movieclip. To rotate it into perspective, simply adjust the rotateY property of the movieclip:   currentTrack.rotateY=30;   (you'll have to play with the value to get a satisfactory rotation)   Rotating the track to match the movement of the car is simply a matter of rotating around the Z axis:   currentTrack.rotateZ+=10; //Turn right by 10 degrees currentTrack.rotateZ-=2; //Turn left by 2 degrees   Most likely you will want to add this to a keyboard or mouse event listener so the player can control the movement. Because the keyboard system introduces a delay between first/subsequent keystrokes, you will want to handle keystrokes more directly; something like this:   import flash.ui.Keyboard; import flash.events.Event; import flash.events.KeyboardEvent;   private var _currentKey:uint = 0;   private function frameLoop(eventObj:Event):void {    if (this._currentKey == 0 {       return;    }    if (this._currentKey == Keyboard.LEFT) {       currentTrack.rotationX -= 5;    } else if (this._currentKey == Keyboard.RIGHT) {       currentTrack.rotationX += 5;    } }   private function keyDownHandler(eventObj:KeyboardEvent):void {    this._currentKey = eventObj.keyCode; }   private function keyUpHandler(eventObj:KeyboardEvent):void {    this._currentKey = 0; }   stage.addEventListener(Event.ENTER_FRAME, this.frameLoop); stage.addEventListener(KeyboardEvent.KEY_DOWN, this.keyDownHandler); stage.addEventListener(KeyboardEvent.KEY_UP, this.keyUpHandler);   Note that the rotation values are arbitrary -- you can adjust these based on the turning ability of the car, track conditions, etc. In other words, use variables unlike me :)   Now that it's rotated, the track can be placed "beneath" the car using straightforward Flash display depths (setChildIndex, etc.)  Create the track and then just center the car on top. Same for any other elements you want to be visible on top of the track.   Moving the car along the track requires you to simply adjust either the X or Y values of the track clip (probably Y but you'll have to test this out). For example:   private var _carSpeed:Number=0;   private function frameLoop(eventObj:Event):void {    if (this._carSpeed>0) {       currentTrack.y+=this._carSpeed;    }    if (this._currentKey == 0 {       return;    }    if (this._currentKey == Keyboard.LEFT) {       currentTrack.rotationX -= 5;    } else if (this._currentKey == Keyboard.RIGHT) {       currentTrack.rotationX += 5;    } }   If you find that moving along the Y axis works well, you can introduce a little X axis motion for things like drifting or sliding (wet track, for example).   Finally, you'll want to implement some sort of collision detection. The following is far from the best approach but it worked well enough for FloorPig so it may work for you too. I created 3 (or was it 4?) invisible dots (just movieclips with alpha=0) that sit at the virtual "edges" of the character -- in your case, where the corners of the car should be at the chosen perspective. I adjusted these by hand -- no fancy math. On ever frame loop I check to see if the dots are on top of a tile or not by doing a hit test. For example:   private function frameLoop(eventObj:Event):void { if (currentTrack.hitTestObject(edgePoint1) &&     currentTrack.hitTestObject(edgePoint2) &&    currentTrack.hitTestObject(edgePoint3) &&    currentTrack.hitTestObject(edgePoint4)) {       //Currently on track    } else {       //On ore more wheels is off track    }    if (this._currentKey == 0 {       return;    } ...   This, however, has one major problem - if your track includes both the road and non-road (grass, etc.) in one graphic, the car will always be "on the track" if it's over any part of the clip. To differentiate between different types of terrain, I'd recommend drawing or somehow separating the various elements within your track clip. For example, you could have one movieclip within "currentTrack" that's the road, something like currentTrack.road. Another internal clip would be the grass: currentTrack.grass -- and so on. With this detection in place, you can produce a basic version of what you're looking to do. For example:   private function frameLoop(eventObj:Event):void {    if (currentTrack.road.hitTestObject(edgePoint1) &&        currentTrack.road.hitTestObject(edgePoint2) &&       currentTrack.road.hitTestObject(edgePoint3) &&       currentTrack.road.hitTestObject(edgePoint4)) {          //Currently on track       }    if (currentTrack.grass.hitTestObject(edgePoint1) &&        currentTrack.grass.hitTestObject(edgePoint2) &&       currentTrack.grass.hitTestObject(edgePoint3) &&       currentTrack.grass.hitTestObject(edgePoint4)) {          //Currently on grass    } ...   Using a similar approach you can place additional objects on top of the track as well as additional "edge points" to detect collisions with them.   Since this isn't true 3D, you will most likely be pre-rendering the car (or maybe video capture?) Just be sure to decide on what angle your track will be at up front, otherwise your car will look odd in the context of the scene.     Good luck
  11. Such animation systems have been a standard part of Flash and, more recently, JavaScript so you should have plenty of sample and well-tested code to look at. In Flash, animations from point A to point B with certain dynamic velocities are called Tweens and are typically comprised of two parts: the code that applies the tween to the target display object (and reports on progress), and the equation that accelerates, decelerates, or otherwise calculates the motion (or more correctly, the X,Y position of the object at a specific point in time -- what will X,Y be at N milliseconds/frames?). Beziers are just one type of curve that can be applied -- others include exponential, quadratic, sinusoidal, etc. One of the more established and robust libraries for this is the Greensock library (TweenLite or TweenMax). In jQuery, there's the "animate" function which does the same thing, except of course if operates on HTML DOM objects -- but the concepts are the same. One thing to keep in mind as that you will probably want to include some sort of reporting mechanism: a callback or event whenever the position is updated, and one more when the animation completes. This will allow you to expand on the animations beyond simply animations (collision detection, Z-axis support, etc.)
  12. "Depending on what you want to make, HTML5 is ready now (audio, as mentioned, is extremely problematic, although usually not insurmountable).  Offline support is available, although unwieldy, multi-player 'support' can often be easier (this is admittedly a sweeping statement to be taken with a pinch of salt) and the ecosystem is thriving (although forerunners are not yet entrenched as industry 'standards').  The GPU is within your reach (with fallbacks in most cases, canvas is near ubiquitous although performance is perceived as sketchy often due to CPU limitations) although not across all devices, as said, fallbacks do exist but may not be good enough depeding on your use-case."   Let me see if I got this straight:   You can't really do audio, you can't reliably store data offline, maybe in the future there'll be multiplayer support, and you can get GPU acceleration and 3D but only with a bunch of caveats. Internet Explorer is a big JavaScript "gotcha" (who uses that dumb old Internet Explorer anyways?), and mobile support (isn't that what HTML5 was supposed to be all about?), is less than amazing.   "As a game developer the biggest challenge you face is not actually fragmentation (which is a major major issue) but performance."   There's more?!   "Whilst JS is often perceived as being a 'weak' language (partly through its loosely typed and interpreted nature but mostly due to previous employment of JS) it, when part of the greater web platform, is actually incredibly difficult to write properly and requires as much as skill as many other mature languages."   Well that's a selling feature. Incredibly difficult.   "However, JS is hard.  Programming on the web is very hard.  You have to write a lot yourself and there is a lot to understand about the nature of the web.  The games industry is learning, often the hard way (the graveyard of failed projects is large)."   Well I'm sold.   "HTML5 is still a maturing platform and parity is almost already active."   Right...http://en.wikipedia.org/wiki/Comparison_of_HTML5_and_Flash   The same problems that plagued Flash in the early days are back all over again because lessons of the past are being tossed in the trash in favour of a bullheaded push for HTML5. Often CSS and JavaScript get forgotten, but they're an integral part of the whole. And overall, that adds a whole lot of complexity. Plus, unless you want to limit your audience, there's that cross-browser thing, which is still a problem. You can do things like PhoneGap to app-ify your JavaScript/HTML5/CSS3, but it`s nice to be able to step into other technologies if it doesn't work out. In the browser, even more so. ActionScript is simply a more complex version of JavaScript -- it's not about 'slummin' it but it really is like the old days of Flash. I can't avoid HTML/JavaScript/CSS in my daily work, and I don't dislike it (remember that Flash runs in HTML and obeys the laws of JavaScript to some degree), but it's just not what it's promised to be. And considering JavaScript/HTML are older than Flash/ActionScript, they (HTML/JS) just never quite managed to make the same advances or penetration. Maybe that's a community open standards thing vs. single custodian thing, I don't know.
  13.   Flash runs great on every device I have (including mobile). The problem is today the same as it was when Jobs made his pronouncement---slow, bulky Apple products based on a purposefully crippled OS (in the name of "user experience"), are the problem, not Flash. I've done countless side-by-side comparisons (many of them not involving Flash), and Macs have always -- no exaggeration - been far slower and crash-prone. I've had fanbois sitting next to me during these comparisons tossing out "explanation" after "explanation" about why OSX was slow here, or why applications were more prone to crash there, etc. End result: Apple products suck. That's why Apple has been shifting the blame from Flash to Java to Reader...did you ever stop to think that maybe it's not the rest of the world that's the problem but the hardware / OS?
  14. Flame war not intended ... I just don't like what Jobs has done to computing (Steve Wozniak kind of backs me up on this). But that wasn't the bulk of my point.   I don't want to imply that HTML5 should be tossed in the bin because, as I said, it has many good uses. I've seen some impressive 3D demos, and some great 2D game ports, but unfortunately those were browser-specific (which to me is a limiting factor), and didn't always perform well mobile devices (which to me is also a limiting factor, especially for games). It's been my experience that unless there's some sort of overarching uberagency to IMPOSE standards, we're not likely to see them coming to an apex, instead, development of individual standards will continue in parallel (with a bunch of common overlap, as today). That includes Microsoft, of course -- Internet Explorer is always a special challenge to work with (especially a couple of versions back).   I agree that workarounds exist, and that working on the wild frontier can be fun and rewarding, but developing a game in HTML5 is a challenge and for me requires too much effort on things that are elegantly implemented in Flash (AIR on mobile).   There is currently a debate happening about implementing a closed Digital Rights Management regime into the open HTML5 standard -- is this a start down that slippery slope to closed and proprietary? Or are we there already? There are many forces competing for access to web standards and I'm not sure that'll go away any time soon. Proprietary software standards are nimbler and faster and so I can't see those not being implemented in browsers as new features (but only for those browsers, of course).   Basically, I don't see this horse race coming to an end any time soon, so while I don't doubt that eventually most HTML5 features (which are still being discussed) will be implemented in most browsers, there will continue to be those nagging differences. Maybe I've just gotten pessimistic over the years :)
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!