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

Camilo

Members
  • Content count

    18
  • Joined

  • Last visited

Community Reputation

189 Neutral

About Camilo

  • Rank
    Member
  1.   Hey Roger, I am from Chile, too. Regarding your question, my advice for you is: Just make the game, don't worry so much about the tools. If you already know C#, that's a fine language, and for the engine, if you don't know any, just pick something: if you stick to this career path (which is rather hard in this country), you'll probably switch engines and technologies a few times, so it doesn't really matter what you start with. I'd start with Unity if your planned game is 3D or rather complex, or SFML.Net if you have something 2D and simpler in mind.
  2. I have experimented with similar design ideas before, and am currently also developing a "grand-strategy" (well, more like a real-time risk with diplomacy sorta thing) game, and my experience is: making abstract(-ish) strategy games fun, while obviously not impossible, is really hard, because you give up on all the "cheap" thrills of action and fancy graphics: you have to focus on gameplay, intellectual immersion, balance. Another thing to keep in mind, IMO, is that needless complexity is a dangerous trap: try to have every action the player does be a decision, that is, both doing and not doing some action should be related to some outcome (not necessarily linear or even deterministic, though). E.g. if the game requires you to build thing X on every colony for it to function, that's not a decision, it's only needless complexity.   On the theme of Space, while maybe slightly overdone, it does have the nice characteristic of being relatively simple to implement for one person (who, I am assuming, is a coder and designer, not a graphic artist): you can use circles or dots on a mostly black background to represent galaxies, stars, planets or whatever: Much easier than e.g. trying to make good looking terrestrial maps. It also makes it well suited for platforms with less powerful graphics (the web?).
  3. Most of you will probably know (or at least have heard) about SFML, the Simple Fast Multimedia Library. Just letting you know that the community there is holding their first 72-hour game jam, scheduled to start on August 2nd. The rules are pretty simple: Besides your game ovbiously having to use SFML or one of its multiple bindings, it's required that you post your source code, so that it serves as educational material for future generations of game coders. I think's a great opportunity to polish your game design and SFML coding skills. And --why not-- have fun, too.   Mods: this might belong into Announcements, or somewhere else enterily, but I am not sure. Please let me know and/or move it.
  4.   I wonder if there are any pseudo-random number generators that can run backwards, so you could reconstruct those pieces if the player walks back.
  5. Isometric? Almost any game engine should do the job: From as low level as OpenGL calls to as high-level as Unity, or anything in between. That's not very helpful, I know, but what I am trying to say, is, rather than the graphics style, you should consider what your target platforms are and what language you are comfortable with. Then consider cost, and license terms. E.g. if your game was open source, I'd just take one of the existing games and adapt it, while e.g. Unity costs around $1500, I think.
  6.   I second the buckyball idea. Actually, you could use triangle tiles to draw it (just squishing the tiles that make up a pentagon a tiny bit), but for game logic purposes use the center of the pentagons/hexagons as tiles. Or alternatively, if you want all your faces to be the same size and shape (but irregular triangles) draw a pentakis dodecahedron and use the vertices as game positions. Either way, each of the 32 "game tiles" still has 5 or 6 neighbors.
  7. Overall sounds like a fun game, if well designed and balanced. I'd try it. Regarding the choice of language and engine, I do agree with Skullz in that a higher level approach is usually more suited for these one-man-efforts, but also understand your desire to learn C++. One option would be to write the renderer in C++ (with the excuse that it needs the performance, although it probably won't, on today's hardware) and write the rest in a higher level language (C# ?). Maybe even add scripting language for the game logic (IronPython?). That would open the door to modding, if that interests you. As a nice side effect, it forces you to modularize your code and define clean interfaces.
  8.   I think that doesn't change anything on the behavior...     I think it does: I am treating the speed as a vector, while your "acceleration" (actually speed, I think) is a scalar.
  9.   I second this. The good thing about using a library like those mentioned is that you get a bit of both worlds: convenience of the higher level abstractions that allow you to actually *make* a game, and the understanding of what's going on behind the scenes. Plus the ability to later mix in some OpenGL for critical parts, if you happen to need it.   You'll need to learn to structure your code and organize your game, though. And that is, IMO, a far more valuable skill than knowing all the low level calls.
  10. Not sure what you mean by "2D pixelated graphics". Maybe write everything in one of those 3D engines you know an apply a pixelating shader on top of it?
  11. I would just keep one vector for the speed, then add the normalized mouse direction vector to it: Vector2f position; Vector2f speed; void Nave::update(sf::Time& delta, sf::Vector2f mousePOS) { float mouseMagnitude = sqrt(mousePOS.x * mousePOS.x + mousePOS.y * mousePOS.y) mousePOS = mousePOS / mouseMagnitude; // probably need to divide this by some constant, too. speed += mousePOS; position += speed; // * delta if this is not called at regular intervals }
  12.   As a pedagogical exercise it's an interesting question, but don't use it. If you have to ask on a forum what it does the next person that sees your code (or yourself in a few months) might not know, either. Not worth it, just to save 1 line of code.
  13. SFML has nice C# bindings. It depends on your needs, of course.
  14. This is very cool. Now if I only could get it to build... it seems to have flash dependencies, so it won't generate any other target. But I have never used haxe before, so I might be wrong.