• 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.

epicpunnum

Members
  • Content count

    38
  • Joined

  • Last visited

Community Reputation

459 Neutral

About epicpunnum

  • Rank
    Member
  1. Oh man, that's a huge weight off of my shoulders haha. Thanks Brother Bob and ReaperSMS!   I didn't even consider the fact that both languages use floating points behind the scenes. I'll mark it down as solved :)
  2. I've been working on an encryption system for a program, and as a means of getting size of the encrypted String down, I decided to allow the system to put numbers into any base - 62 being the max (values going 0-9,A-Z,a-z). I wrote this out fairly quickly, and it works for the most part, but *almost* every output value is off on the last character (even worse if not using base 62).   Some example cases: 30400066288418849 becomes 2FEQDJkH9F instead of 2FEQDJkH9E (a difference of 1) 21392905688514741 becomes 1Zyk6HmZO9 instead of 1Zyk6HmZO8 (a difference of 1) 22236810928128038 becomes 1dqNWdRcwg instead of 1dqNWdRcwi  (a difference of -2) 1407619700686911 becomes 6Rhvv3b0J, which oddly is right? As of right now, my code is this: private static final String toBase( long number, byte radix ){ if ( !validRadix( radix ) ) throw new IllegalArgumentException("Illegal value for radix. Cannot convert."); String str = ""; boolean isNegative = false; //Before we start, let's do a super quick check to see if nothing changes. if (radix == 10 || number == 0 || number == 1) return (number + ""); if (number < 0){ isNegative = true; number *= -1; } while ( number > 0 ) { byte times = (byte) (number%radix); char c; //digit value to char conversion if (times < 10) c = (char) ('0' + times); else if (times < 36) c = (char) ('A' + (times - 10)); else c = (char) ('a' + (times - 36)); str = c + str; //Then we end our iteration by preparing for the next highest digit. number /= radix; } if ( isNegative ) str = '-' + str; return str; } I'm sure it's just a small error somewhere, or a tiny oversight, but I've been looking at it on and off for 5 days and still can't see it. System.out.println()-ing each step hasn't been too informative either, as the math seems about right. The digit conversions are all correct too (6=6, 35=Z, 44=i, 61=z, etc).I've been using this site and this one as a means to test my results. Both have the same results, so I think I'm the wrong one here.   Any help is greatly appreciated! Cheers!
  3. Hello, and welcome to GD.net! So as it is now, what you are shooting for may be a bit out of reach. I can't speak to your skill level, but from what I read, I'd say you're just starting out? GameMaker isn't a bad tool. It's fairly basic and clunky, but you can rapidly prototype and test your game. I used it for roughly 4-5 years, and I very much enjoyed it. However, it is a restrictive tool. You won't get amazing performance, but it will be good. That being said, I don't believe PS3 development is part of GameMaker, as with most consoles. This, I'd say is what you should be concerned about least, especially because porting to any console is a huge investment. This is because you need a development kit, or at the very least a $1200 debug PS3 to actually run and test your game on the platform before they accept it and put it onto the network (which they also have a certification process before any of that as well). You can read more about it here: http://www.gamasutra.com/php-bin/news_index.php?story=17707   PC is always a viable and easy option for publishing, so for now I would recommend that you stick to that.   So what you're experiencing is a screen resizing issue, and in GameMaker, there's not all too much to be done with that. If you go into the global game options, there's an option along the lines of "interpolate colors between pixels," which changes your scaling algorithm slightly so that around the edges it's a bit blurrier and less distorted. Definitely do that if you're not doing pixel art. Global game options also allow you to choose how your camera fills the screen, so if you're concerned about different aspect ratios consider this. You may be able to find some DLL's that provide a better scaling algorithm, or use a 3D DLL and use it's scaling algorithm, but I can't really guarantee either. OR if you're feeling ambitious, you can also create multiple sizes of your Sprites, and, assuming you can get the screen size, use the best fitting Sprite to fit your current screen. This attempt could reduce your distortion from scaling, but uses more memory and a bit of GML. So if you are comfortable managing duplicate sprites, having a larger game file, and using some GML, you could also look into that. Again, it's been a bit since I've used GameMaker, but hopefully I've put you on the right track. And don't forget about the GMC! They're a pretty good community, and much more dedicated and up-to-date with Game Maker than this site, so if we can't really help you, you should definitely ask this there. Cheers!
  4. One key question I would ask to this is: What motivates people to change weapons? Consider it a given that you have a starting weapon, what will make the player want to stop using it? If all weapons can grow to the same potential, why stray from the weapon you had since the beginning? Many games that provide a varying degree of weapons do so to give you an idea of strength; the more you adventure, the stronger your weapons and armor, and the greater foes you can defeat. If all weapons are the same, then why go for any other? Think of it in terms of Pokemon, as strange as it may sound. Most players always keep their starter Pokemon, and in many cases, it's either the same level or higher than all the other Pokemon in your party. Most people avoid going out of their way to get rid of their starter, because in many cases, it's just a hassle to train another Pokemon. If you can provide incentives to pick different weapons (ie: the new one levels up faster than your current one), then it could be a very rewarding system, especially if you have any plans of PvP (which you probably don't, but it's a thought). As long as you provide a vast array of abilities/playstyles, it could allow players to have a choice - and players like choice. On the topic of choice, I offer food for thought: Perhaps allow for weapons with both passive or active abilities. One may improve stealth and agility, while another allows you to freeze an opponent solid. Alternatively, if you choose not to go down that path, you can also opt for a perk system each level, not unsimilar to Borderlands. Each level earns you a new bonus, so in the endgame, you have a very distinctive playstyle regardless.
  5. For me, I'd say it's a mix of Olof and Mussi's responses. When I begin a game, I consider the foundation of it - what I feel makes it unique in both atmosphere an gameplay. From there I more or less branch off in every direction and seek to explore every possibility using the atmosphere and gameplay, so that the player can learn on their own just what they are capable of. Typically it's me sketching new ideas and their functions into a day planner or something, but as I test it, and ask for advice from other, one of the key things I look for is proposed changes. If an element in the game seems more like a matter of luck than anything in such a way that it seems impossible or frustrating, I remove it or look for ways to better it. Sometimes I have an initial idea of how I'd like something to look, and it ends up not fitting into the game as well as I had hoped. When I feel that the game is polished, and appears stable, and runs efficiently, then I feel it is able to be released. The main game is complete in my eyes. However, much like Olof said, I may still support it, design add-ons, extra levels, fix missed bugs, and tons of other things. When I've exhausted my ideas, when I feel like it is time to move on, then the game is truly finished once and for all.
  6. Hello everyone! For my game, a 2D platformer, I decided to add parallaxing backgrounds to create more depth. For this approach, I created an object for each pane in the background and foreground, having the following traits: Movement factor (scale): The proportion to the Camera's position that it moves at (ie: 3/4 of the Camera's speed) Position (x,y): Pretty obvious. For example, x = scale * Camera.x; Layer Image (img): The image used for the plane object. As far as rendering the image at the correct location, I have that taken care of. What I struggle with is how to determine the exact image size needed to line up with the room correctly. By that, I mean: given a room's dimensions, a camera's dimensions, and a movement factor, how can I calculate the dimensions of the image, so that when the Camera moves to the edge of a room, all the layers line up? Currently, the best formula I could come up with for the image size is (|scale| * room_dimension) - (scale * camera_dimension), but it only works on a few cases (mostly with foreground layers) As a side note, the scale variable is a float data type with the domain of (-Infinity,1]. Any layer with a value from 1.0 to 0.0 inclusive is considered a background layer. Any layer with a negative scale value is considered foreground. Any help is greatly appreciated :)
  7. Very good article! Pretty much how I would explain it all. Definitely good job emphasizing practice above all else. On thing that I would recommend you revise, is your sudden shift from saying "value" to suddenly saying "brightness." Perhaps also state that most art programs use the abbreviation "HSB" over "HSV." Otherwise, fantastic! A great starting article for beginners!
  8. Likely yes. To my knowledge, a lot of today's 3D games use 2-Dimensional particles in conjunction with a technique called "billboarding" (there's even a recent article that covers it a bit located here, but it may help to also follow the earlier articles he's made as well). What that means is that no matter what direction the object is being seen from, it will always show the same image. To my knowledge, this is implemented by making a square (based on your library it may be made using 2 triangles), applying a particle texture to it (I've attached an example one), apply billboarding, and then program something to make the rendered particle move and fade in/out. ?I'm assuming you've worked on 2-dimensional games already. It's really the same concept as that, except using a technique that make the image face you constantly. I'm sure there are other ways of doing it as well, but this is one of the basic ways of doing that. Hopefully that clarifies it a bit :)
  9. One path you may want to put thought into is names of third-party factions, as it might give you a more "criminal" vibe that you seem to be looking for. Maybe look into terms used in something like drug traffickers or mafia members. Possible Street Level Entities: >Mercenaries/Mercs >Hitmen/Sharpshooters >Guards/Security >Dealers/Slingers >Falcons >Associates >Capos   Possible Leader Level Entities: >Suppliers >Cheifs >Executives/Execs >Lords/Kingpins >Boss & Underboss   Hopefully that helps :) http://en.wikipedia.org/wiki/Drug_cartel http://www.askmen.com/money/mafioso_150/176_mafia.html
  10. I use double-protected cloud storage. I use a SkyDrive account folder on my computer, and I configured my Dropbox folder to be inside of that. That way, I can store my projects on Dropbox, and it will sync to their servers, but because the Dropbox is inside my Skydrive, it's synced to their servers at the same time. That way it's very unlikely that they're lost. And to my knowledge, Dropbox AND SkyDrive provide a file history, so that anything accidentally deleted can be recovered. Right now I have about 4GB of storage available on Dropbox, so until that runs out I'm happy using this method. The only downside is that it limits where I can code, but it's not that bad. If i know there won't be internet access where I'm going, I'll only stick to one computer for coding and sync it up when i get back.
  11. I am constructing a barebones engine for my game, and because of its structure, it it very easy to create and implement new features, even after the game has been finalized and published. The specifics of doing this isn't too hard, but what I'm struggling with is the best way to present it. My game is a 2D puzzle/horror game that has a large focus on story. As such, there is a natural progression of mechanics and difficulty; it may start with a simple button and door, and more to remote control puzzles, and finally work with challenging momentum physics puzzles that require more reaction time. Therefore, there may be mechanics that are slowly introduced and fit into the story. However, what do I do after the game is done? Currently, I plan on improving replay value of my game by offering later updates in the form of a sub-game I'm currently calling "The Tower." In it, the player is subjected to a supply of new maps at random and with each update, more maps will be added, turning it into a game of "how many can you solve/survive?" But let's say that I end up introducing a mechanic that's entirely foreign to the main story game. After playing the story, the player may be familiar with traps, buttons, doors, toggle switches, spikes, spawners, teleporters, and enemies. But what if when I make an update to expand on what can be done ingame, I create a new game mechanic? For the sake of explanation, let's say it's a window, which can only be smashed with an object moving fast enough. The player would have no knowledge of this; it may even seem like scenery for some, and they may never make the connection that it's an important mechanic.   In the story it could have time to be introduced, but if this mechanic is introduced after the story has been finalized, then it would make no sense to go back and change the story. And because changing the story is out of the question, that would leave just simply slapping it into "The Tower" sub-game, where it would be randomly show up without explanation or exposition. So what I'm asking is: In a game where the story has been finalized, but the potential to add more content exists, what are ways to properly introduce new mechanics without simply telling them every time? What are ways to add new mechanics and puzzles into a story-driven puzzle game? Thanks for taking your time to read this :)
  12. As this is filed under C++, I'd assume for this case a C-like syntax would be ideal. Personally, like cr88192, I prefer such a syntax as well, especially as C-based laguages have a lot of ground in today's world, encompassing C, C++, C# and Java (not to mention that there are a few other languages that have somewhat similar structures and syntax). Just for a general idea, psuedocode can have any loosely defined structure. If you wish to adhere more to the language you're using, it could show up as void performMorningRoutine(){ wakeUp() shower() getDressed() eat(breakfast) }   In many cases of psuedocode, the actual implementation is ignored, and instead just has a loose design, opting for comments in some places void eat( food ){ if ( hasFood ) while (hungy){ //decide how to eat your food and eat it. } }   In most cases, it's just to give you an idea of the structure you need to follow for an algorithm. Honestly though, as long as your structure follows some sort of structure that programmers can get, you should be fine. If there's one language you're using specifically, using it's syntax loosely is probably preferred as long as it promotes readability.
  13. Personally, I'm iffy with perspectives (3-point especially), some architecture, and likenesses, as Hamsta said. For some reason, realistic mouths and eyes allude me, and so a lot of my style avoids that. I still try and practice it, but I certainly don't publish it. But I think what I am worst at above anything else is CARS. I don't know why, but I have NEVER drawn a good car in my life, unless it's an antique car like a Ford Model T. I feel like it just has something to do with the smoothness of it all.  Without any really clear lines to define it, I can never quite get the shape right given my perspective; and even if I do, I'm still not accustomed to the design/features of them. As for the conversation that seems to be going around about being good at art: Honestly, I'm not all too good. I am however, proud of what I can do - which is more or less 12 years of my childhood absently doodling and reading up about things I wasn't sure of. If I had to say anything on the fact, is that to get better, there really is no easy way. I see tons of people who don't try and expect it to be handed to them. I sincerely doubt anyone was born able to draw some of the amazing art you see on the Internet today. Just practice, be patient, look to life, and don't rush your work. Make stupid faces in the mirror and draw them as a smiley face so that you can get emotion. Discover proportionality. Look up tutorials for pretty much anything you want. Make comic strips - it'll make your characters more consistent. Review every doodle you make to see what can be better. No matter how you practice - so long as you're practicing - you WILL get better. You can strive to be like one of those amazing artists, just don't expect it to come instantly.
  14. To clarify, I felt that a lookup table would be a necessity because: More than half of my ingame entities would be using some form of rotation Rotation is a key aspect of the gameplay Elastic and inelastic collisions are frequent If I understand correctly, the Math variations on trig functions run an algorithm  to accurately determine it each call. For lookup tables, it only has to run those calculations once for each angle and function (less if you understand the symmetry of the unit circle). So let's assume that you only really need to run 270 (aka 90*3) calls to a trig function and its really accurate algorithm. Because of the high frequency of trig functions in my game, it wouldn't suprise me that at any given time I could be running AT LEAST 50 of these functions on any given frame. For the record, I honestly don't mind using only integer angles or sacrificing some accuracy. I do most of my away-from-home programming on an outdated netbook (32-bit processor, 2 GB RAM, 1.6 Ghz CPU, >4 years old), where Flash can lag easily. Anything that can optimize calculations is useful for me.   EDIT: Thank you EWClay, that at least addresses the issue of precision. As long as it comes close and there are no discernible differences visually, its fine for me.
  15. For a game that I am designing, I have been designing a barebones 2D game framework that includes physics, boundng boxes, cameras, game states, etc. Naturally, because my game is largely physics based, I felt the necessity to design a lookup table for my trig functions. Currently, this Trig class uses only integer values for angles, and three arrays for sine, cosine, and tangent (Each as a Double wrapper object so that values could pass by reference). In an attempt to try and make my framework less memory intensive, I have been going through my code an using appropriately sized variables over simply ints and doubles. It occurred to me that instead of saving hundreds of doubles (at 64 bytes each), I could cut that in half by using floats (at 4 bytes each). My question comes in multiple parts: In your experience, would this help a good amount in terms of memory management - especially for lower end computers/netbooks? Would the loss of precision from a double to a float be significant to the player? Could this potentially increase the number of trigonometry-based object at any given time? Thank you for your time :)