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

caldiar

Members
  • Content count

    478
  • Joined

  • Last visited

Community Reputation

715 Good

About caldiar

  • Rank
    Member

Personal Information

  1. From what I understand you're wanting to have batch files execute based on git events such as post commit and pre commit? The .git folder will be created when you initialize a git project. In the folder you'll have a folder called hooks. You will then see several files ending in .sample. If you rename any of these files to strip the .sample off the end (so, for post-commit.sample you'd end up with post-commit) then git will see that you want to hook that particular event. Inside the file itself you can have your batch file execute by simply providing the path of the batch file. I have a batch file called test.bat in .git/hooks/ and within post-commit I replaced ": nothing" with ./git/hooks/test.bat My test.bat file merely contains "echo hurrah". Now whenever I do a commit in that particular project I see hurrah echoed in the console. From the looks of things it seems that you'd have to set up hooks for every git project you're working with. However, it might be possible to set it up so the .git/hooks folder always has your batch files set up whenever you initialize a new git project.
  2. Check the value of your lighting variable on the other computer. From the code you've posted, only ambient lighting is applied when 'lighting' is equal to 1 (both ambient, and directional are applied when lighting is equal to 2). I don't see where lighting is actually set anywhere in the code you posted but that's a good starting point to take a look at for you. To reiterate, the reason it looks brighter on the other machine is probably because you're only applying ambient lighting when it runs on that machine.
  3. [quote name='Ectara' timestamp='1355393154' post='5010133'] Almost, but the important part is the ratio: 32 by 9 is not a 16:9 ratio. [/quote] Well spotted! Perhaps a sign for me to turn off the computer for the night and go to bed.
  4. Ectara's right. Removing the poorly thought out suggestion.
  5. Take a look at quadtrees. As your level format is already a 2D grid, this would be ideal for quickly determining the largest possible box you can make out of the smaller boxes. The idea is similar to Waterlimon's. Starting from the root node, you would drill deeper into the tree until a node has no empty children or you've met a maximum depth. If all 4 children of a node contain data (boxes) then it's safe to represent that as a single block. Here's a visual, interactive example - http://donar.umiacs.umd.edu/quadtree/regions/regionquad.html
  6. I can't comment on the SFML part of this question. However, I'd like to say that if it isn't broken, don't fix it. It seems to me that your current solution is running fine. I'd say stick to your current solution and focus on the next pieces of your project. Don't worry about the 'alternative solution' unless the way you're currently doing things actually ends up becoming a problem (and verify that the sprite approach is the problem with profiling!) If you're approaching this purely out of curiosity though then, by all means, dig into it. Good luck on the project!
  7. If you're looking at getting your hands a bit more dirty with the programming side of things then perhaps you could look into the XNA framework and focus on making a game with it rather than on using an engine. I found that Blender worked surprisingly well with the content pipeline in XNA as I was able to basically drag and drop models into my game and see them just automagically appear. However, I believe you needed to export to .fbx for that to happen. It was a couple years ago when I was doing this so I'm a bit hazy on how I was doing things... I just remember it being extremely simple and straightforward.
  8. From the looks of it, you have a circle image that most likely has excess empty space around it. Make sure you trim all the excess blank space off from around the circle so that the image is no larger than the square needed to contain the circle. However I can't be 100% positive that this is the case. It helps to be a bit more verbose with what you expect, what actually happened, and what you tried to do in order to fix it. Relevant code doesn't hurt either ;) Hopefully it's just that you need to trim the image to fit the circle better. EDIT: I'm making more assumptions than I usually do. I'm assuming you're making a rect with the same dimensions as your image which you want to use.
  9. While you're at this point, consider the following: A player isn't necessarily a paddle. Rather, a paddle is controlled by the player (or the AI). Keeping that in mind, having the player inherit from the paddle class is probably not the most correct route to go as it indicates that your player [b]is a paddle[/b] and not simply that your player can control a paddle. If you decide to still design your program in such a way, it's not going to explode in your face or anything and will definitely still work, but in more complicated projects it'll start making you scratch your head wondering what exactly is going on. When thinking of the design in terms of 'the paddle can be controlled by either a player or the computer' it makes things a little simpler to work with. You would have a single paddle class whose movement is determined by input received. You could then have a Player and NPC class which each can send input to the paddle they're associated with. The input for Player being created through keyboard button presses and the input for NPC being generated through some set of rules you've determined to affect their movement behavior.
  10. Allocating/Deallocating memory is a pretty expensive thing to do. However, with C# the garbage collector is going to decide what to end up doing with your memory once there are no longer any references to it. It still isn't a good idea to give the garbage collector any excuse to start up and begin sifting through your 'trash'. Ideally, instead of 'deleting' the enemy once it's dead, have your enemies have a bool variable saying whether they're active or not. If the enemy is dead, it isn't active. If the enemy isn't active then you can skip physics, rendering, etc... on that particular enemy during your update loop. Then, when you want to spawn new enemies, you can flag the deactivated enemy as active again and re-initialize the enemy to default stats (back to full health, etc...). It's a bit of a balancing act though since it's not really practical to have everything in your game pre-allocated and always sitting in memory. If you're going to be creating/deleting something quite often, however, you should focus on keeping that in memory as long as possible otherwise you're going to be making your garbage collector work overtime.
  11. After you've been working on becoming a good programmer for a while, you'll find that companies will state that experience within the game industry and/or a B.S. degree are required to be eligible for a programming position. The best way to get experience is to collaborate with a mod team. You could possibly get an internship with a smaller game company for experience but volunteering for a mod team on a game you're interested in will not only give you experience, but also give you something to show off in a portfolio. It's extremely important that you have something to demonstrate to companies showing that you not only can deliver on what you say you can do, but that you have the passion and grit to follow through on projects not for the money, but for the love of it. Of course, this is all after you are comfortable with the language(s) you choose to develop in and are comfortable with programming concepts in general. Having a portfolio, even as a programmer, I feel is essential. Be sure to [i]finish your projects[/i] and only show off what you consider to be your best work. One of the greatest resources you have at your disposal (other than google) is your peers. Don't hesitate to ask questions of others especially here on gamedev when you encounter a difficult problem. Lastly, be consistent. Try to at least program something, no matter how small it is, each day. You will be surprised how much more you learn in a shorter amount of time if you practice and experiment every day rather than every other day. On experimentation, don't ever be afraid to try out an idea because it might be a mistake and break your code. Breaking your code is a good thing. Look into how the code broke, why it broke, and how to fix it. You [i]will[/i] run into bugs throughout your programming adventures; every programmer does. Being able to identify and fix your bugs quickly will be an indispensable skill for you to have. Good luck, take your time, and have fun with the process
  12. I see a 'motion' vector which I would take to mean your velocity. Merely altering the position of the ball on collision will do nothing in changing the velocity (which determines the moving direction) of the ball. I'm unclear on how you're determining how the ball moves through the game world. Are you simply adding to position every update tick or are you doing proper movement with distance = velocity * time (assuming constant velocity since this is pong)? When the ball collides with a surface, you will need to [b]reflect[/b] the velocity vector. Merely changing the sign from negative to positive or vice versa will give you weird results. You would notice this any time the ball is going in a diagonal motion. XNA vectors provide a [url="http://msdn.microsoft.com/en-us/library/bb975900%28v=xnagamestudio.20%29.aspx"]Reflect method[/url] to do just that.
  13. Honestly, the most important math you could know for a solid foundation to build off of would be trigonometry and linear algebra. Ultimately you're working with planes (triangles) aligned within a 3D space (2D if you're making a 2D game). Knowing your trig will be of huge benefit when it comes to triangle manipulation.
  14. [quote name='!Null' timestamp='1349166244' post='4985993'] caldiar I just wanted to say thanks for the quick detailed reply. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] [/quote] Not a problem Ray-casters are always fun projects to work on. They're a very interesting piece of history. It's amazing to me, even today, the results you can get with the relatively simple code and basic trigonometry. I'm really itching to put together a ray-caster now...
  15. You also need to keep in mind how the Unreal 3 engine handles culling with models. If even a single vertex of a model is visible to the viewport, then the entire model is drawn. This is more than likely why loading up a single model for an entire level was killing the performance for UDK; the entire level was drawn at all times regardless of what was actually truly visible. I believe this goes for 'grouped models' as well (collections of smaller models). You would need to balance grouping models together and having individual models for situations such as having a bunch of crates throughout a room. Grouping these together means you only have to check once to see if any of the models are visible. However, group too many too far apart, and a single outlying box that might be visible from where you're currently at will cause all the rest of the boxes that are hidden to be drawn anyways even though nothing is shown for the work. BSPs can be a handy tool for indoor scenes but they really begin to struggle with handling large outdoor areas. I can't remember off the top of my head what the deal was but I believe there's also some inconsistencies with lighting methods between BSP geometry and model geometry (vertex lighting vs. lightmapping and dynamic lighting). Something to keep in mind and look deeper into. If you build your models properly snapped to a grid following UDK's units, you will be able to snap them together in the UDK editor with ease. As long as you have your models flush with each other and prevent gaps between meshes your models will prevent anything behind them from drawing (as long as [i]all[/i] vertices of the hidden models are not visible).