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

WavyVirus

Members
  • Content count

    444
  • Joined

  • Last visited

Community Reputation

884 Good

About WavyVirus

  • Rank
    Member
  1. Overview Take control of a team of mercenaries, doing the dirty work of the numerous shady factions vying for control of the city. Assemble a team and build up their strength by deploying them on missions to infiltrate, steal, and eliminate their targets. Then challenge your friends in competitive team-vs-team battles, or attempt to climb the online leaderboards in ranked matches.   The game is set in a gritty, steampunk-themed city. We are aiming for a pseudo-retro art style which mixes 3D and pixel-art, and currently we are targeting the Android and PC/Mac/Linux platforms.   Battle System At the core of the game is a twist on a classic turn-based, JRPG-style battle system.   The main distinguishing feature of the system is that characters do not simply execute an attack or skill and then wait quietly until their next turn. Instead, they make their move and then choose one of several "stances" to adopt until their next turn. Stances allow characters to react to certain events, and have a significant effect on the battle in-between turns.   For example, a warrior-type character may choose to act as a bodyguard for a weaker ally, taking damage on their behalf in order to protect them. Or they could choose to put pressure on a particular enemy, making opportunistic attacks whenever the opponent attempts to move or attack.   A technomancer might choose to spend the time between turns projecting an energy field which gives a speed or strength buff to one of their allies. Or they could protect themselves by levitating into the air, putting them out of range of melee attacks.   Each character class has several different attacks/skills and stances available to them, giving each a completely different role in the battle. The numerous potential combinations of these skills and stances allows for some interesting strategies and synergies between characters.   Other Gameplay Features Surrounding the core battle system is a framework of single-player missions and competitive PvP battles.   The player will take on missions which see them entering randomly-generated maps, where they will move through room-by-room in order to reach their objectives, encountering AI opponents along the way. These missions allow them to level-up their characters and obtain new equipment. Completing missions on behalf of factions also affects their territory on the persistent world map, giving players a sense of influence over the world.   The player can then test their strength by challenging their buddies to friendly duels, or by participating in more serious ranked competition via a matchmaking/leaderboard system.   Current Status There is a working prototype of the game for Android, PC, Mac and Linux. It contains only placeholder art, but the battle system is more-or-less completely playable, including five different character classes. The basic framework of the single-player mission system and AI battles is in place, as well as competitive online PvP battles.   Collaboration Currently I am the sole programmer, and I am working with a talented composer who is already putting together some original music to fit the theme of the game. We are hoping to collaborate with one or more artists on this project. We are aiming for a pseudo-retro style, with pixel-art sprites placed in a simple 3D environment. We are also looking for somebody interested in working on sound design/effects.   This is not a paid position, but we would of course make arrangements for profit-sharing should the project be in a position to make money. We are attempting to constrain the scope of the project to allow us to release an initial version within a reasonable timeframe. If this is successful, we can consider implementing ongoing enhancements and additional content.   Anybody joining the project should be prepared to inject some of their own vision and to help to develop the style of the game. We want the visuals, audio and gameplay to support and feed off of each other to create a cohesive whole.   Please feel free to get in touch via PM if you are interested, and we can arrange to chat about the current state of the game and our thoughts about the direction in which we want to take it. I'm excited to hear from you!   Here is some sample gameplay footage. All art here is temporary/placeholder: https://www.youtube.com/watch?v=o1a1lM6DaBg
  2.   Game engines are software / tools used to create games. Basically, they provide the common features and technical foundation which most games rely on, so that you don't need to reinvent the wheel with each game. Most games need to do things like "play audio" or "load and display a 3D scene", for example, and engines provide tools to make these common tasks more straightforward.     A portal is a web site / service which has a catalogue of games which customers can purchase, download and play. It is analogous to the mobile app stores.     These are virtual-reality heasdets. Oculus and Rift are the same thing (the company is called Oculus, and the headset is the Oculus Rift).
  3.   I will just say that I have found on rare occasions completing an RPG has left me with a sense of cultural enrichment. That is to say that it has left me feeling like my mind has been expanded beyond just having consumed an escapist experience. Your millage (and everyone else's) may vary.   I think games as an art form are impossible to dismiss, especially if we consider the potential of the medium and not just what the majority of games look like today. After all, a game can literally contain a novel, an image, or a movie (so on a pedantic level has at least as much potential 'value').   Also games have the unique capacity to engage the player and their emotions by having them directly participate in what is happening, and to react to the player's choices - this has hardly been fully explored, but the potential is clearly there and some games are certainly making inroads.
  4. As others have noted, it doesn't look like there's currently any performance issue, so this should be fine.   There are several interesting techniques which involve doing a bit of extra work to organise your objects into some kind of order/structure which allows you to more efficiently perform this kind of collision query. There are lots of ways of doing this, ranging from complex structures to very simple ones (e.g. keeping a list of objects sorted by their X position and only checking the objects nearby in this list).   These techniques generally require a bit of work to maintain the structure as objects move around, and how effective they are depends on a lot of factors (like how many objects there are, how much they move, how clustered together they are, how many queries you will perform each frame etc). These factors may even make a particular technique slower than the basic approach in some cases. Often, a simple approach like what you have can be perfectly fine.
  5. How do you picture the game working, mechanically? You mention exploration, but I'm not sure what that means in the context of a game about phreaking. It seems like the most fundamental question to answer in a hacking game is how the act of hacking is actually represented.
  6. The idea sounds interesting. I'm a big fan of procedurally generated content, and love a good loot-heavy game (like the legendary Diablo 2). Your monster concepts are also quite promising (tank tracks notwithstanding...).   Over a hundred people looked at this and no one said anything until you did!   Your post was quite general - giving an overview of the game and asking for feedback/suggestions. People often find it easier to respond if you pose a more specific question. Is there some more narrow part of your design which could be developed? You mentioned that your combat/battle system isn't yet implemented - perhaps we could discuss your current thoughts about it in more detail?   How does the player actually interact with the combat system? Is this a real-time/action system or a turn-based/tactical system? What are the character's basic combat abilities? Can they actively evade, or is this entirely down to their speed stat? Does each weapon have a single associated attack, or are combos etc available? Blocking/parrying?
  7. I think your comments are at about the right level of detail.   I like to describe the general functionality of the method in much the same way as you have. It is important to explain the basic behavior, and also to document any expectations regarding the input which are not self-evident (i.e. things which the function signature/parameter naming does not make obvious). I will also describe what kind of output can be expected.   Usually I don't bother formally documenting each parameter and return value, although this is more due to laziness than intent.
  8.   This point seems rather shaky to me. There are some fairly significant unknowns in your estimate, such as (A) what kinds of queries are being issued and (B) how many "hits" are investigated to an extent that people would consider intrusive.   (A) is largely an unknown, and will remain so if such information grabs aren't seen by a judge and come with an attached gag order. It's not unreasonable to think that a query for attributes like "reads about computer security", "objects to US foreign policy" and "lives in area X" might be issued - how small a result set might this return? Without some kind of oversight and transparency, I think it's short-sighted to dismiss off-hand the possibility of ending up "on a list" as the result of something like this. Also, are searches really limited to likely indicators of illegal activity? What about whistleblowers, activists or members of the press?   (B) is also rather fuzzy given the information we currently have. We don't really know how this data is used. Perhaps a summary of everybody's pornographic preferences and searches relating to embarrassing medical conditions is attached to their file. Perhaps somebody with access to this database will seek to sell such information, or use it against somebody they dislike. For example, there have been dozens of arrests of senior police officers in the UK recently as the result of investigations into sensitive information being sold to the press/private companies (e.g. Detective Chief Inspector April Casburn of the National Terrorist Financial Investigation Unit - a senior counter-terrorism officer).   Consider that a silly tweet or Facebook post is now enough to get you shaken down for several hours by DHS.
  9. I've always been a fan of these motocross games.   Your implementation seems promising - the basic physics are solid and it runs decently.   However, there were a few issues: I found the combination of colored background hills and the track's solid black line quite confusing. The background already looks like a moto game track. This really doesn't work for me The game is a little "twitchy" - perhaps you could soften the physics somewhat? When moving at speed, I only see a very small distance in front of me - the player really needs to learn the tracks as they have no chance of reacting in time - perhaps the camera settings could be tweaked (e.g. to align the bike towards the left of the screen when moving quickly)
  10.   I tried converting a pygame project with py2exe, but without any luck. I didn't spend a great deal of time attempting to get it to work as I was just interested in trying the software out - it may well be possible with some tinkering.
  11. The server has a model of the game world - all player and monster positions, items on the ground, obstacles etc. The server usually doesn't need to load or draw graphics. Each player also has a model of the game world, although perhaps only of the area surrounding the player. Player machines send the server information about the actions each player is taking. The server sends each player information about any nearby enemies, dropped items etc.
  12. I think that's correct belfegor.
  13. It's hard to say. You'll probably learn more quickly about the low-level graphics, physics etc by jumping straight into these systems. But it's quite possible that you would learn more about what a good engine should actually *look like* (in terms of how it is structured and used for creating specific games) by working on a couple of games first.
  14. I think AntP is suggesting that the tile's position on the game board is part of the model, but the sliding/dropping animation might just be considered part of the graphical representation of the underlying game state - a transitioning animation between two game states. A different view could be plugged in which doesn't animate tiles at all. Consider chess: the game state can be captured simply by piece positions on the board, and a "move" event only needs to include the moving piece and the position it is moving to. There is some merit to having this abstract representation of the game's state unpolluted by any other information.   One solution is to make the tile's intermediate (sliding/dropping) position part of the model, as haegarr suggests. You might consider the fact that this makes the model less abstract/"pure" a disadvantage. However, I do believe that this is closer to the traditional MVC pattern. If you choose this approach, I suppose you might store only a "game board position" for each tile in the model, converting these to actual screen/world positions in the view (allowing changing tile size/spacing etc without modifying the model).   Another solution is to provide a mechanism for the view to signal that it is "busy" performing some animation in reaction to an event / change in game state. The model can then be informed of this, and wait for the view to finish before advancing the game. I have implemented something like this before, and it seems to work quite well in turn-based games (which might include your game if gameplay is effectively frozen as tiles are cascading).  The disadvantage here is that there is now an "impure" connection between your model and view...
  15. Creating an engine can certainly be educational. But I think that an engine created before you have experience in creating games, and before you have been exposed to existing engines, will largely be a throwaway exercise. It is unlikely that the engine you end up with will be designed in such a way that it is actually convenient to use for creating games.   I took a similar approach, creating an "engine" before I had completed a game of significant scope (although I had created a few simple games before this). I did learn a lot, but the engine was not actually particularly useful in its own right. I no longer use any of the engine code.