stormwarestudios

Member
  • Content count

    346
  • Joined

  • Last visited

Community Reputation

211 Neutral

About stormwarestudios

  • Rank
    Member

Personal Information

  1. Project: Alter Ego - An introduction.

    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. Critique my 2D assets

    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. What a server should look like

    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. Tiles, tiles, tiles...

    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. Character Creation

    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. Tempest Game Engine, tech demo 1

    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. Interested in Beginner advice for Online Web game

    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. iOS Game Level

    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. Web Game Development advice

    [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. Web Game Development advice

    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 Current best open source 3D rendering engine?

    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. How to read PNG images without a library?

    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.