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

DoniRamirezSoto

Members
  • Content count

    12
  • Joined

  • Last visited

Community Reputation

383 Neutral

About DoniRamirezSoto

  • Rank
    Member
  1. Good article Macoy, I only think it might be wisely to put your prototype in a separate source repository. This will allow you to be more adventures with developing a prototype. Different branches might be used to focus on separate parts of you prototype. Also being able to revert back all your changes might be needed when you are not satisfied. Besides the normal benefits such as a pc/laptop crash.
  2. I would say that your question is to generic and by-far not relevant for you at this point in time.   If you are still learning c I would not go out and start thinking about things that might happen somewhere far out in the future.  Sure it is always good to think a couple steps ahead, but this is more like a few journeys that you still have ahead of you before even start thinking about things like this.   It is simple fact that focus will bring you far more result when undertaking something as learning how to develop games. Best what you could do if you are willing to think so far ahead is to make sure you at least have the necessary skills set. That will give you some insight about the basic ins en outs of the process involved that you are trying to collaborate on. Without that any project is doomed to fail even before it starts.    IMO this question is wasted of time for you and for people on this form trying help you out. Any answer that you will get will probably raise more questions and than answers. The missing of a foundation makes it even harder to understand what every body in this thread is talking about. The best advice I could give to you is stick with what you are trying to learn, keep thinking few steps ahead but not years unless your skills and experience allow you to. Make a few games on your own before even start thinking to work with other people. There are not many teams that are willing to take on apprentices as they make chance of actually finishing a product very small.   Armed with the knowledge of the basic principles that are involved in making games and one or more skills that could be valuable to actually work with a team on a collaborative game project you would be able to ask much better question. You might be even able to answer this question for your self for the largest part.  
  3. Why won't you do a search online there are tons of game projects that have there source code publicly available.
  4. [quote name='rip-off' timestamp='1349952903' post='4989052'] Your performance point of view is more or less irrelevant here - performance will be dominated by the I/O performed in this function. [/quote] I was merely explaining as why I choose to do it this way and of course in a small program you probably won't have to think about such things. [quote name='rip-off' timestamp='1349952903' post='4989052'] Lines of code does not equate to elegance, of course. That said, I think that by removing an extra comparison alvaro's code is simpler to understand. An alternative that I think would be simpler in your code is to restructure the final condition like so: if(repeat > 1) { flip_coin(repeat - 1); } Avoiding the complex mutation expression in the condition makes the code much simpler, IMO. [/quote] I agree with you on that it would have been better to write it out like this, but on recalling the function i still have to disagree. In this example there is little cost of recalling the function, but just out of habit not having to call a function that could be costly I would prefer to not call a function if not needed.
  5. [quote name='alvaro' timestamp='1349947795' post='4989033'] This version is slightly more elegant: [code]import java.util.Random; public class flip { static Random random_generator; static void flip_coin(int repeat) { if ( repeat > 0) { double random_number = random_generator.nextDouble(); System.out.println(random_number); if (random_number < 0.5) System.out.println("head"); else System.out.println("tail"); flip_coin(repeat-1); // <-- This is the only change } } public static void main (String[] args) { random_generator = new Random(); flip_coin(10); } }[/code] [/quote] From a performance point of view a function call is more expensive than a comprising. This piece of code will cause every run to have an additional function call to flip_coin with no result. As why there is a guard condition on top this is only because if you would be silly enough to provide any value less than 1 it would just skip the function. Less LOC's (Lines Of Code) doesn't mean it is more elegant just remember that.
  6. Another solution might be using a recursive solution. [source lang="java"]import java.util.Random; public class flip { static Random random_generator; static void flip_coin(int repeat) { if ( repeat > 0) { double random_number = random_generator.nextDouble(); System.out.println(random_number); if (random_number < 0.5) System.out.println("head"); else System.out.println("tail"); if(--repeat > 0) flip_coin(repeat); } } public static void main (String[] args) { random_generator = new Random(); flip_coin(10); } }[/source]
  7. [quote name='zqf' timestamp='1349905105' post='4988874'] Thanks for your replies. I'm mainly just paranoid about getting into bad habits [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] [/quote] Don't be afraid for that, most programmers still have habits on which could be improved on. I takes years to perfect your art [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]. Until then it might be a better idea to be productive than over think everything you doing. By programming allot you will get a better picture about what type of relationships can be made between classes. Everybody here might talk big about programming theorem but i bet you that we all still drop the ball every once in a while (that includes me). [quote name='SIC Games' timestamp='1349929258' post='4988952'] If the variable are consantly changing then don't use getters and setters. In fact, the editor I am making uses less getters and setters that previous draft versions. But what is a setter and a getter - ask yourself? A setter is just a function that sets a variable. So, if you think of a player's position and some way you want to retrieve the player's position then you can have a set up like this: [/quote] You might consider reading the hole thread before posting a reply ;)
  8. [quote name='Telastyn' timestamp='1349890357' post='4988781'] IMO, an actor should not reference objects at a higher level than itself, including the world. [/quote] I fully agree with you on this but still I would see this a design decision. [quote name='Telastyn' timestamp='1349885837' post='4988763'] [quote name='zqf' timestamp='1349878892' post='4988728'] When an actor moves it needs to find the actors and tiles nearby to collide with (stored in a World object say). [/quote] That's why actors don't move themselves. Something moves them (and can then know enough to handle collision between actors). Unfortunately, much of OOP turns out to be a bad idea. Not [b]everything [/b]is an object. Objects shouldn't necessarily contain [i]all[/i] of their state and behavior. These are traditional concepts that are unfortunately still taught heavily at universities. The focus should be on the [url="http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)"]SOLID[/url] principles. These are more general principles that are great for OO as well as other paradigms. They've evolved over years of use (and academic study in some cases). Hope they help. [/quote] Yet again I agree with this too but this pore guy just got flooded with advanced practices. I tried to keep the answer with in context of his question ;)
  9. Most IDE's now days have good syntax highlighting. Also it is hard to say what u mean by "best". Do you mean allot of colors or most pretty color scheme which is configurable with most IDE's as well. If you where looking for a list of cross platform IDE's a search true this forum would have given all your answers.
  10. First I will answer your question. No you don't need to write setters and setter for every field in your class. Only if think you are going to use them or have the need for them to be public. Making such decision is all up to you and is called software design. Use your logic to layout the classes in such way that they will work together but also will not cause problems behavior wise when you are able to modify properties publicly. As for getters and setters them self. I have feel obligated to say they are not so great as every body might think. Actually they are even evil. First of all for the fact that most people never put anything in a getter setter block besideds passing true a value which is actually just mindless typing working which doesn't make sense at all. Secondly for the fact that getters and setters are no more than syntax sugar in the end it is a function that return a fields value and set a value using function. With that said it more logical to make a function/method that has a better description about what the operation is going to preform on a class. Compare the following example [source lang="java"] spaceship = new SpaceShip(imgSpaceShip, posx, posy); if( spaceship.x < screen.width) spaceship.x += speed; if( spaceship.Y < screen.width) spaceship.y += speed; [/source] to.. [source lang="java"] spaceship = new SpaceShip(imgSpaceShip,posx,posy,speed); spaceship.move(screen); [/source] This is a small part pseudo code that reflects real good what I mean that using getters and setters does not promote better software design. It is not even considered OOP. I used to be a big fan off getters and setters until I starting using more languages that had no syntax sugar for getters and setters. At first it hated it then i found out that I wrote better OOP and made less mistakes due better open close principle and that methods attached to classes where better descriptions on them self. If you would still feel the need for model / object to have mainly public properties you might think of using a struct. Therefor I have to disagree with people in this thread whom claim that structs and classes are the same this is simple not true.
  11. I've taken a look at your code and seems that it needs bit reorganizing. Games have a main loop that consist of few functions like input (could be user or/and network), logic, and draw.Each of them should handle specifically what it says. Meaning that in the input function you would only do things that have to do with input, logic would only handle the logic that needs to be run each frame and draw should only be drawing the game object on to your canvas. What you have done is putting the draw function of the bullet inside your (logic/input) function which not the way to go. Move the draw function of the bullet to where you draw the ship. I suppose you did this with the idea that the bullet would only be displayed when you would press a key. My advice to you is try to improve your OO by moving the ship and the bullet to a separate class file and like SimonForsman said don't use static you have noneed for this at this point.
  12. Like Mikea15 says a comment is a good idea, I don't know which IDE you using but these days most have support for a todo comment. something like // TODO: Proceed with this class This would come up in your task list in your IDE. Meaning you would not have to go look for it after you been closing your files.