Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your help!

We need 7 developers from Canada and 18 more from Australia to help us complete a research survey.

Support our site by taking a quick sponsored survey and win a chance at a $50 Amazon gift card. Click here to get started!


Member Since 27 Jun 2001
Offline Last Active Today, 02:57 PM

Posts I've Made

In Topic: entity component system object creation

Yesterday, 08:04 PM

Its also measurably prettier than JSON.


Did you make up some measurement when you made that statement?  YAML's much better than XML, but I don't know what measurement you could possibly use to judge YAML is prettier than JSON.


I'd say it's 6 one, half dozen another and up to the preferences of the user.

In Topic: entity component system object creation

Yesterday, 12:50 PM

Isn't this a one person effort? Rebuilding is fast compared to putting time into implementing a scripting system you only want to use for loading some data.

IMHO just use CSV files with column headings, exported from a spreadsheet application where you type it in. They are easy to read into your game and don't contain cruft these XML-like formats have.


I would highly recommend using json instead, as it is extremely flexible in that it can handle arrays, structs, and dictionaries and is quick and easy to use.  You'll find tons of parsers out there for it, and it's not nearly as verbose or clumsy as XML.

In Topic: HTML5 game engine for Isometric "Final Fantasy Tactics" like game

27 August 2015 - 12:06 PM

phaser.io should have many of the things you are looking for.  Take a gander if you haven't already.

In Topic: The best way to manage sprite sheet animations?

14 August 2015 - 08:44 AM

The "death" animation would then essentially play an animation which was already defined as:
         animation.startPosX = 2;
         animation.startPosY = 3;
         animation.playSpeed = 5;
         animation.replay = false;


In more conceptual terms, these values should not be defined in the source code.  You need to use external data to define your animations, something like json (which has many parsers and is easy to work with and not overly-verbose like XML).  Then, you'd define your animations like this:

{"animations":[{"name":"death", "spritesheet":"death.png", "startPosX":2, "startPosY":3, "playSpeed":5, "replay":false}, 
                       {"name":"walking", "spritesheet":"walking.png", "startPosX":1, ...} ...]

Obviously, it can be more than that, but doing it that way you don't have to re-compile every time.  Then, in your animations constructor (or Init, whatever), you can load all the animations and define them using the animation json file(s).


(Oh, I see Haegarr said this, but I wanted to give an example).


Good luck!

In Topic: Basic Programming Knowledge Need Some Advice

12 August 2015 - 07:18 AM

My other suggestions would be to keep as little clutter out of your main file as much as possible. It's perfectly ok to move your functions into a separate header file. This example I am going to show you would be something that would probably get you screamed at in the professional enviorment... but for something this small... it'd be overkill to do it the proper way.


Please PLEASE don't put code in a header file.  This defeats the whole purpose of a header file.  Header files are great for prototyping functions/classes that need to be called from other source files.  They are not a place to put code it just so you can "clean up" your main source file.


If you're concerned about cluttering up your main source file, then make multiple source files and include the function prototypes in a header file.


You even said, "This example I am going to show you would be something that would probably get you screamed at in the professional enviorment" so why would you offer this as advice to a beginner who's trying to learn the right way to do things?


And, FWIW, there's nothing wrong with prototyping a function in the same file it is defined, assuming it's only used in that file (and then, it should probably be declared static).  I'm not sure why you are so against that.