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

BrokenKingpin

Members
  • Content count

    27
  • Joined

  • Last visited

Community Reputation

236 Neutral

About BrokenKingpin

  • Rank
    Member
  1.   Have you had issues with eye stain in the past? If not, you are thinking about this shit too hard.
  2.   technically, OOP is not required for implementation of a C-E system.     That is true, but it helps.      I think the argument was more against deep inheritance trees, not OOP entirety. It is probably still a good idea to implement you C-E system with objects, but you are avoiding deep inheritance in favour of aggregation.   As other people have said, do whatever works best for your game. For me, the entity systems reduces the complexity and dependencies the entities have on each other.
  3. FredyC, maybe I am reading your post wrong, but your entities should not share the same instance of your components. If the property of component changes at run-time, it it would change for all the entities that have a reference to it, would probably would not be desired in most games.   For the example you gave where you want to change the stats of an item, that would just be changing the stat in code or config, and anyone who creates an instance of that item would have the new stat. Unless you want to change that stat at runtime, but again this would not be the way to handle that. ----   For the me the component entity model makes things easier because you have systems that manage the relationships between entities, and the world. The components themselves are just a set of properties, and all the logic an interactions are managed in the systems. When all the logic is contained in the entities themselves, then it gets tricky as they need references to the map and the rest of the world to handle all the interactions.
  4. What about Java... you can use the SWING GUI components in your UI.
  5. That does not sound like fun. The fun in programming is the problem solving, etc... not getting points for typing something properly. I must be missing something.
  6. Good article. I do find it irritating that every gamer seems to think that they can make their own game, with no programming or technical skills. At least if you have a background in programming you can prototype a game and stub in crappy art and music. Just coming with an idea for a game is useless, because everyone has those, but at least programmers can do something about it.   This seems to be one of the few industries with this type of problem. Just because I can drive a car does not mean I can just go design and create one with absolutely no training or education in those fields.
  7. Decide what project or game you want to develop, and what platforms you intend to target, and then pick the language that best suites you needs. You could go either way and will most likely be okay as both languages will get the job done. For the most part the skills you learn will be transferable... the language itself is just a tool to get the job done.
  8. I have played a few text based roguelike games in my day (nethack, etc.), and they are quite fun. I have also played a few that have some pretty cool uses of ascii graphics.   I did start to create my own roguelike with simple ascii graphics. I have to say it was nice not to have to worry about creating graphics. The idea of a text based MMO sounds pretty cool.   I would look into some of the existing roguelike games out there... you will be surprised at what you can represent with ascii graphics (different terrain, water, obsticles, enemies, etc.).
  9. If you are such a hard core developer, then do the initial programming yourself, and you only need to find some artists.   You could also work on a smaller budget title and sell that to get some recognition before spending all your money on one huge game that could end up failing. For example if you start with a 2D game you would just have to get one 2d artist, and you could do the programming.
  10. OpenGL is a perfectly good way to go, and is cross platform. A lot of game engines use OpenGL, so there is no technical limit they they could not release for Linux/Unix systems, they just don't spend the time to support the platform.   You could also use an existing cross platform game engine. To be honest, it is more about learning good game design practices than a specific API. You can always learn a new API and apply those same principals you learned.
  11. Pick a language that makes the most sense for the game you are designing and learn that. Using two languages for central components is just dumb. I can see using different language for some scripting or web based components, but otherwise it will be way easier if you both use the same language. To me it sounds like you should spend more time learning the basics of programming before working on something as complex as a game. If you really do understand the fundamentals of programming picking up Java should be fairly easy, at least for the basic stuff to get you going on your project. I would personally recommend moving to something like C# or java anyways, as they are far more popular than Blitz Plus.
  12. Either use smart pointers, or use a language like C# or Java that has built in garbage collection. Bolting a GC into C++ just seems dumb... defeats the purpose of c++.
  13. Linux users are completely willing to buy good commercial games. Take a look at the Humble Indie Bundles... Linux users consistently pay more for the bundle. The numbers are not as high as Windows, but enough to justify releasing it for the platform. And as others have said, Valve is now going to support Linux... so that is a good sign that there are Linux users willing to pay for games.
  14. Either way is fine, it just depends on how you go about the re-factoring Sometimes it is nice to create a new file so you can keep the old one open for reference. If you decide to just rewrite the file without creating a new one just make sure you have a backup (if you are using a version control system you are good to go).