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


  • Content count

  • Joined

  • Last visited

Community Reputation

211 Neutral

About stormwarestudios

  • Rank

Personal Information

  1. There was a game which accomplished the combat system you're after, called Die by the Sword, which gave you fine(esque) control over your weapons, and upper/lower torso (IIRC). I'd recommend trying it out if this is the combat style you're after.   IMO the DbtS execution of combat was flaky at best.   As far as your implementation goes, have you considered perhaps applying the equivalent of "mouse gestures" (or swiping on mobiles) to achieve the same effect? It'd be a little more intuitive, at the very least.
  2. You lack a forge (firepit + bellows) for your smithy. The oven IMO wouldn't cut it.    Consider increasing the size of the building signpost icon (the Inn, for example) and exclude the text. It's hard to read, and the overall style calls for more symbolism in that regard.   The cat statue is called "maneki neko", if you want to read up on it.   I really like the style. Looking forward to playing the related game!
  3. There are no set answers to the components of your template, but I can maybe suggest ways to determine them. It's easy to answer "it depends" for each category, so I will try to offer something a little more insightful.    Type of game might have influence over the packet communication protocol you develop; if the game is realtime, your packet design might be aggressively optimized to minimize bandwidth usage. Conversely, a low-traffic game can be more loosey-goosey with packet design optimization.   Typically, clients will be requesting permission for things, whereas the server will be either responding to permission-requests, or simply updating the state of something as it sees fit. For example, a request from a player to move his avatar comes from a client; the server will respond with either (a) yes, or (b) no; in the case of (a) he will likely also update other clients with the new position of your avatar.   Required connectivity is sort of unclear. More bandwidth is better, obviously, but (briefly) your server will need to be able to sustain, at a base minimum, a per-second send-speed at a rate R dictated by the largest packet byte size S, multiplied by the largest number of hosted clients C, multiplied by a minimum operations-per-second threshold T. For example, where S=100, C=16, T=30, then R=46kB/s.   Required hardware is a mixed bag. Given the required S*C*T from above, the CPU shouldn't choke for particularly complex operations, or hang while managing something else in the OS (for example, a database, or an antivirus program). More importantly, your application should try to take advantage of hardware offerings (multiple processors, or CPU-specific features du jour) , where applicable.   Required OS is determined by what your developers are familiar with targeting, what your technology development stack is compatible with, and what you want to pay for. An environment like Cygwin provides many UNIX-like functionalities on Windows hosts, and likewise environments like WINE offer Windows-like environments on Linux. .NET development is (arguably) more accessible on a Windows host, and languages like C, C++, Java, and PHP are everywhere. Servers should strive to utilize system resources as minimally as possible, hence servers which run in a console (i.e. GUI-less, or headless) could be considered a commonplace design. And in situations where a game-server attempts to be online at all times, it might be installed as a service on the host, available upon startup in the situation where the server must be (or is) rebooted.   Required software depends on the technologies employed in your game server, but minimally you need a communications layer (HTTP, WebSockets, plain-old TCP socket server, UDP server, or something in between like ENet), a database (MySQL, MS-SQL, PostgreSQL, SQLite, Oracle, CouchDB, or a higher-level language-specific data-access library which offers something like ORM) if persistent storage is a concern, and possibly configuration file serialization library (for XML, JSON, INI, or whatever your game server uses).   I hope I've offered food for thought. Looking forward to further discussion.
  4.   Seconded. If you're writing abstractly enough, then swapping out portions of your network data-transmission module when your game reaches a point where security and/or performance are under scrutiny shouldn't be a big deal. The up-side is you've got a working game in a shorter amount of time, which lets you focus on more important things -- like finishing the game.
  5. Congratulations! You've discovered User Stories from Agile Software Development. :-)   In its very basic form, a User Story is a concise, normal-English overview of a feature you want to implement, which includes the person involved who would normally use the feature, and the outcome you expect to achieve with the feature's implementation.   The format is simple: "As a <user-type>, I want to be able to <feature>, so that I am able to <purpose>".   For example, "as a Level Designer, I want to be able to view a minimap of my surroundings, so that I am able to quickly determine the surrounding area just outside line-of-sight of my current location in the game world".   There are many methods to approaching User Story design, but a next logical step in the Agile development methodology is breaking down a User Story into individual tasks, sort of a check-list of To Do's which go toward implementing that User Story and achieving that goal. A rule of thumb for defining tasks, no task can be too small.   In the past, disorganized individuals came across the same organizational problems you've encountered, and invented an entire project management methodology to help them achieve the goal of shipping a project on-time. You'd do well to read up a little bit of what Agile really is, and how it can help you get your thoughts organized on paper.   Good luck, and happy coding!
  6. I prefer minimalistic character instantiation coupled with evolution through gameplay choices.   A: Consider a character creation system whereby the player makes cosmetic choices for his character, then enters the game. Through active game-play, the character encourages development in particular skills by their frequency of usage, frequency of success or failure, or other usage-based characteristics. The player might achieve levels of proficiency, or unlock items/perks based on skill achievement.   B: Conversely, the classic D&D-influenced system of rigidity where, because the player chose class X, he is completely unable to perform a task limited only to class Y. Furthermore, he can perform a specific set of skills, and learning new skills outside that realm are impossible (or heavily penalized).   My personal preference is A, because it lends to more incremental character development; the player is constantly seeing small gains throughout the character's life.
  7. RSS   I joined GD in 2000 under an old defunct account (it might have been called MatrixCubed?) and have seen many changes, the vast majority of them positive.   About the time the most recent changes came into play, I started taking an interest in aggregating my intake of various sites using RSS feeds.   The current offering for GD's forum posts is only a single "GD Forum RSS" URL; I'd like to see the RSS offering expanded to support individual forums.   Theme   I miss the old "classic black" GD theme. It was mentioned previously in this thread; I'd like to add my voice to that request.   Web and HTML5   With the continued expansion of web technologies, it would be nice to see separate forums which focus on web-specific technologies (Canvas, Audio, Video, WebSockets, Workers, Unity3D, NaCL, and so on). I suppose forum tags could be used to facilitate related searches, but there are many subtle differences between developing for a platform and developing for the web which I feel warrant their own space.   Note that my above request does not concern web design, but rather developing games using latest web technologies.   Thanks again for a great 2012; looking forward to 2013! :-)    
  8. Hey all,   So I've been plugging away at my project, Tempest Game Engine, and I've pieced together a tech demo. I've posted about it here (my blog is here), and a video is here.   If there's enough interest in the technologies employed to pull this off, I will write up a short technical paper.   Disclaimer: I'm not really looking for performance stats, as I have a number of performance improvements planned. I'm also certain that it mightn't work in non-(Chrome/Firefox) browsers, so don't be surprised if it doesn't, because I'm not. :-) I've tested it in Chrome and Firefox (on Windows 7 as well as Android ICS), but any curiosities which arise would certainly be appreciated.   Thanks! - Peter  
  9. While I can't assist with the lost .cs file, have you considered looking into a revision-control source repository? A little self-discipline goes a long way, and it beats the pants off standard backups.
  10. I posted a thorough response to such a question just this week; see [url="http://www.gamedev.net/topic/622793-web-game-development-advice/page__view__findpost__p__4927568"]here[/url].
  11. It sounds like you need to investigate different methods of managing game levels for your game, before you ask this question. Identify the type of game you are making. Your levels are likely tile-based, so you need to investigate tile-based level management. Start with 2D arrays, and go from there. This sort of thing shouldn't be SDK-specific, as it is more or less a building-block (no pun intended) of 2D games.
  12. [quote name='Servant of the Lord' timestamp='1333403480' post='4927655'] Neither is C#, though C# is somewhat better (Unity plugin, and I don't know what else, but it seems Microsoft designed C# for web support as well). Python I don't have a clue about, though I imagine it's in the same boat as C#. Java is much better suited for web games, at least presently. [/quote] Can you qualify this statement? Specifically, why do you feel C# is unsuitable for web-based games? Are you talking client or server? If you're talking client, then I wholeheartedly agree; Java or Flash are the ways to go. But server is a different story (as would be C++; for the most part, you require a HTTP, WebSocket, or CometD server for communications).
  13. If you're writing web-based games, here is a high-level look at what you need to know: [b]1) Client-Server modelling[/b] Browser-based games, if they are to do anything ranging from storing high scores, to permitting multiplayer and persistent state worlds, require communication between "what the player sees" (i.e. the client) and "what controls the game logic" (i.e. the server). Often the logic is stored IN the client, as is the case with many Java or Flash games, but even "storing high scores" needs to talk to a server at some point. [b]2) JavaScript[/b] Until Google gets their development workflow for [url="https://developers.google.com/native-client/"]Native Client (NaCl)[/url] worked out, JS will reign as the "king of the browser-based functionality" languages. Learn it. Inside out. Closures. JSON. RESTful interfaces. Simulating classes. All the important HTML5(-ish) tags (canvas, audio, video, websockets, workers). This will take care of the client in your "client-server" model. [b]3) WebSockets[/b] Chrome, Firefox, and Internet Explorer 10 (i.e. the browsers that matter) all support WebSockets. Why? Likely because it is going to be the Next Big Thing in browser/server communication. Understand what it is, what it offers, and why it's probably going to be adopted sooner than [url="http://dev.chromium.org/spdy/spdy-whitepaper"]SPDY[/url] vs. [url="http://tools.ietf.org/html/draft-montenegro-httpbis-speed-mobility-01"]S+M[/url]. [b]4) Server-Side (Scripting) Language[/b] Your server needs to be able to run in a persistent "loop". Many server side scripting languages are more built for "one-off" executions. This includes PHP, and I would take a closer look at Python in this light, as it might be unsuitable (or rather, there are likely more suitable languages for this purpose). Think of a script which needs to run in a "while(server.active)" state, crunching incoming connections. Better suited languages would include C#.NET (or C# on Mono, if you prefer cross platform) and Java. [b]5) Database and SQL[/b] You need to store your persistent data in some form or another. My personal preference is to use an ORM layer which abstracts away from the [url="http://en.wikipedia.org/wiki/Relational_database_management_system"]RDBMS[/url], and provides "object-like" functionality for manipulating table data. For [url="http://tge.stormwarestudios.com/"]TGE's[/url] workflow and build environment, I use pure (i.e. library-less and toolkit-less) JavaScript (canvas, audio, video, client websocket, workers), [url="http://code.google.com/chrome/devtools/docs/overview.html"]Chrome Developer Tools[/url] (JavaScript debugging), [url="http://superwebsocket.codeplex.com/"]SuperWebSocket[/url] (server websocket), [url="http://monodevelop.com/"]MonoDevelop[/url] (C# on Mono IDE with debugger), [url="http://odx.codeplex.com/"]ODX.NET[/url] ORM layer, [url="http://www.mysql.com/products/community/"]MySQL[/url] and [url="http://www.mysql.com/products/workbench/"]Workbench[/url]. Of course, there are other configurations which can be used, it really depends on how painless you want your development to be. Remember, [i]the tools you employ must work for you, and not you for them[/i].
  14. Unity

    Last time I touched Ogre (2-3 years ago) it possessed very competent terrain rendering capabilities. If anything, it's engineered quite brilliantly; I'm sure with minor investigation to see its current state, I would recommend it again.
  15. Short version: Bite the bullet, and use libraries. Long(er) version: Are you writing a game, or writing an engine? If your answer is the former, why re-create the wheel by doing what has already been done? If your answer is the latter, well... carry on.