SDK manual

For developers using the Construct 2 Javascript SDK

Post » Mon Dec 15, 2014 5:41 pm

@tet2brick

I had made TMX importer plugin before. It is a parser for tmx string (XML or JSON format).
It also provides two modes, one will create tiles automatically, including set position and set frame, and still could configure each tile under specific event; Another mode is just retrieving the data structure of these tiles in tmx string.
B
109
S
27
G
276
Posts: 4,479
Reputation: 154,418

Post » Tue Dec 16, 2014 1:33 pm

@Ashley
I was trying to do that because in the first platformer tutorial it's explained how to use sprite to make a simili tilemap. I discovered the tilemaps object yesterday.

I will do something manually, it's more simple :D

Thanks
B
4
Posts: 8
Reputation: 216

Post » Tue Dec 16, 2014 1:34 pm

@rexrainbow
Thanks! I will try that :)
B
4
Posts: 8
Reputation: 216

Post » Sun Jan 18, 2015 2:30 am

@Ashley - In the context of "plugins should be independent"... what you said makes sense to me, however I have become very tired with wiring objects together via events over and over, project after project. Since we can't package events together in a reusable way, that leaves only sdk to make behaviors do these things... How then can large scale projects reusing the same events be effectively managed? I need over 350 events simply to get my custom box2d platformer working... I have saved the basics of this to a template file, but its still a lot of tedium. I have also toyed with the idea of putting the code in the physics behavior as an enable-able constraint but that brings up many problems(I am sure you know what I mean here). The final, most sensible, thing to me would be to make a behavior that can call another behaviors functionality via actions, conditions, and expressions. Even writing an AI that then calls a behavior using another behavior attached to a specific plugin isn't a bad thing at all...

And it's not like we all are writing for the community or trying to make behaviors that work in any way. Each game is it's own thing, but I am fond of not having to do the same work again and again.
Image
B
33
S
11
G
2
Posts: 564
Reputation: 5,163

Post » Tue Jan 20, 2015 2:28 am

@ruskul
@Ashley

Agree.
"You could make this feature in event sheet" is not enough. To put all features which might come from different project (capx file) together easily with bug free and is more important for product.


Even packing events into plugins/behaviors could not solve whole problem, it only a little better solution than pure events.
A more better way is - "package events together in a reusable way" like @ruskul said.
B
109
S
27
G
276
Posts: 4,479
Reputation: 154,418

Post » Wed Jan 21, 2015 5:15 am

@rexrainbow
@ruskul

... but you can write events in a reusable way, just need to copy the objects the events operate on between files... It's really not hard if you're organized about it and will take less than a minute. Writing a behavior / plugin for every little thing is a pain in the ass if it's not necessary. The whole point of constructs event sheet is that you can use super functions that handle complex object oriented picking behavior for you quickly.
B
79
S
13
G
8
Posts: 1,976
Reputation: 9,947

Post » Wed Jan 21, 2015 5:25 am

@QuaziGNRLnose

Before coping events , every related objects including object type, families must be setup to be the same. It is not easier.
After that, the initial value of instance variable must be the same to ensure there is no bug.

I had spent more then 1 hour to copy whole project to a new one, including fix bugs caused by something missed. And it is only a small project.
I can not image that how hard to integrate normal size project for product .
B
109
S
27
G
276
Posts: 4,479
Reputation: 154,418

Previous

Return to Javascript SDK

Who is online

Users browsing this forum: No registered users and 0 guests