Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


stormwarestudios

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

#5024150 Project: Alter Ego - An introduction.

Posted by stormwarestudios on 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.




#5024145 Critique my 2D assets

Posted by stormwarestudios on 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!




#4927568 Web Game Development advice

Posted by stormwarestudios on 02 April 2012 - 11:37 AM

If you're writing web-based games, here is a high-level look at what you need to know:

1) Client-Server modelling

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.

2) JavaScript

Until Google gets their development workflow for Native Client (NaCl) 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.

3) WebSockets

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 SPDY vs. S+M.

4) Server-Side (Scripting) Language

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.

5) Database and SQL

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 RDBMS, and provides "object-like" functionality for manipulating table data.

For TGE's workflow and build environment, I use pure (i.e. library-less and toolkit-less) JavaScript (canvas, audio, video, client websocket, workers), Chrome Developer Tools (JavaScript debugging), SuperWebSocket (server websocket), MonoDevelop (C# on Mono IDE with debugger), ODX.NET ORM layer, MySQL and Workbench.

Of course, there are other configurations which can be used, it really depends on how painless you want your development to be. Remember, the tools you employ must work for you, and not you for them.


#4927557 How to read PNG images without a library?

Posted by stormwarestudios on 02 April 2012 - 11:14 AM

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.


#4924719 How do I get that first project off the ground?

Posted by stormwarestudios on 23 March 2012 - 12:33 PM

Programming is simple enough or at least there are plenty of resources available on here and other places to get you started there. The bigger problem in my mind is "How do I actually get a project started?". Let's just assume I have all the relevant coding background* and I am ready to hit my first game. I still have hundreds of questions on how to actually get started.

1) The ever present "What do I actually want to code" question.
A) It has to be simple enough to get something fun to play with in a month or two being a first project to keep the motivation going for the
next one.
B) It has to be somewhat entertaining or you don't get any sense of accomplishment.
C) You generally only have a couple of friends working on the project so your design somehow has to make up for the lacking skill sets.
D) If it turns out well it should be a good transition into project 2.

2) How to choose a framework.
A) It has to be useful in your game making future.
B) It needs to be relatively easy to work in or you will lose motivation to continue.

3) How do you control feature bloat.
A) You have to figure out which features you want that are in conflict with the requirements of 1.
B) You have to keep bugs to a minimum due to the low number of developers.

For those of you with successful projects how did you answer these questions?

I am beginning to see why there are so many game engines projects out there


You need to be able to manage the project. Developing a game is not about writing code, it is about managing a project from end-to-end and meeting your users' desires and needs (that is, to be entertained).

Answers to 1 and 3 are simple enough: learn Scrum, and apply it to the Agile development methodology. I leave this as an exercise for the reader to learn more. ;) Learn and use the appropriate tools to manage your project.

Answer 2 is also simple enough; choose tools that let you get stuff done. You need a "studio"-esque IDE to manage large numbers of source files and library dependencies. You need a debugger. You need a source revision control repository. But most importantly, you need to learn how to use all these tools effectively.

Doing anything less is setting yourself up for failure.


#4918082 Python or C#?

Posted by stormwarestudios on 29 February 2012 - 10:55 PM

Your development language of choice demands more criteria than just the language itself. You need to look at:
- Development IDE.
- Debuggers.
- Community support.
- Availability of complimentary libraries.

Do some research, and your answer becomes simple.


#4916290 GUI within a DirectX program

Posted by stormwarestudios on 24 February 2012 - 12:55 PM

Consider rolling your own, too...

Part 1
Part 2
Part 3
Part 4

I've referred to these in the past when coding GUIs in C++/OpenGL and JavaScript/HTML5 canvas, so they can really be applied to any technology platform.


#4905783 Beginner question for (maybe) Isometric games

Posted by stormwarestudios on 24 January 2012 - 08:16 AM

If you're building a game for the browser, then there are two major factors you need to key in:
1) You'll have to master JavaScript
2) Putting all your logic in the front-end makes your game significantly more hackable.

There are alternatives to #1 (ActionScript being one of them; I feel this is a technology which is losing traction to HTML5 so can't recommend going this route). Google's Native Client would also be a good bet, since C code becomes reusable; this, however, is even more bleeding-edge than HTML5 game development, and its future is highly uncertain.

As for #2, the main option is to put game logic in the back-end, and link the browser game client via some means like XmlHttp requests, WebSockets, and the like.

I've gone the Canvas+WebSockets client/server route, upon which I'm basing TGE's development (link in sig). Game development in this fashion is in its infancy at best, meaning there aren't complimentary libraries (higher-level network messaging, stateful machines, sprite animation, level formats or generators, user interface widgets, and so on), but I'm slowly working on them.

Flash/AS, obviously, give you a neat little black-box SWF, user interface, and (probably) established game engines (see these 11) already, but the trade-off is (what I refer to as) a dying technology (YMMV). It's really a matter of what you want to accomplish moving forward.

Drop me a line if TGE interests you.


#4901344 [Seeking input, information] Making an application that looks like BIOS

Posted by stormwarestudios on 10 January 2012 - 11:16 AM

Install Cygwin with vim/emacs for file editing, mutt for email, and give users access to a particular (perhaps mounted usb key drive) directory to muck around in.

If you're really creative/dedicated/Linux savvy, set up a Linux server, and have users ssh into it in order to access said subsystem.

Your end product already exists across numerous venues; find the most ideal solution (Linux wins, hands down), utilize it, and your LARP group wins.


PARTNERS