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

Bucket_Head

Members
  • Content count

    143
  • Joined

  • Last visited

Community Reputation

308 Neutral

About Bucket_Head

  • Rank
    Member
  1. Heh. Well Scott, I won't tell him what to do -- though I will offer him some advice. Species, I think the question at the heart of all of this is really whether you want to focus on 3D graphics or on making a game. The reason why people so often strongly recommend completing a 2D game first before taking on 3D is not because 3D graphics are so difficult in and of themselves -- it's because making a game is so involved otherwise. There are many different complicated components that make up a game, and careful design and thorough methods are required to bring everything together effectively. If things are handled poorly, you end up with a mess that's very hard to work with -- and that will make you tired and irritable, and likely bored. If there is no other impetus to work on it besides your own desire to do so (which is waning at this point), then you will leave it behind and take up another, more interesting new idea. This can lead you down a path of many half-finished projects, which is quite common among hobbyist game developers. The knowledge required to actually finish games is borne of discipline and forged with experience. It is a knowledge of rigorously enforced slow-and-steady methodology. Most anyone schooled in these truths can assure you that you want to minimize complexity when working with new, unexplored technology -- that is, if you're still figuring out what is involved in making a stable and complete game engine (and if you think graphics and input are it, you've a lot to still pick up grasshopper), doing that at the same time as figuring out what is involved in 3D graphics is indeed taking quite a massive bite for yourself, which you'll find difficult to chew. It's encouraged to do 2D first because, with the graphics so simple, it's a fine grounds to let the logical organization of a simple game engine framework come to fruition before upping the ante to 3D. It's building a backbone before you walk, basically...and it's much easier to do this than it is to arrange an effective game engine design around some quickily hacked up 3D code (which your first explorations into 3D graphics surely will be, as most everyone's are). If, however, you are less interested in making a game engine than in playing around in 3D graphics -- which I don't mean to insult; it can certainly be a lot of fun and a very worthwhile activity -- then by all means screw 2D and go to 3D. It's basically a question of what you want to explore and focus on first -- 3D graphics, or a proper game engine. You can best make that call because you know best about what you want to achieve.
  2. Quote:Original post by Anonymous Poster A simple implementation for the propsal above would be to slow down the time for the player who starts its bullet time and let him act upon the saved state of the game. After some determined time the player's time has to be accelerate to catch up with current game state. This would allow the player to aim with more precision because other players are moving slower. The other players would see this as damage coming from the player even when they are already moved past his line of fire. (can also be seen during ping spikes, some older fps games can be tricked by forcing packet drops to make everyone stand still for a brief moment) The end result would be: -nice effects and easy targeting for the player involved -bad movement artifacts and lag like hits for others That still sounds pretty bad for the non-bullet time player; they see the bullet time player shooting in a different direction, yet they get hit? This would come off as a buggy lag-induced experience -- which is true enough, as we're inducing a lag in gameplay for them to produce this effect. However, we can still bend the bullet time player's aim so that they do in fact shoot and hit the non-bullet time player. We can pass this off as relativistic phenomena. If executed well enough, it would simply seem that the bullet time player aimed well and hit them. Quote:Original post by Shuger i found this by searching gamedev site: http://www.gamedev.net/community/forums/topic.asp?topic_id=333833&PageSize=25&WhichPage=1 if i remember right FEAR multiplayer uses bullet time effect, you can also check FEAR Combat which is the game multiplayer without single, i'm not sure but i heard it's free. This is an interesting paper so far (I'm about halfway through) and I recommend it for all interested in this thread. I like their idea of dealing straightforwardly in terms of space-time, and expressing game events in terms of communication between active (non-deterministic) entities through use of passive (deterministic) entities that travel over contours in space-time. These contours can be shaped as is most convenient to fit your lag and timewarping situation. Of course you very much need to distinguish between what actually happens (game state) and what you see (mere visualization). If we feel the need to visually indicate signs of discrepency between the two representations, we can do so via relativistic effects, such as the bullet-time blur effect and possibly through use of brightness or color to give more information as to the nature of the discrepency.
  3. I like Anonymous/Haphazardlynamed's idea re: dead reckoning hacks. You could increase the speed at which you estimate they could have traveled, and render a blur effect as you move the character -- so that as you get corrections, you'll get very fast blurry motions (from the non-bullet time player's view) which are conducive to the effect seen in the Matrix movies. The "Time Grenade" idea also sounds like an innovative weapon idea that would be fun to play with. Of course (?) I don't see this idea working in an MMO so much as in a game with networks of a standard FPS scope (ie maybe up to 32 players in a single game). A thought that I had was allowing players to be at differing points in time. Basically, you'd all start off at a synced clock time, but due to various actions (including invoking bullet time) you could throw your times out of sync. Playing on oliii's idea of limited time travel, it would be incredible if the game was automatically logging players' motions with timestamps, so that if you happened upon a player who was a few seconds ahead of you, your copy of the game would be playing their actions back, so you'd be able to get the drop on them. The game would notice the discrepency in the two players' current times, and might throw one player into bullet time to let the other one catch up. So what you'd get then is one player would have a moment of advantage on the other player (while the other's recorded motions are played), but then the advantage would be reversed as the formerly disadvantaged player now gets some bullet-time to catch up. This could add an element of strategy involved; do you want to keep your clock a bit ahead or a bit behind? Still, it might seem that the player who's ahead might have the disadvantage -- if the player with the earlier clock can do enough damage in the time they're allowed, then the player with the later clock doesn't even have a chance to fight back. To give them a chance, the later player might see a "time disjoint" version of the earlier player, manifesting as a bullet-time-effected player, which might give them a chance to realize thay hey, this might be a time to go back a bit in time a bit to even things out. If they do this soon enough, they can even up the advantage sooner, so that they'd be on an even par again -- or they could go a little bit further back, causing a little bit of a crazy fourth-dimensional cat-and-mouse game (while energy lasts). Hmm...What I'm seeing now is a game in which you can change your rate of time forward and backward, where deviations from standard time rate cost power, and achieving deviations that are further from standard time position cost exponentially more power, which will keep players fluctuating between a nice, controllable range. Aha, and perhaps when you move forward in time at an accelerated pace, you regenerate power a bit faster? This might give players an incentive to go a little bit ahead of time, so that they'll have more power, yet will be more susceptable to someone getting the drop on them. If they're really fast, they can use their power to reverse the drop -- they'll likely have more of it, so they could win a war of attrition...if they're skilled enough. Ha, I really like where this is going. In short though, when things get out of whack, you could basically fudge it a bit and let things get a bit crazy and as long as it's awesome and there's some sort of internal consistency that players can become adept at exploiting, there will be devout fans who love it. If someone were to run with the disjoint time idea, the bullet-time effect can be used as a good cover for fudging correcting discrepencies in general.
  4. Quote:Original post by dwarfsoft Quote:Original post by da madface and, if i want do something illegal? If you talk about it here then you get banned. We don't like thieves who rip off other peoples works. It sounds to me like this is a problem only if the software/data is not open source. Madface, are you familiar with open source software? The basic idea (as I understand it) is, you're free to use and modify open source software, as long as you present your modified software likewise as open source -- so you can't modify it and refuse to give it away, essentially. If you're cool with that, as it sounds like you would be, then it's just a matter of finding a Pac-Man clone that you like that is open source. Then you can modify its data as you like, and present your own modified version as open source itself. Open source software tends to be licensed in some way -- the details of what you're getting yourself into (nothing bad, but you just want to be aware of what your obligations may be and what you're not allowed to do) will be in the license the software is released under, which (hopefully) will be provided along with the software when you download it. Good luck!
  5. It seems most people here think madface wants to make his own Pac-Man game with his own sprites, but that's not what I see here. It sounds to me like he just wants to end up with a Pac-Man game whose sprites he can control. Madface, why not just google to find and download some homemade Pac-Man clones (there must be dozens out there at least), find one that loads in bitmap files for the sprites, and then go edit those yourself? You might even be able to find one that reads in levels from text files, so you could edit those too. I think sometimes we get a little overzealous in pushing people down the game programming path, when it's not necessarily what people are asking for... Sneftel, you had said he can't edit Pac-Man data -- I'm wondering if you're referring to copyrights? If he's simply making modifications for personal use, does that violate copyrights any more than making a clone of the game would?
  6. Scott, first I'll take a moment to stress something that you've probably already heard before, but that I feel obliged to say anyway. Yes you're right that making an MMOG is not the greatest of ideas -- and I'll tell you why. You're young, you're learning, and you're doing this as a hobby in your spare time. Maintaining an MMOG though, if it's at all successful, is a constant job. It's not something you can do just as a hobby in your spare time if it's going to stay up -- it's going to take money, in the end (your money, since it's your project) to pay people to keep it up, or even just to feed yourself while you keep the game up. It's really just not a good investment of your time; you'll sap all your time and energy on one project that you will get tired of, when you would have learned and grown so much more and had much more fun doing several smaller games instead. If you scale the scope of your projects small enough that you can finish them by the time you get tired of working on them (and you will), then what you've done is accomplished something to its full extent -- all the while learning and staying enthused. Switching between multiple, varied projects will also stretch your skills in myriad directions, so you'll become a more experienced, well-rounded hobbyist game developer. It's just a better thing to do. To that end, and I urge this, do small games. Do tiny games. Make Tetris. Make arcade games like Pac Man or racer games or fighting games. Hell, make freaking Mega Man or Mario spin-offs. Have you seen Gish? That game is incredibly fun -- and it's a simple platformer (albeit with great physics). You can even do small-scale multiplayer games like Diablo-scale, where anyone can set up their own small server that's not assumed to be dedicated and people can have their own small, fun sessions -- that'll be more fun to work on for a hobbyist like yourself than a full-blown MMO. If you want ideas, take a critical, analytical look at anything you do in your life that would make fun. See an interesting science fiction movie with a nice premise? "Hey, I wonder how that would work as a game...just a simple arcade game where you need to escape-the-whatever would be great!" etc etc. You can also take a look around at other indie games people have made, to see what sort of scope other people are setting for themselves. Zombie City Tactics is another neat indie game that graphically is quite simple, yet has nice tactical game play that can be challenging and entertaining. So, in short, consider taking on the challenging of finding a core element of fun, and formulate a tiny kernel of a game idea just around that -- and don't expand too far past that for the final game design. In my opinion, that's what makes for the best games anyway; simple, fun, great. Make those Scott, and I'll play 'em. I don't really care for MMOs anyway.
  7. I can attest that this difference in attitudes towards work between artist and programmer extends beyond the hobbyist sphere and into the professional. In my time having worked professionally as a game programmer (a little over a year now), time and time again it is the programmers that stay late to work further while the artists go home at a time (say 6 PM) that would be considered standard outside of the game development industry. While sure, it could be argued that the nature of the programmer's work tends to simply demand more time (programs will have bugs that require fixing...but if the art looks good, it's done), and that that is the main reason why programmers stay late, I believe there's a more fundamental issue at play here. In short, in my opinion, the programmer is more passionate (read: more obsessive) about the work. This is not simply a job for them, this is their life -- they live and breathe the code. For the artist, however, it is more simply a job, and most definitely not their lives; artists do tend to be more "normal" and less "obsessive" about their work than programmers in my experience, and have social lives that tend to be more socially acceptable outside of the game industry. Considering this theory, it seems to make sense that the programmer would want to stay late, to continue doing the work they love, while the artist would be more likely to scoff at the idea of working "unreasonable" hours for (what is likely) meager pay. The artist would be more apt to quit under bad work conditions, whereas the excited, driven, and naive programmer is simply happy to be there and is likely to put up with whatever he has to so that he can be allowed to program games professionally. I believe that, for better or worse, these are elements of the commonly accepted culture that we live in, and that we all (to at least some degree) subconsciously buy into and so perceive as normal and expect, and that we ourselves perpetuate (knowingly or not). Consequently, this will naturally carry over into the hobbyist sphere as well, where the artist doesn't want to waste his time on work he's not getting paid for, though the programmer sees the act of coding as an end in itself. I realize that my analysis has painted the programmers as the real liberal artists and the artists as the more vulgar, illiberal wage-oriented folks. I do want to say that I don't mean offense by it, as artists can be very idealistic and driven people as well, and that there are always plenty of cases that break the mold. Still, I feel pretty confident about this, and I'm curious about what an artist's response would be.
  8. OpenGL

    No, don't do what Anonymous says, heh. Here's the deal. You start with x increasing to the right, y increasing upwards, and z increasing out of the screen, towards you -- right? Normally, you might come to interpret this as saying that x is right, y is up, and z is forward/backward -- and increasing backwards, which seems strange. This is not the only way to interpret x, y, and z. Take a step back and remember -- they're just axes. The directions they refer to can be whatever you want them to be. All you have to do is just say that x increases eastward, y increases northward, and z increases upward (which I think is what you want) and bam! You start by looking down on the scene from above, instead of starting by looking forward. In this you achieved your goals, just be redefining what x, y, and z mean for you. From there, all you need to is render all of your geometry with this reference frame in mind. You'll probably want to lift your camera upwards (in the +z direction) to get a better view of your scene, and you may decide to rotate (pitch backwards by rotating about x) to look forward instead of downward, but that's your business. I hope this helps. Good luck!
  9. Hey there, I've been programming games professionally for about a year now, and it's definitely fun, rewarding work. I'll be happy to draw on my experience so far to respond to several of your questions. Quote:Original post by solinent In a typical team of game developers do some developers code and others model, or do they do both. Obviously I should learn both, but I was wondering how a typical game environment works. Typically there are a few distinct roles in game development, and a given developer will adhere strictly to one of those. You'll have programmers that do not do art, and artists that do not do code. It's also common to have sound and/or music people that focus solely on creating their content files, and sometimes a group of artists will be subdivided into 2D pixel artists, 3D modelers, and animators. You may also have people devoted to creating levels, or to writing scripts used by compiled code to change data in-game (such a position is sometimes given to programming interns). This all of course varies dramatically on the size of your team -- indie projects may involve a small handful of people that each wear many hats, whereas professional development teams of twenty or more people that can each afford greater specialization. With more distinct roles, it's also helpful to have people that can speak enough of everybody's language to help coordinate people -- which is where roles like producers, who (though they may not be considered developers in the strict sense) are indeed absolutely essential, come in to help make sure that nobody's waiting indefinitely on somebody else and that the project moves forward smoothly at a steady pace. So in answer to your question, actually, it's not at all required that you learn both. Becoming familiar with a variety of disciplines can always come in handy because it can help you be more effective at communicating with co-workers in other disciplines, and so you can better understand how to work with them towards solutions, but it's not required that you master every single trade. You're far more useful in this industry if you do have a specialty -- so keep that in mind. Quote:Original post by solinent I am 14, and I know web development and C++ programming and visual basic programming and windows programming, but I am just getting started in DirectX or OpenGL. I found a bunch of tutorials, and I was wondering how things are controlled. Is it all effects and environments are made in the model program, and they are loaded and made interactive with code? And only when certain objects need to be changed the programmer has to alter them? Because I'm using Blender for modelling and it has many features to make models and textures and such. But DirectX has similar features (Like adding transparency to a cube in DirectX, or adding it at model time and just importing it?) As you say, typically you have various data files that are read in by the program at runtime and displayed and interacted with as according to the code. Nowadays many developers try to do their best to make their projects "data-driven" meaning that more and more of how the game works is described in data files rather than explicitly in the program code itself. The program code is arranged mainly to know how to interpret the data files, and how to do what they describe. This makes the game very flexible and easy to alter, and less error prone; in general, the simpler and more generalized you can make the program code, the less likely you will have convoluted errors in very specific, hard to track down cases (which tend to require obscene hacks to fix when you're down-to-the-wire and need to ship the product soon). The more abstract you make things, the easier they will be to work with -- and offloading work from programmers to level designers is a pretty good win also. Quote:Original post by solinent I'm only in grade 10, and I am just getting started and I would like to know since the industry is progressing so fast, is there even any point in learning online (I am constantly finding old documents and such, right now I'm using tutorials from directtutorial.com which is making all the tutorials still. (so they are new). It's always good to keep learning -- just take it all in, everywhere you look. You're right that the industry is progressing fast, and it's very true that many things will be radically different by the time that you make it to a time when you are ready to join the industry. However, there's that old saying that "the more things change, the more they stay the same" which definitely applies here. There is a good lot of fundamental theoretical knowledge that all of our technology is based on, and this is stuff that's not going to go away -- new technologies are just going to be more interesting and refined developments of the same fundamental truths. School (universities etc) is a great place to get firmly grounded in this theory, and to develop the abstract reasoning skills that will help you maintain the adaptability to pick up any sort of new technology as it comes and run with it -- and even to combine differing ideas with some of your own and come up with new technology yourself. It's been said (and I agree) that the university is a place to "learn how to learn" in a way that you hadn't before -- so it's definitely worthwhile (as long as you put your all into it) to just keep learning, everywhere you look. Quote:Original post by solinent Anything I should know to get me into the gaming industry? Also, what do I need to do in university to get into the gaming industry? I'm more interested in what kinds of universitys offer gaming programs, or whether I would just have to learn the seperate parts and combine them myself. I am very critical of these gaming programs being offered at universities nowadays. Sure they may provide the job training that works as a jump-start to attaining skills used in the industry right now, but my concern is that they may skimp on the depth needed to be able to think all the more outside-the-box and roll with the punches as things continue to progress and change in the industry. I encourage you to go for a more traditional computer science degree (if you decide to go the programmer route) which, though it may not be as specific as game programming, will grant you a profound knowledge that is quite applicable to game programming. That being said, though, one of the most important classes I took when I was at a uni was a class in software methodology -- a less theoretical and more practical course. It dealt with working in teams (typically programming assignments in class are totally done individually) and coordinating goals together, gauging progress, and formally and explicitly declaring ahead of time what exactly it was that's to be made (extremely important to do for any nontrivial project). Do be sure that you look into this area (how to go about working together to effectively get the work done) in addition to exploring the details of the work itself. As for actually getting in, the absolutely most effective way is to know somebody on the inside who can recommend you (or directly hire you if they're in a position to do so). For my first shot at professional game development, I was hired by an old friend to work on a Nintendo DS game -- and after getting experience on that, I was able to land my current job (and I've helped gotten two of my friends hired here so far). Short of that, you're going to have to develop some decently impressive work to show off, and present that in some sort of portfolio along with a resume, and hope that that gets you an interview -- at which point, if you're pleasant and seem to know your stuff, and aren't up against others that seem much more impressive, you'll probably have a very good shot at getting hired. Good luck on working your way in -- it'll take years of involved study, but if you keep at it, you'll get where you want to be.
  10. Quote:Original post by lordcorm What i meen is this: If i created to differnt files (mainframe and monster) how whould i make it so that i can link the monster file to the mainframe and get the monster function and use it in the mainframe Ah okay. Well, for this, we need to remember a few things: mainly, we need to be able to differentiate between definitions and declarations, and we need to remember that each source file is compiled from scratch separately. For the first part, a definition is actually where you specify that you want to reserve a spot for something to be created definitely, whereas a declaration merely indicates that the thing is defined somewhere, without actually defining the thing. (You don't necessarily need both; a definition by itself works fine as a declaration, too). You may wonder why you need this distinction, but it does come in handy in many cases. If you're defining two things (say, two functions) that each need to call the other, you may be in trouble, since the definition of one necessarily has to go before the other. Before the compiler has read through the definition of the second, it won't know what you're talking about when you try to call it from the first, and so will generate a compiler error -- an "unidentified identifier." However, if you simply add a declaration of the second function up above the definition of the first function, then the compiler will have an idea of what you're talking about when you try calling the as-yet-to-be-defined function, and things will go smoothly. What I mean by the second part is, when the compiler compiles each of your .cpp files, it does so without being aware in the slightest than any of the others exist. This is why you need to have the same set of #includes or whatever at the top of each one -- the slate is wiped clean with each new file, so every new thing you want to work with needs to be redeclared. Now we can start to see how declarations allow you to lay things out in different files, but so that they can still reference each other. Just make sure that when the compiler compiles a file, everything that's referenced has either been defined or declared within "sight" of the file (either in it itself or via #includes) so that all identifiers will be understood. The other thing that's required is that whatever's being referenced (be it a function, global variable instance, or whatever) can be resolved in the linking stage -- if you declare something that isn't actually defined anywhere, you'll compile just fine, but linking will fail. Likewise, if you define it in more than one object, when you try to link, you'll get errors due to redundant definitions. The last thing I'll comment is a matter of style and code hygiene. Suppose you have a function defined in one source file that you reference in a dozen other source files. You could copy and paste the function prototype (which serves to declare the function's existence) into each of these source files, and that would work fine. However, if you were to then, say, add another argument to the function's argument list, and forget to change all of the prototypes, you'd get linking errors due to things not matching up -- and you'd manually have to look through and find the problem and fix it. That can be a hassle! A better solution is to put the declaraction in a single header file, and have all of the source files that want to reference it #include that. This way you only need to make the change in one place, and then the compiler will be able to point out all the erroneous spots where you forgot to add the extra argument where you made the call, complete with line numbers -- which is much better than the linker will do, which is basically just tell you "oh, linking error...this symbol is undefined in this object. Don't look at me; you wrote it." Quote:Original post by Oggan just want to let u know that wasnt a waste of time writing all that for him, cuz i read it and learned from it =) Glad you found it worthwhile.
  11. I'm not quite sure what you're asking -- are you asking about the linker? As you may have noticed when compiling programs, your compiler generates some intermediary files called object files that probably have file extensions like .o or .obj. These are binary files that are much more machine-readable than the C++ source code files you write, but they're still not the finished product. Generally speaking, a compiler will work on each .cpp source file independently and (provided there were no errors in doing so) it will generate from the source file an output object file. At that stage the compiler is done, and the linker will take over. The linker takes these object files and links them together into a final output executable file. In this manner, you can work on a single project that is composed of many source files, and still manage to combine them together into a single program. There are several advantages to this strategy of organization. If you're using an intelligent make system, then modifying a single source file will only require that you recompile that single file (instead of all of the source files in the project, since files that haven't changed would just generate the same object files that are already there) and relink the object files in order to build your program. Also, you can decide to build a library instead of an executable as your output, and libraries can in turn be linked directly in with the object files of other programs. This is how you are hooking in standard library calls like for printing and working with files -- these calls aren't syntactically speaking a part of the language itself; rather, they're amongst a set of standard libraries that are included in standard distributions of C++ compilers. Your intuition about adding complicated systems (like a health or medicine system, sure) to a program via the linker is correct -- you would want to write code in separate source files, keeping things organized, and compile separate object files, and link things together to complete the build process. Here is a wikipedia article for more information: http://en.wikipedia.org/wiki/Linker As for how to actually get things linking at the command line, it varies by compiler. I recommend that you read through your compiler documentation or ask around (asking about a specific C++ compiler) to find your answer.
  12. Hey, if you feel that something is beyond your ability, that's a good time to start extending your ability. With this sort of problem, I find it useful to try looking from different angles (so to speak), including looking at simpler versions of the problem. Consider the 2D case -- much simpler, I know, but as we'll see, we can draw some very useful wisdom from it. As I'm sure you know, you can represent a two-dimensional rotation as a simple number, an angle, typically in radians or degrees, with 0 pointing right and increasing counter-clockwise. You can just as well represent a two-dimensional rotation as a rotated reference frame -- a pair of orthogonal (perpendicular) unit vectors that form a basis. Let's picture these vectors in our minds as arrows pointing out from the origin. You start with a vector pointing along the X axis, with coordinates (1, 0), and another vector pointing along the Y axis, with coordinates (0, 1). If we apply a rotation of 90 degrees, we get a new reference frame, with the first vector rotated to become (0, 1) and the second vector rotated to become (-1, 0). A handy way to visualize this is by taking the thumb and forefinger on your left hand, forming an L, and to tip it counter-clockwise 90 degrees. Now, as you may know (and if you don't, you can see that it is true with trial and error) the coordinates of the first "x" vector, as it is rotated into a new reference frame by some angle theta, follow a pattern -- the coordinates will be at (cos theta, sin theta). The coordinates of the second "y" vector are like those of the first, but 90 degrees out of phase ahead of the "x" vector -- with coordinates at (-sin theta, cos theta). More information about this phenomenon can be found at http://en.wikipedia.org/wiki/Unit_circle. Next, take a look at a 2-dimensional rotation matrix: [cos(theta) -sin(theta)] [sin(theta) cos(theta)] Hmmmm...say, aren't those the coordinates of the "x" vector down the first column, and the coordinates of the "y" vector down the second column? By jove, it is! I'm not going to delve into a full explanation of just how this works, though if you spend about ten minutes thinking about it and tooling around with a pencil and paper (and considering the definitions of sine and cosine, and they shape of their wave patterns and such) you'll hopefully arrive at a fairly intuitive understanding that you can work with. But in any case, you can do the same thing with vectors in 3-dimensional space. Any arbitrary rotation in 3-D space can be represented as a 3x3 matrix with three mutually orthogonal unit-length vector columns -- and these would be the "x," "y," and "z" vectors, exactly as they are when rotated into place. Very straightforward, isn't it? You could simply maintain one of these matrices to represent ship orientation, and whenever you want to change the ship's orientation, you can simply multiply this matrix by a matrix representing the small rotation change, and the result is the rotated matrix. A few notes though -- first and foremost, beware of precision errors accruing! Over time, your vectors might wear down and change to non-unit length, or stop being so orthogonal. There are steps you can take to fight against this though -- think about it. An alternative is to explore the crazy world of quaternions which are much smaller (a mere 4 floats vs the 9 you'd need for a 3-D rotation matrix), which are less prone to precision error wear and tear, and which multiply together much faster than matrices do -- however, they are more difficult to comprehend. Still, if you're interested, you can start by following a similar path to what's outlined above, and begin by exploring the 2-dimensional version of quaternions, called complex vectors or even complex numbers. Even besides all that, many people have utilized quaternions without understanding them at all, simple working with them as a black box, and using them as a drop-in replacement for rotation matrices. Anyways, more food for thought.
  13. Ol' Hap (aka Anonymous) speaks truth. I'll explain it using an analogy. Basically, you're performing a coordinate transformation here. You've got the coordinate system of your source image, and the rotated coordinate system of your destination image. Your algorithm, as implemented, is: for each pixel in the source image, ...transform its x,y coordinate to a rotated x',y' coordinate ...copy the color from source@(x,y) to destination@(x',y') But consider that you're working with floating point values when you do your transformations, but casting to int when you do your final plotting. When you cast to int, ofcourse you lose precision -- and you're not even rounding here; you're slamming the float value you had to the next int closest to zero (if the int > 0, you're taking the floor; if it's < 0, you're taking the ceiling). But nevermind that; ask yourself first why you are so sure that your algorithm will not "miss" any x',y' pixels in the destination image (as it most clearly is). Certainly, not all transformations, when implemented in this for-each-source-pixel manner, will catch every pixel in the destination image. Let's say, hypothetically, that instead of performing a rotation you were performing a scale. Now, if you're scaling to a smaller size, then as you iterate over all pixels in the source image, inevitably multiple pairs of x,y coordinates in the source will map to the same x',y' pair in the destination -- and you will redundantly place the same pixel coordinate a few times, depending on how extreme the scale is. Conversely, if you're scaling to a larger image size, there will be some x',y' coordinate pairs that no x,y pair maps to. This is clear from the fact that there are simply more pixels in the destination image than there are in the source image -- and so, since we're only plotting as many pixels as there are in the source image, there must be several that we're missing (forming stretches of "missed" pixels between any "hit" pixels, again depending on the extremity of the scale). With a bit more thought of how to circumvent this problem, we can see that if we instead choose to iterate through each of the pixels in the destination image, and for each x',y', do an inverse mapping to get at the corresponding x,y in the source image, and then copy the color value over, that we can rest assured that every pixel coordinate in the destination image is getting set. This will then work regardless of how big we might want to scale our destination image relative to our source image -- we won't have any of those bothersome gaps between pixels. This also has the added bonus that if we try to scale to a smaller image, we don't end up hitting destination pixels redundantly -- each destination pixel is hit no more and no less than once, which is exactly what we need. No holes and no extra processing -- perfect, ne? A similar problem with the missing pixels is occuring here, due to rounding errors (as mentioned above). The simple solution is to reverse your algorithm, and have it iterate over the dimensions of the destination image (rather than the source), and to start with those coordinates and perform the transformation backwards to get at the source image, and then copy that over -- pixel by pixel. That way you can be sure that each pixel in the destination image is getting set, since you've processed each and every pixel. I hope this helps, and works for you. Good luck.
  14. Actually, I just realized that it's entirely possible to partition but not have either of the new subgraphs be closed (if the enemy has touched the insides of both sides, foiling our nefarious scheme) or to even partition into three pieces instead of two, and to have (I think as many as) two of the new subgraphs be closed...so keep that in mind.
  15. You are correct in that identifying a closed region of neutral hexes bounded by a contiguous wall of hexes of your color and the wall at the edge of the board requires some sort of breadth-first search. However, in thinking about various situations the game board may come to, I realize that there is some ambiguity in what cases you would consider "closed" (and thus resulting in the simultaneous earning of several hexes). Now, let's consider the hex board to be a graph, with each hex as a vertex with an edge to adjacent hexes. It may prove convenient to allow an outer edge of "wall" hexes forming a border around the board, or it may prove more convenient to simply say that the graph ends with the neutral hexes at the edge of the board. My first thought was that any connected region of neutral hexes with bounding edges to hexes that are either the given player's color or walls would be considered closed and thus takeable -- however, if this were so, our very first move would claim the whole board as our own. You could add a stipulation that you must have made at least two moves, which would have allowed the other player a chance to put one down and thus give you something to work against, but I still don't feel that this is getting at the heart of the problem. Also, suppose we had a situation wherein a player plotted a closed circle (with a hole in the middle) somewhere in the middle of the board. Would this area in the middle of the circle be considered closed in our sense, meaning that the neutral hexes in the middle are considered takeable? Or must the connected region be bounded by both the player's color AND wall? While I could be wrong, in reflecting on what I imagine to be the sort of gameplay that you're going for, the answer would be yes -- that the region in the circle would be considered closed and takeable. If that's so, I think what's really at the heart of the situation here is ultimately a matter of partitioning the game board. If we take the set of neutral hexes as a pool from which to draw vertices, we can determine from these the connected components of the board (being the board's "maximal connected subgraphs" (wikipedia)). Really, the moment at which you will claim territory (en masse) is the moment when you claim a hex on the board that ends up partitioning one of these connected components into two pieces -- and then at that time, the subgraph piece that you take is the one that satisfies our earlier condition of (put most simply) not neighboring any of the opponent's hexes. What we need next, then, is being able to determine when placing a hex partitions a connected component, and then which components are enclosed -- and then ideally to be able to do so relatively efficiently. I'd like to recommend a technique that I happened upon in my A* implementation. As I expect is usual, I had a few fields per vertex in the world for use in the A* algorithm, for marking what I'd visited and so on. Rather than clearing the board after I'd completed a search (so it'd be ready for the next one), I simply numbered the searches, so that as I visited a particular vertex upon a particular search I would leave the number of that search on that vertex. Then with the next search would have a new number (I'd just increment), and since none of the vertices would be labeled with the number of the current search, they were thus cleared for all intents and purposes. If you use such a technique, you can also retain information about which (breadth-first) search spanned a particular vertex (you'd want to not stop abruptly when you detect an opponent's hex adjacent to a visited vertex, but keep going -- just don't visit any non-neutral hexes when searching) and so use this to know which set of vertices are in the same connected component (they'd all have the same search ID). The algorithm would go something like this (with every move taken): - remember which search ID we're at at the beginning of this move - make the move - while there exists a neutral hex adjacent to the spot just moved to whose search ID is less than the current search ID... ...increment the current search ID, ...perform a breadth-first search (w/ current search ID) on said hex When we're done, when we examine the difference between the search ID we'd then be at (after running the above algorithm) and the search ID we were at beforehand, we'd know how many connected components there were. We could compare this to the number of connected components there were before we made the move, and if this number is greater, then we must have partitioned one of the components, and so it'd then be time to claim some bonus territory. If, at the time we perform a search, we track whether we ever come up against against a neighboring hex of the opponent's color, and associate that information with the search ID, then when we realized we'd partitioned a component we'd be able to quickly look that information up (we'd only need to remember for searches for the current move, which really shouldn't have to be more than...three, I think). Then it'd just a matter of iterating over the hexes that match that search ID and coloring them in, woohoo! That should be fast and hopefully seems straightforward. EDIT: Anonymous never forgives. Changed "strongly connected" to "connected" since (as Anonymous points out) "strongly connected" only applies to directed graphs. [Edited by - Bucket_Head on July 14, 2006 4:36:45 PM]