• 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

100 Neutral

About Outworlder

  • Rank
  1. Quote:Original post by The C modest god Quote:Original post by superpig A networked 3D shooter or something? Sure, perfectly doable in a year. You think? How much time and how many people worked on battlefield 1942 for example He said a *networked 3D shooter*, not the Battlefield 2 or whatever. You'd think would learn to read before programming...
  2. Quote:Original post by Gink I think all programs can have their source code viewed, regardless of whether it is compiled or not. That is true. After all, everything is turned to assembly instructions, and those can be viewed no matter what. In fact, that's how most "cracks" are made. Now, if you mean the *original* source code, then the answer would be no. A "decompiler" *can* try to guess at what the original code was, but with languages like C there are a lot of ways to accomplish the same result, or even different outputs for the same input, with something as trivial as a compiler version change. Plus variable names are often not kept (unless you've got a debug build). The reason Java (and .NET) are so easy to decompile is that they store a lot of metadata on their assemblies, and that bytecodes/MSIL are easy to translate back and forth. I like to think that choosing a language based on how easy it is to decompile is often not a wise choice. Not like that will wield a useful build :)
  3. I can't for the life of me understand why they chose the name "javascript". It's as related to Java as PHP is to Ansi C. The reason anyone can see your code is that it's designed to be that way. The purpose of javascript is to add scripting capabilities to the browser, not to be a general purpose language. And pretty much everything that goes to the browser is text. Java was made to be easy to "compile". Compilation, in this case, meaning translation to bytecode. However, the other way around is also easy, and Java decompilers will produce amazing results. The only workaround for that is obfuscation. Same with C# (and all .NET languages). However, don't let this old textbook stuff confuse you. Nowadays, Java code is most likely compiled. If you've got a properly configured Sun VM, try on the command prompt: java - version You'll most likely see: Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode) HotSpot is a compiler. That is, translates bytecodes to ASM instructions. Due to that, and advancements in VM itself, Java code is much faster than it's used to be. Bottom line: javascript for Web pages. Java for pretty much everything else. For a compiler: go to java.sun.com and get the JDK. That's free (the actual compiler is called javac, and is included). For a kickass IDE, if you've got a decent amount of memory, try Eclipse (www.eclipse.org).
  4. Quote:Original post by Thevenin Quote:Original post by tolaris Taken to extreme, you can reduce it to a point where when the player moves one tile left/right you only fetch single "new" column worth of data from respective direction... I would have thought the seek time would be the greatest slowdown factor. eg... Loading 1 KB = 10ms Loading 1 MB = 11ms. And it is! Take a game like Ultima VII, for example. Smardrive made a huge performance improvement, probably by avoiding unecessary disk accesses. However, if the world is, say 10000x10000, why not store a (for ex.) 200x200 region, and let's take a 20x20 visible area(I'm making these numbers up). Now, whenever the player moves, start "shifting" and prefetching tiles, preferably in a "lazy" way. Since you've got a good buffer, you don't need to start fetching tiles right away. You can give your player a small room to move about before getting crazy with tile loading. Might even have a special code to handle the worst case: a player running non-stop in a single direction. And this tile loading could be backgrounded, you could have something to predict player movement and so on. Those ideas are untested, but I've been thinking about it for some time now. It seems it would work just fine for tiles, but NPCs would give you character some trouble. My advice? Download Exult and play with it. It's a engine to replace the aging(read: impossible to run today) and proprietary Ultima VII engine. Then look at the source, you might get some good pointers.
  5. Using excruciating long names for loop variables is one bad thing, in my opinion. But i,j,k don't cut it out either. If it is a simple counter, I tend to use "counter". Sometimes, "loop", for lack of a more meaningful word in some situations. I don't think of myself as being a bad programmer because of that :)