• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.


  • Content count

  • Joined

  • Last visited

Community Reputation

92 Neutral

About zoneweb

  • Rank

Personal Information

  • Location
    West Coast
  1. Using a polar coordinate system for the physics should simply things a lot.
  2. [quote name='Sayid Ahmed' timestamp='1332864566' post='4925717'] What bothers me is that, one of the core features of the game will be trade, and with that you need a market place with lists of buy and sell orders. These will need to be kept up to date and every time the user visits the 'market.php' page it will have to do a search query and update it accordingly. I'm worried this could take very long and by the time the user chooses to buy or sell something, the data has changed and they'll get the wrong order when they submit. [/quote] You need to queue the orders and process them one at a time. Read from the database only if the values have been changed. Otherwise, display it from the cache like what you've said.
  3. [quote name='hplus0603' timestamp='1332865082' post='4925722'] If there is no packet loss, then TCP and UDP are exactly the same speed. [/quote] Even if there's no packet loss, TCP requires the receiver to send acknowledgements of received data.
  4. [quote name='rip-off' timestamp='1332431398' post='4924354'] Try to stick with facts, rather than opinions. [/quote] [img]http://public.gamedev.net//public/style_emoticons/default/rolleyes.gif[/img] [quote name='rip-off' timestamp='1332431398' post='4924354'] Consider virtual machines, if you look back a few years and see the performance difference between what they were then and where they are now - you will see that most of the "performance issues" are actually implementation issues. [/quote] It's so easy to blame everything on [i]implemention[/i]. It's a catch-all phrase for defending anything that's wrong with a particular tool. One could argue that the performance issues of C/C++ is related to implementation too. If the compilers were made better, C/C++ would always be extremely far ahead of Java in performance. [quote] Java's main performance pitfall is the memory structure - it suffers because it doesn't allow explicit value objects and AFAIK little or no memory layout optimisations are done automatically. This is where 95%+ of modern performance issues are - memory layout problems causing the busy loops to fall outside the cache. [/quote] Regardless of whether or not the percentage is correct, you've admitted yourself that Java is an inadequate language, performance-wise. [quote name='rip-off' timestamp='1332431398' post='4924354'] And of course if you allow C or C++ that, then surely you must allow Java, C# or even Javascript the same, and you are back to where you started. However unless you are in the business of writing operating systems I don't see any relevance of this line of reasoning. [/quote] There's a huge difference between a little abstraction and 100% abstraction. And if Java is so good, it would've been used for coding commercial operating systems
  5. You could try one or more of the following: 1) Check the distance of the player to the bot. If the player is too close to the bot, the bot should avoid placing bombs and focus on running away. 2) Use the pathfinding algorithm (A*). If there isn't a path of escape to safety, don't put the bomb. If a path leads to a dead end, the bot should avoid it. 3) Make the map bot-friendly. Add hidden triggers or location markers on the map to make it an ideal bomb site.
  6. If you want it simple, you could just average the coordinate positions of all targets that your camera needs to look at, then have your camera focus on the averaged position.
  7. You haven't mentioned what graphics API you're using, but the principle is the same regardless: sort all your sprites by the order of their appearance before drawing them or draw each sprite into a separate graphics layer then draw all the layers in order onto to the main screen.
  8. Since your space combat mode is strictly 2D, there's no reason why the standard A* algorithm can't be applied. Just use a different grid for each different ship size.
  9. This should be easy. Just use an array of flags identifying the buffs/debuffs with associated countdown timers. Have each timer decrease with each frame elapsed or poll the internal clock. Once the timers reaches zero, turn the effects off. When the buffs/debuffs are reapplied, increment the timers. Activate the effects only when the timers are greater than zero.
  10. [quote name='Vlad86' timestamp='1332258514' post='4923654'] C++ will consume allot of time before you will be able to generate something useful (without major bugs). [/quote] That only happens when you scale it up. Hobby games are still doable in C++ without much hassle (if you know what you're doing). You just have to avoid the gimmicks that other programmers sometimes use to make their programs appear more sophisticated than necessary (e.g., excessive use of inheritance, pointers, and unnecessary datatypes when simplier methodology would suffice). The key is to follow a programming paradigm that allows smooth porting of the program between platforms and languages.
  11. [quote name='Cornstalks' timestamp='1331767609' post='4922091'] Ummm... Welcome to the 21st century, where the bottleneck in graphics is: the graphics card, your shaders (if you write the like crap, they'll run like crap), and memory I/O (between RAM and the video card). These days, the amount of graphical work done on the CPU is tiny. [/quote] Your point would be valid if it weren't for the fact there aren't any Java games that have graphics and performance comparable to a modern game written in a non-Java language (e.g., Crysis). [quote name='CRYP7IK' timestamp='1331769604' post='4922102'] Spoken like a person who has no sense of style. Seriously though, while you are correct (Crysis in Java?) Minecraft has it's style for a reason but Java is able to do a lot nowadays. For example look at jMonkeyEngine and see what can be done with Java. This is without saying a single person will not be able to model, texture and animate things at Crysis level so that is most probably not going to happen and renders that point moot. [/quote] Here's a link to the only list I've found so far of commercial games made with Java: [url="http://www.java-gaming.org/index.php/topic,3123.0"]http://www.java-gami...hp/topic,3123.0[/url] The latest game on the list, Tribal Trouble 2, has dated 3D graphics. Same situation with the rest of the games on the list too. I understand games made with Java have to work within Java's limitations but it's rather [i]euphemistic[/i] to explain the reason for the substandard graphics that's consistent on many Java games as simply a matter of differing style. Your reference jMonkeyEngine is a good example of Java trailing behind in the graphics department. Blocky, low poly, and pixelated graphics, seriously? [quote name='CRYP7IK' timestamp='1331769604' post='4922102'] No it doesn't. [/quote] [url="http://www.electronicsweekly.com/blogs/eyes-on-android-updates/2011/11/what-is-android-native-code.html"]http://www.electroni...ative-code.html[/url] [i][quote]The Android NDK is a companion tool to the Android SDK that lets you build performance-critical portions of your apps in native code. It provides headers and libraries that allow you to build activities, handle user input, use hardware sensors, access application resources, and more, when programming in C or C++. If you write [b]native code[/b], your applications are still packaged into a .apk file and [b]they still run inside of a virtual machine[/b] on the device. The fundamental Android application model does not change.[/quote][/i] [quote name='CRYP7IK' timestamp='1331769604' post='4922102'] Most usages of C++ turn it into that anyway with smart pointers and things like that. Then you go even further with memory buckets etc. Until you basically end up writing verbose C#. If you don't do that with C++ your game or program is going to have so many possible ridiculous bugs and lots of undefined behaviour. Don't believe me? Look at this blog post by John Carmack. [/quote] John Carmack acknowledges problems, but what developer never encounters problems? What programming languages never have problems? Should a developer switch to another language simply because he found his current language too hard for him instead of working things out? Carmack never mentioned switching to Java anywhere in that blog post. I'm not entirely discounting Java as a language for developing games, but with such a discouraging number of commercial games produced with Java, it doesn't support the opinion that Java is good for general game development especially if the developer wants to stay on the cutting edge. I understand there are developers who feel a sense of romanticism for certain languages because of various reasons (e.g., it's their first language), but sentimentalism shouldn't taint the arguments of why languages are good or bad. Otherwise, why deny the shortcomings of a language in spite of evidence?
  12. A simple solution would be to use the onmousemove event to control an in-game cursor.
  13. [quote] Slow compared to what? C++, C, Assembly? The JVM has come an awful long way in its 15+ years. And of course there are multiple vendors of JVMs now, all with different performance properties. Minecraft is written in Java, and while it might not be that much to look at, a whole mass of computations are going on under the hood. [/quote] If it was fast, then the graphics could've been done better. Java is not good for gaming unless you're content with not going beyond subpar 3D graphics. Yes, there are commercial games made with Java, but they're only a few in number (at least on PCs). That's a telling sign that it's not meant for heavy duty games. [quote] Not so much -- There's a native code SDK available too, which I'd make an educated guess is the preferred environment for pro game developers, for portability between PC and iOS if nothing else. [/quote] Programs written with the native code SDK still require a VM (for the Android OS at least), which defeats the purpose of writing in native code. [quote] A simple, self-contained library that doesn't do what you want isn't very helpful, regardless of how well its documented or clear the code is. [/quote] Multiple libraries that aren't well documented aren't very useful either. Many functions and classes are often so interlinked and esoteric that examples are required to know the proper use of them. [quote] C++ simply doesn't make any over-reaching attempts to protect you from yourself. Java and many other modern, RAD-oriented languages have extensive guardrails in place, while C++ is happy to let you walk off the end of the pier; however, that does't change the fact that good design is required regardless of language or programming paradigm. [/quote] So the best languages are the ones that act like nannies? I see that cognitive laziness and impulsiveness, but I agree with your point. [quote] Again, there's something to be said for simplicity, and I actually have a lot more respect for JavaScript than your average Joe -- but its hardly a panacea of simplicity. Javascript performance varies greatly between browsers, as does the feature-set needed to do anything interesting with games. Performance swings from one extreme to the other between even versions of the same browser. [/quote] Though JS code is prone to hanging up because of bad loops or whatnot, it won't crash in the way that compiled programs do. With the recent addition of the canvas element, making games with decent 2D graphics is possible. It's a good alternative to flash, which has even worse performance issues.
  14. Like what one poster said you could simplify things by making some variables constant. But you could make it even easier by making almost every variable constant. Restrict yourself to a limited set of jump vectors and have the AI choose from among set one vector that best fits the situation.
  15. You could either make every sprite image the same size and hard code the offsets (easy way) or you could do on-the-fly calculations for the offsets (hard way). In the latter case, you create a standard point of reference for the sprites (e.g., center of the sprite image).