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

Cagnazzo

Members
  • Content count

    9
  • Joined

  • Last visited

Community Reputation

140 Neutral

About Cagnazzo

  • Rank
    Newbie
  1. [quote name='hupsilardee' timestamp='1354200231' post='5005306'] Python is great for this kind of thing. I just pull up the shell and hack a quick function together. Great for GCD, LCM, co-primality, etc. Quicker than C++ to compile and run. I just rewrite the function every session I want to use it, which ends up with me learning the definitions of these things very thoroughly (and degrading my mental arithmetic). [/quote] Python is pretty good, but you'd be amazed at how well Haskell does with Project Euler. There are tons of problems that it just chews through with no thought. Which is exactly what you'd expect from a purely functional language, really [img]http://public.gamedev.net//public/style_emoticons/default/tongue.png[/img]
  2. I think you might be mixing 16 up with 15. 255 is, in binary, 11111111. 16 is, in binary, 0001000. The reason you can take any number up to 255 and logical and it with 255 and get that number back, is because 255 is basically ones everywhere - so if the number you're &ing has a zero in a slot, the result is zero in that slot - if it has a one, the result is one. 1&x is simply equal to x. 0&x is always equal to zero though. So if you're &ing with 16, the the sixteenth place is [i]always [/i]going to be the only place that could possibly be nonzero. You'll end up with either 16 or 0. Does that make sense? I suspect you meant to be using 15, which would be 00001111.
  3. [quote name='Bacterius' timestamp='1353737350' post='5003684'] [quote name='superman3275' timestamp='1353733380' post='5003673'] I think about it like this: CPU does the math, GPU does the rendering. Ta-Da [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] (I'm not a smart programmer [img]http://public.gamedev.net//public/style_emoticons/default/tongue.png[/img] ). [/quote] GPU does the math too. I would say it's more like, CPU does the logic that brings everything together, and GPU is the powerhouse that drives rendering, and possibly physics (and perhaps other stuff too). [/quote] Perhaps the best way to say it is that a CPU is a generalized processor, and a GPU is a processor designed to efficiently operate on graphical entities. It's more or less a very specialized CPU - what it is designed to do, it does much faster than a general CPU, and what it wasn't designed to do, it does much, much, much slower.
  4. Yeah, if you can make a file in storage, things will be a lot easier. You can make a 64k bytemap and count up to 256 occurrences there - if you have more crop up, make a 64k temp file and increment the corresponding byte in it, then set the one in your memory to zero. Unless a number comes up more than 65536 times you won't need to worry (and if it does, you can create a second file in storage). After you're done reading your input, you just have to go through the files in storage in descending order - the highest there is the highest overall, and ties are broken by a lesser storage file if there's more than one or the one in memory as the base case.
  5. Yeah, the need for experimentation is pretty often unstated, but very important. People are notoriously bad at seeing what actually is costing them time so they try to optimize everything. It's variable on the code, of course, but I have a software engineering book here whose author mentions several times that 5% of his code caused about 90-95% of the slowdown. Optimizing everything as it's written in that case means 95% of the work is wasted. You might call that habit suboptimal [img]http://public.gamedev.net//public/style_emoticons/default/tongue.png[/img] (Not that you shouldn't ignore obvious inefficiencies as you write, of course, but weigh "this'll be easy to change later" and "this is easy to read" over "it'll run faster if I do this," especially before you actually profile it)
  6. [quote name='iXenocider' timestamp='1339616452' post='4948898'] [quote name='szecs' timestamp='1339615413' post='4948890'] *Um.... How about using multiple files? One file per map. [/quote] That would not help with anything, the total file size would be exactly the same. [quote name='szecs' timestamp='1339615413' post='4948890'] *If there's a lot of repetition on the maps you could compress the map (for example with [url="http://zlib.net/"]zlib[/url]) [/quote] I can try that thanks, but it takes time to compress and decompress. I don't want them to be waiting for 3 minutes just to save or load their game. [/quote] Combining those two will solve each others' problems, actually. You break the massive world object down into subobjects, and compress those (or encode them in an efficient manner of your own devising, which is really the same thing.) Your world is smaller, as everything is compressed. And since you don't have to decompress it all at once, you don't have huge lag spikes - only the portion being loaded has to be decompressed. It has other benefits too - your RAM usage will be a lot lower, your disk reads will be a lot smaller (though, admittedly, they'll happen less predictably), and so on.
  7. Inukai linked to some good posts. I answered another topic with a post that may be of some help [url=http://www.gamedev.net/topic/625685-cxna-or-pythonpygame-for-game-development-2d-side-scrolling-like-terraria/page__st__20__p__4946951#entry4946951]here[/url]. Basically, I'd recommend checking out university websites that have online computer science departments. MIT is the one I use the most, but there are others out there. Of course, going through all the courses is unnecessary unless you have the goal of learning computer science rather than just getting the ability to code games, but the foundations of the introductory courses will serve you well in programming. Another pretty good advantage is you won't be stuck thinking "what should I program...?". The professors already have laid out exercises to teach you fundamental things like using classes and recursion, which, personally, was exactly what I needed and is something a lot of tutorials don't provide. As for 'good programs to program with', are you talking about the text editors and development environments that you can program in? Those will be very language dependent. Python usually comes bundled with IDLE, which is an excellent (in my opinion) environment. For C++, I liked Code::Blocks, but my libraries got all screwed up recently so I started using the command line. I've never programmed in Java, but I know people recommend Eclipse and NetBeans. I would probably recommend starting with Python - the two main reasons I've seen people try to start with C/C++ is because it's the industry standard and it's so fast. The reason it's the industry standard is partially just based on inertia, and industries tend to use what they know because it's what they know, rather than because it's actually better, so don't read too much into that. As for speed, it is certainly very fast - but a good coder with good knowledge of algorithms will be able to write something faster in Python in about a fifth the time it takes a newcomer to write a less elegant solution. People get pretty obsessed with speed (myself included), but the truth is that if a program is running slowly in Python, it's probably because the programmer took the naive approach and brute forced a solution rather than implementing an efficient algorithm. And if you're just starting out, Python is good because it's not going to make you deal with some of the nasty, nasty low level stuff that C++ does. I have spent far more time hunting down segfaults than is reasonable, because I jumped into C++ before I knew how to handle its power.
  8. I have a suggestion in a bit of a different vein. Well, actually it looks like the same vein as Serapth, but I'm going to reemphasize and expand on it. You mention you started with batch scripting and have used various other languages. Also, you say you're 15 - am I correct in inferring that you've never taken a formal class in computer science? There's no shame in that, but it does mean that there's something you have to be aware of. Learning a language isn't really what you need to do. It's likely that your knowledge of programming is all imperative. Again, there's no shame in that, but it means that if you jump headfirst into making a game, or even learning a language, you're going to be getting a bunch of information that you won't know what to do with. I tried to learn C++ before studying computer science, and I thought I knew what I was doing; I was, however, sorely mistaken. Not only did I not know what I was doing, I didn't know that I didn't know what I was doing. There's an entire, rich, important world of computer science out there, of paradigms from declarative to functional to object-oriented, and until you wade into it, you probably won't truly understand what you're doing, and more importantly, why you're doing it. It can be extremely frustrating both because bugs will pop up that you don't understand and because your design will be, in a word, poor. At least, that's what I experienced, and it was very disheartening. To that end, I'd recommend picking up and going through introductions to computer science. I actually have something that might be perfect for you - check out [url=http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-00-introduction-to-computer-science-and-programming-fall-2008/]this[/url]. It's an introduction to computer science done by MIT - it requires little in the way of prerequisites, and teaches important, foundational techniques in CS. Things like debugging, container types, basic algorithms, and recursion. Best of all, it uses Python as its main language - if you do the problem sets, by the end you'll be filling out a skeletal program to model virus populations within an organism. It only takes a few weeks if you study hard every day. Though I haven't done it myself, there's also [url=http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-00sc-introduction-to-computer-science-and-programming-spring-2011/]this[/url], which is the same course but designed for learners over the internet. Remember, you'll be learning Python this way - but rather than the shallow understanding you'd get from just skimming documents and tutorials, you'll get a rich understanding that you'll be able to apply to other languages and problem areas. That all may seem harsh, but I see myself about ten months ago in your posts. I had brief experiences with languages and thought I knew enough to get started making a game. All I did was throw together code so poorly that I got frustrated and gave up. I spent the next several months learning everything I could from MIT's courses and various forums. I'm far from an expert - I've only actually finished about three of the introductory courses, and my own game project is basically only at the point where I have colliding blocks on the screen. But I do know that if I hadn't gone through those courses, my code base would be a mess and I probably would have given up on programming entirely. Though my code is still terrible, it's leagues ahead of what it was, and uses many important concepts, like abstraction barriers and data hiding, that I didn't even know existed before. It's a long road, but ultimately it's one of the few that will get you where you want to be. I wish you the best of luck.
  9. Hey there! If your code seems to be working ok, that's the most important thing - but I think I see a few nasty bugs (and a few ways to clean up the code, while I'm at it). [CODE] if(moveRight == true && moveLeft == false) { if (xVel <= maxSpeed) { xVel = int(0.40 * speedTimes); speedTimes +=1; } } if(moveRight == false && moveLeft == true) { if (xVel >= (maxSpeed * -1)) { xVel = int(-0.40 * speedTimes); speedTimes +=1; } } [/CODE] You can, in theory, switch between these two instantly. Since you reset speedTimes only if there is a frame where the left and right are both pressed or both unpressed, if someone were to release right and hit left at such a time that the code below isn't executed, your xVel would invert itself entirely, causing the object to fly off in the other direction. (A clever person could also abuse this to get arbitrarily high speeds, as speedTimes is incremented each time the trick is pulled off) [CODE] if(moveRight == false && moveLeft == false) { if(xVel >0) { speedTimes = 1; xVel = -0.20; } if(xVel <0) { speedTimes = 1; xVel = +0.20; } } if(moveRight == true && moveLeft == true) { if(xVel >0) { speedTimes = 1; xVel = -0.20; } if(xVel <0) { speedTimes = 1; xVel = +0.20; } } [/CODE] First off, you can simplify this. The bodies of the conditionals are the same, and you can test for both conditionals at once by seeing of moveRight and moveLeft are the same. But, this doesn't seem to be what you want. If the person lets go of the keys, then xVel will be set to a constant - no matter how fast they were going, it'll be set. I suspect you want something more along the lines of xVel-=0.20;, as that will cause slowing down instead of instantly changing the speed to a constant. Also, you set xVel to a negative value if it's positive, then have an if (xVel<0) clause right afterwards. That'll get triggered even if it's positive, since it will pass through the if(xVel>0) loop first, which will set it to a negative value. I suspect an else if clause was what was meant. Though, even if you do all that, you'll still be vulnerable to the glitch in the other part of the code - pressing left or right will instantly set the velocity to that direction, regardless of your prior direction. In fact, every time you change xVel, you change it to a constant or a multiple of another variable (speedTimes) which is actually independant. I would not recommend that - set it based on its own value. It's easier and far less likely to end up with bugs like the directional switching one. I'd probably rewrite the thing like this: [CODE] if (moveRight == moveLeft) { if (xVel>0) xVel-=1; if (xVel<0) xVel+=1; } else if (moveRight && xVel<maxSpeed) { xVel+=2; } else if (moveLeft && xVel>(maxSpeed * (-1))) { xVel-=2; } [/CODE] You could also use xVel as a float, and cast it as an int when using to to physically move the object. I just chose to make it an int here so I wouldn't have to deal with rounding errors (like it possibly never actually hitting zero and thus oscillating when moveRight==moveLeft).