faulknermano's Recent Forum Activity

  • If you're using the standard C2 pin, then the offset position is relative to their initial starting positions in the layout.

    Personally I prefer using Rex's pin behaviour: c2rexplugins.weebly.com/rex_pinoffsetxy.html

  • You can try fetching your data using the AJAX object...?

  • very nice work！very usefull work！ do you use one tilemap to make iso map ？

    In a way, yes, but no exactly.

    For each scene/room/level, I use one large 'ground' sprite (technically not a Tilemap), and one 'element' sprite.

    The 'element' sprite is composed of multiple animation named after their object name in Tiled Map Editor. So, technically, I use 2 sprite objects per each level.

  • I've just finished a prototype in C2 after almost 7 months of near non-stop work 12-16 hour days. :-)

    Here's a link to some screenshots

    https://c2isogame.wordpress.com/2018/07/11/prototyping-a-killing-house/#sights

    Last month I put up a 'sampler' video, which shows how it looks.

    https://c2isogame.wordpress.com/2018/06/24/prototype-sampler-1/

    Working on the prototype has been great fun, and I hope to start again soon on the full game.

    PS: Does the forum have instructions on how to reference attached images? Basically, are there any instructions on how to use the forum at all?

  • If you really want to scale the amount of dialogue and choices, you need a system that reads the dialogue/choices from external files and puts them in Construct in a way that's easy to reference and read (e.g. storing them in Dictionaries). Also, you need to think through how a dialogue is intialised, and how a choice leads to another dialogue. It involves some care in planning and executing, but it will serve as the framework for any kind of dialogue, and you'll be able to edit/revise your text and the flow of the dialogue more easily than if you were to do everything within events.

    (FYI, I am making an ARPG prototype -- in C2 -- that has a lot of dialogue. I've implemented my own dialogue system which is partly based on a nodal graph format. But it was originally just a specially formatted technical writer's nomenclature, and this is where I'm basing my advice.)

    I think you should think about designing a text-based writing format that makes sense to you. I'll give a simple example: 

    init_topic=intro

intro.text=You are in a hallway. Choose a door.
intro.choices=door_a,door_b
door_a.choicetext=Door A
door_b.choicetext=Door B

door_a.text=You enter a room with a lever on the floor. What do you do?
door_a.choices=lever,nothing

lever.choicetext=Triggers the lever
nothing.choicetext=Does nothing and returns

lever.text=A trapdoor opens into the ceiling and a zombie falls right in front of him.
lever.choices=fight

door_a.text=You enter a room with a lever on the floor. What do you do?
door_a.choices=lever,nothing

door_b.text=You enter an empty chamber, everything in this place is a picture on the wall.
door_b.choices=examine_picture,come_back

examine_picture.text=Nothing happens
examine_picture.choices=come_back

come_back.text=You enter a room with a lever on the floor. What do you do?
come_back.choices=door_a,door_b

    This text file can be read and then parsed into a Dictionary so that the text before the `=` is the dict key, and the string after `=` is the key value.

    E.g. 

    dialogue_dict['init_topic'] = 'intro'

    The `init_topic` shows where to begin. The system will search for the intro topic, then get the text of the topic, and the choices,. Pseudo-code: 

    topic = dialogue_dict.Get('init_topic')
topic_text = topic&'.text'
choice_key = topic&'.choices'
for(i=0;i<tokencount(choice_key,',');i++)
{
 choice_text = tokenat(choice_key, i, ',')
 DisplayThisChoice(choice_text[/ic])
}

    The basic idea here is that choices are the selectors for another topic. However, they share the same internal name, so when you choose `door_a` you're actually going to the topic `door_a`. But when you're in the `door_a` topic, the dialogue display will read from the value of `door_a.text`. For the choices being displayed, a list of keywords are given: `lever,nothing`. If you look at `lever.choicetext` it reads `Triggers the lever`. This is what is written in the choice text (not the dialogue text). And then it keeps on going as far as you're able to write it.

    Just note that the format I wrote above doesn't support multiple `choicetext` or `text` so you might have noticed that I had to repeat the `intro` text in the `come_back` and `nothing` topics. However, you can think through your own requirements and re-format it so that it suits your purpose.

  • For completeness sake :-)

    http://faulknermano.com/pub/isodist2orthodist_c2_func.png

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • However, are we gonna put the future of C3 on the decision of one man? That is not a good idea in my opinion.

    I would be more confident if the base package had more of these quality of life improvements built in, so that we had proper ongoing support from the actual developers.

    In my many years as a TD who has used (and coded) for a myriad of different post-production DCCs (e.g. AE, Maya, LW, Nuke, etc), I've arrived at the opinion that regardless of how good or bad the base product is, the 3rd-party developers have always been a cornerstone of any real-world/professional situation.

    The host app devs can't provide all the tools that their user base are using, and determining what are essential features are ultimately confusing; many are essential features, and only few are not. These features may just be small 'quality of life' features, or a 'I didn't know you could do this in this app!' kind of feature. The tools themselves are not point; it's the fact that you can't possibly expect the host app dev to come with that at the rate you're experiencing.

    But I think the expectation -- explicit and implicit -- that *some* 3rd-party devs will inevitably fall by the wayside mis-judges their contribution to the product: there is the intangible value of their responsiveness of knowing what is needed in the real-world and implementing a solution. Users often talk about 3rd-party as 'tools' or 'plugins. It's not just about the plugins but the 3rd-party devs ongoing involvement that makes a difference. You won't get that level of nitty-gritty involvement from Scirra; you can't get that from any developer. (You can, however, wait in line until the feature you're pining for happens to get added.)

    This is the reason why I saw Rex's leaving, whose reason was strictly due to the SDK, was really a pity.

    The one thing that construct has against it, that i think scirra doesn't see, and it really is it's Achilles heel, is the asset management pipeline.

    It's hard to hold one's breath on that one. After a few years in the forums, simply observing the kind of the features and improvements that have been implemented, then the C3 reveal, it's pretty clear to me that 'management' or 'pipeline' is just simply not quite the gripping concept in the Construct world as it is in other worlds. I think they'd have to bring in someone who has some serious experience in larger projects, using another app, in order to understand.

    (E.g. I wrote a Sprite Manager for C2 -- a Python app -- for personal use to deal with a massive amount of animation sprites. I figured that I couldn't wait, and that there is no guarantee that any improvements in asset management will be relevant to me.)

  • I'm thinking: what is the most optimal way to get the total length of the path?

    Well, I think the simplest way it is to add the iso-to-ortho-distance between the filtered nodes as they are being chosen. So if node # 1 is chosen, then the next node before lost-LOS is node # 5, then it's just a matter of computing the iso-ortho distance between those two nodes and accumulate the distance until the end.

    Is that what you mean?

  • I'm happy with how things have turned out, all the issues so far appear to be cosmetic which are all easily solvable. Just bear with me.

    Hi Tom, re cosmetic issues, if I could just put in a few suggestions, and perhaps someone will either agree or disagree.

    The green colour is ok for a few areas, but I think the use of that colour on the icons on left of the forum topics is probably too pure and it is a bit overwhelming to look at. They are also against the off-white background, which makes it a bit difficult to read. But more importantly, it's a bit hard on the eyes.

    The blue and red key colours (blue on the titles appended on your and forum leaders' names, and red on the font of the topic names), which are too pure/saturated (as in HSV-saturated). The red font on a green background (seen as column headers in topics view) is too 'hue-contrasted'.

    My suggestion re colour is simply to desaturate most of the hues and darken the values. Against off-white (or white) backgrounds, I'd avoid using pure or near-pure colours except for few small elements you want to emphasize. And I'd avoid putting two elements of pure colours in close proximity to each other (hue contrast).

    Also, the font kerning/spacing used in parts of the the forums as well as the blog is a bit generous and results in less-readability, especially when they're used in titles.

    Lastly, and I digress a bit, the 'NEW!' graphic in the blogs area make the page look super busy (and tbh, not as quite inviting to read as the old format which was more calm and structured). Perhaps it's not necessary to add 'NEW!' to each post? Perhaps it should be only the ones that's a few days old, or something?

    Anyway, they're just suggestions.

  • I've always had issues navigating the Debugger's list of objects because when the list gets long, it takes longer and longer to scroll through the list. Watching variables isn't always the solution because 1.) newly-created variables don't show up, and/or 2.) the reason for searching the object is to find out its count, and/or 3.) there are just too many watch variables already.

    I don't know why I didn't think of this before, but the solution is DevTools. Under the Elements tab, hit CTRL+F, and type in the object name. This searches the whole frame, though, so it's obviously helpful to name the objects in a way that is easily referenced.

  • Are you referring to the MAC address?

    There may be a way to do it from JavaScript (run-time), but I don't know how. If you're ok with a hack, perhaps you can try creating a batch file, and then put

    getmac > d:\gamedir\getmac.txt

    Use NWJs's "Run file" to run the file, and access the output. I haven't tried it, and again, super hacky. If the game is run on Mac, the command will likely be different.

  • Generally speaking, you should use instance variables if it relates particularly to the instance. In the case of `cooldown_time`, this seems best to be put in an instance variable of the player since other NPCs/enemies may have a different `cooldown_time`. Or maybe the player, in future 'levels' may improve their rate of attack separate from other entities.

faulknermano's avatar

faulknermano

Member since 26 Jul, 2014

Twitter
faulknermano has 1 followers

Trophy Case

  • 10-Year Club
  • Email Verified

Progress

11/44
How to earn trophies