Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 Dec 2006
Offline Last Active Nov 25 2013 10:41 AM

Posts I've Made

In Topic: Project: Alter Ego - An introduction.

21 January 2013 - 08:39 PM

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.

In Topic: Critique my 2D assets

21 January 2013 - 08:24 PM

You lack a forge (firepit + bellows) for your smithy. The oven IMO wouldn't cut it. happy.png


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!

In Topic: What a server should look like

16 January 2013 - 10:12 PM

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. smile.png


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.

In Topic: On a scale from 1 to 10 how bad of an idea would it be to use a JSON like for...

16 January 2013 - 09:23 PM

1: If it's truly turn based, this should be completely fine, and will make life a lot easier I'd say. I've even considering using compressed json strings for packets on real time games just because JSON rocks.


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.

In Topic: Character Creation

13 January 2013 - 07:09 PM

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.