Primary tabs

Comments by User

Tuesday, March 11, 2014 - 21:00

"I hope tap enjoys it." - ryan

Don't worry.  I thought it was hilarious.  Good way to start a night of gaming. Thanks, Will. :D

Just to be clear, I want to restate that I have nothing against Haxe as a platform. I would love to use it for a professional or collaborative project sometime in the near future.  Godot game engine also looks very promising for collaborative projects, and I intend to look further into it as part of a viable game creation suite.

Tuesday, March 11, 2014 - 03:01

I agree with Bart that the jump-right-in approach is hard, but it is also very rewarding.  However, you could supplement the language and libraries I chose with slightly easier languages/libraries/IDEs, like AS3 combined with Flixel in FlashDevelop.  If you use a game engine, make sure it is open source for learning purposes.

Monday, March 10, 2014 - 19:00

I can vouch for Scirra Construct.  It is a brilliant game engine, and it's fairly cheap, too.

However, Paul Wortmann is correct.  You need to learn a programming language in order to really have the power to make whatever game you want to make.  If you want to jump right into the hard stuff and get some real programming experience, you should look at CodeBlocks and C++ and SDL2.  SDL is great as a graphics library for C++.  CodeBlocks is an excellent IDE for C++ programming.

You also may want to look into tile map editors and develop a decent workflow for making tile-based games.  I recommend Ogmo Editor for tile-based game design, because it is extremely flexible and keeps settings across your entire game project rather than per map.  I like Ogmo's ability to set prefabs for the entire project.

Whatever you choose to start with, make sure it is a platform that allows you to learn traditional programming structures and concepts.  Do not choose to start with Unity, because it does way too much for you.  You want to avoid game engines in general unless they are open source and somewhat simple.

Monday, March 10, 2014 - 18:27

I have very limited Java experience, but I would be curious about the game's workflow if you're willing to share that information.

Monday, March 10, 2014 - 18:25

@William: I think you already agree with me about NME being unintuitive.  OpenFL is not something I really delved into, but I have toyed with it a tiny bit, and it seems very similar to NME.  I will have to try making a Flixel game using OpenFL on top of Haxe and compare the experience to my older experiences with the language/platform.  However, Haxe has always been more strict than AS3, and the syntax is a little different, so porting from AS3 to Haxe takes a very long time.

I'm sorry if I seem to be insulting you at any point in this thread, but I never insult anyone intentionally.  You have intentionally called me a stupid troll.  I do not appreciate the hate and am therefore backing out of this thread permanently before things get out of hand somehow.

Sunday, March 9, 2014 - 19:07

1. I typically use a background layer for tiles which I use for the floor/ground.  Then I have a decorations layer to decorate the ground/floor with small details, like bullet holes or long grass.  Then I combine those layers in some cases (not always) to improve performance.  Basically, you use whatever you need and just try not to overdo it.  If the commissioner wants to limit the layer count, that should be made known to you before the work is done.

2. a. Semi-transparent tiles are very uncommon.  If you want to have dim versions of tiles, you typically modify them using tints or color manipulation at runtime.  It doesn't really hinder performance much.

2. b. Rotating/flipping tiles should be expected to be done by the end user or developer in most scenarios.  Some exceptions should be considered, like ground tiles for each corner and side.  The reason you pre-flip and pre-rotate these tiles is you may want to change a few pixels for some added variety and such tiles are typically already set up a certain way in tile sets.  Just use your best judgment.

Sunday, March 9, 2014 - 18:53

"HaXe also now has a port of the Love2D framework called HOVE, which looks pretty promising."

That looks very interesting.  I'll have to try that out soon. :)

Sunday, March 9, 2014 - 18:51

"Certainly Flash does not have an API, though Action Script does."
In a way, yes, AS3 is an API for Flash.  However, I doubt that's what you meant by API.

Haxe's not extremely different from AS3.  I just think AS3 is easier to work with.  AS3 is more flexible as a language.  Haxe is a broader platform with better support for desktop apps and other cool things.  On the language side, there are a few things that Haxe simply does not do that AS3 does and vise-versa.  It's really a trade-off of performance and ease-of-use and portability.  Neither is better than the other in every way.

Sunday, March 9, 2014 - 15:49

"The Flash API is available in Haxe through OpenFL, right?"
That is an odd question to me, because Flash doesn't have an API.  OpenFL is a recent development that I have not investigated thoroughly, but I used its predecessor, NME, a lot, and while it was very good at emulating the Flash standard libraries, it did not change how the Haxe language works.  It also required a lot of tinkering to get it to compile with FlashDevelop, something I never had to do with Adobe Air and AS3.  As far as web game development goes, it is simply easier to use AS3.

Sunday, March 9, 2014 - 05:24

I don't like Haxe as a language as much as I like AS3 as a language, but Haxe is a better platform that Air.  Air isn't even supported on Linux any more.  For web games, AS3 is probably the better choice, but Haxe is lightyears ahead of Air for desktop games and mobile apps.

Pages