ZOMGBananas's Forum Posts

  • 14 posts

  • Hey all, been quite a long time since the last time I was here. Just getting back into the frame of mind to want to work on games again, and it's great to see just how far along Construct has come since my last visit. Anyway...

    I popped in because I was just watching a video on YouTube, "You Can Make Video Games" (

    Subscribe to Construct videos now

    ) which is a talk which was held as part of AmeCon 2010 in the UK. The talk itself is fairly insightful, but at around the 18:50 mark while he's talking about game creation tools, Construct pops up (as the second of his chosen three).

    Thought it was awesome to see that Construct is getting out there and is becoming known by more and more people.

  • Wow, been a long while since I was last here, caught up with study and other assorted thing, and certainly a surprise to see this little tid-bit floating about. Glad it's still of help to people.

  • Thanks Sagal, and MisfitBYTE, I'm glad it was helpful.

    The best thing is that reading and writing values to a .ini can be a really powerful thing, and opens a massive world up to you. I only touched on the most basic of uses. If you go for a look back over the Uploads forum, you should be able to find quite a few other examples using an .ini file, like making a level editor, saving status, and many more.

  • I had a bit of a look around, and I couldn't find any topics specifically refering to .ini files and how they are structured and used. So, I figured I'd post up a little about what I've learned after tearing apart other peoples .caps. It's nothing spectacular, as I'm still learning a majority of stuff as well.

    The first thing to know is how an .ini file is structured. They have 3 seperate parts; the group, the item, and the value.

    An example of how an .ini file might look:

    [Names]Name1=Fred
Name2=Bob
Name3=Jack
Name4=Tom
[/code:2grvp9ic]

In that example, [Names] is the group; Name1, Name2, Name3 and Name4 are items; and Fred, Bob, Jack and Tom are values. Inside our .ini file, we can have as many groups and items as we need.

In Construct, before we can do anything with an .ini file, we need to add in the INI object. This object doesn't need to be placed in the layout, similar to the Mouse & Keyboard object.

Then we need to tell Construct to load the file. It's simple to do.

[code:2grvp9ic]System - Start of Layout

    INI Set INI file to AppPath + "names.ini"[/code:2grvp9ic]

    Putting this as your first event will set the location of the .ini file you want to use. AppPath tells Construct that the .ini file is located in the same place as the .cap or .exe you are running. If you have your .ini file in a different location from your .cap or .exe, you need to specify its location instead of AppPath.

    When we want to get a value from out of our .ini file, we need to specify which group and which item we want to get. In this example, if we wanted to get the name Jack, we need to specify the Names group, and the Name3 item.

    Say we want to display the name Jack in a text object when an event is met, like your player sprite overlaps an something else. To do this, you would do something similar to:

    Player is overlapping JackTrigger

    Text set text to INI.ItemString("Names", "Name3")[/code:2grvp9ic]

    Using an event similar to that should cause the name Jack to appear in the text object.

    To explain what the condition means; obviously we are taking the Text object, and setting the text to something. We have specified that we want to set the text to what we find in our loaded .ini file. Inside the brackets, we tell Construct exactly which part of the .ini we want to display. "Names" is the name of the group we want to look in. Telling Construct to look there will cause it to ignore any other groups in the file during this condition. Then, we tell Construct to look at the item Name3. Now that we have specified the group and the item, Construct can now take the string contained in Name3, and display it in the Text object.

    Worth noteing in relation to where we said INI.ItemString in the above event. When loading data from an .ini file, you can grab it in two different ways, with .ItemString or .ItemValue. If you are only storing text, or things you want to appear as text, then use .ItemString. However, if you are using an .ini file to load a value for something you need to use in any math, like a weapons power or a sprite location, you want to use .ItemValue. If you use ItemString when you want to load a number you want to manipulate later on, Construct will consider it as a text string, and you will be unable to use it in math operations and the like. On the other side, if you load text using .ItemValue, Construct will be unable to use it in math, and will default it to a value of 0. So, when loading data from an .ini file, make sure you use the right expression for the purpose you want to use that data for.

    This is only a simple example of the use of an .ini file. Once you begin to explore and understand how to manipulate them, their uses increase dramatically. You can use an .ini file to store locations of sprites placed in a level editor for saving, or read them for loading them, or for various attributes for items in your RPG. A small RPG item list might look like this:

    [Item1]Name=Bronze Sword
Power=20
Weight=5
Cost=100
Description=A simple, uninteresting sword cast from bronze

[Item2]
Name=Holy Sword
Power=200
Weight=30
Cost=10000
Description=A sword of holy vengeance, once held by an angel[/code:2grvp9ic]

To make use of that data when loading, you would specify which one of the items you want to use (if you wanted to use the Holy Sword, you would specify Item2 as the group), and then you can load the data from the items Name, Power, Weight, Cost and Description. Use .ItemString for Name and Description (because the data inside is text, and we will only really use that data in a text object), and .ItemValue for Power, Weight and Cost (because we want the data to remain as values, so we can use them later in equations to determine how much damage the sword does, how much it costs to buy one, and so forth). How you would use that data is up to you to work out though, I'm only showing you how to get those values out of a .ini file.

I'm including a sample .cap so you can see the use of a .ini file in action. Again it's nothing special, but if you don't know how to use a .ini file, this should hopefully give you a rough idea of the things that you can do. Feel free to open up the .ini file to see how I've structured it. I've also commented the .cap, and I hope it's simple enough to understand my rambling in there.

[b]Note[/b]: When extracting the .rar, keep the .cap and the .ini in the same folder as each other, otherwise the example won't work.

[b]Using the .cap[/b]: The .cap produces 100 stars on the screen, and gives them all a name (set in two private variables). The names are randomly pulled from the .ini file. When you hover over one of the stars, the text object at the bottom of the screen will display the name of the star.

[b]Construct Version[/b]: The example was made in the latest (0.99.42) version of Construct, so will not open in earlier versions, so you may need to update to be able to use it.

I hope my little explanation of using an .ini file and the .cap I've provided were easy enough to follow, and help some people out. Feel free to use the .cap in any way you wish; mess around with it, adapt it for your own projects, whatever you like.

[url=https://files.getdropbox.com/u/1414019/starmap.rar]https://files.getdropbox.com/u/1414019/starmap.rar[/url]

  • Wow, that's amazing! I love it!

  • Minor, I like that art style you've got going on there.

    Keep it up man, would love to see a playable version once you're at that stage.

  • Didn't run too badly on my laptop here, only a little bit of jerkiness when the layout moves, that's about it.

    Lappy specs -

    Intel Core Duo T5550 (1.83ghz)

    2 GB DDR2 RAM

    nVidia 8600M GS (256mb)

    Windows Vista

  • Being someone who knows pretty much nothing about making games myself, I find my motivation comes from thinking of the kinds of things I want to have in a game, and then just jumping into Construct and having a think and trying out things until I can get my idea to work.

    That's the best thing I've discovered about Construct so far - it allows you to get right in without any real knowledge at all, and in a short time you're able to produce something. Nothing motivates more than the satisfaction of finally doing something or being given something. That's why games like World of Warcraft are so addicting - you're constantly rewarded and made to feel good every step you take in the game.

    If you're on a similar level as I am, pick something you want to implement and work it out - you'd be surprised how easy and satisfying that can be.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Hey guys, I didn't even realise that I completely skipped over the introductions thread before I'd made my first posts here. So;

    Howdy all. My name is Dylan, I"m currently 25, and it seems I'm yet another aussie Construct user (I've noticed there are quite a few of us about here), and glad to be here.

    I can't remember with 100% surety exactly where I first discovered Construct, but I do believe it was over on the TIGSource forums. Programming and the like is far from my strong spot, and I spent quite a lot of time over on those forums checking out all the different programs people were using to create games, and checking them all out to see if I could get my head around them. Construct happened to pop up in a thread, and I checked it out, and I was able to come out with something, compared to my usual "bah I can't work this out bugger it!" routine.

    I say, you guys have certainly found the right formula for making Construct a strong games creation tool; it's simple enough to just dive straight in, and you are rewarded for your effort very quickly.

    I've lurked on the forums for a while now, and have only recently signed myself up, and am glad I have. I've already learned so much from the many tutorials and examples scattered throughout these forums, and I hope one day someone can come across my works and learn from me.

    Can't really think of anything else, so I'll leave it at that.

  • Haha, I love it. I'm sure there are some awesome gameplay ideas that could come from this one.

  • I never thought of setting the fade time using TimeDelta, but now it's been mentioned, I see its importance.

    So is there any particular reason why using the Fade Behaviour itself didn't seem to be working how you'd imagine it should, or was I just missing something really obvious in my early morning daze?

  • Yeah, seems bizzare anyway. Possible bug maybe, or just a quirky behaviour?

    Anyway, thank you for that, and now I can get myself off to bed now that my mind won't be puzzling over that any more. >_<

  • That's not quite what I want to do there. I can already make the text appear and disappear with a "text>make visible/invisible" event, but what I'm trying to get happening is the fade Behaviour to work when the player isn't overlapping the "S" box, rather than it happening the moment the player overlaps the "S" and presses "x". I mostly want the fade so the rest of the game looks consistant. If what I'm hoping to do can't be done, I guess I'll just have to settle with the visible/invisible events.

    EDIT: Apologies, newt, that does do what I'm wanting it to.

    Is there no way to do it using the Fade Behaviour though? Not that this solution is bad or anything. I'm just very confused as to why the Fade Behavious isn't working how it seems it should (to me, at least). It's practically doing the same thing as the method you posted me there.

    Thank you very much for that.

  • Hey guys - hate having my first post on a forum being one asking for help, but I've been butting my head against a wall for hours trying to work out why something isn't working.

    What I am attempting to do is have text appear when the player is overlapping with an object and they press the "x" button. The text is supposed to stay there, and once the player no longer overlaps the object, the text should fade out. This action should be repeatable each time the player overlaps the object (ie they leave that area and come back and press "x" again, it should re-appear, and then fade when they no longer overlap).

    Anyway, I can manage to make the text remain when "x" is pressed and they overlap the object, and then using "text>make invisible" I can turn it off when they no longer overlap. But when I change to "text>fade:start", the text immediatley begins fading when "x" is pressed and the player still overlaps the object.

    I'll post my current .cap and hopefully someone can figure out what's going on. The most frustrating thing is that I managed to make the fade work properly with an image in another place, yet it doesn't work this time.

    Oh, to those looking, the "S" box is the item to overlap and press "X" to see the text. Text3 is the text object related to it which I cannot get to fade when not overlapping. "Shift" is the jump button as well.

    Here is the .cap: http://willhostforfood.com/?Action=down ... leid=71924

    The version of Construct I'm using is one of the 0.98.x versions, by the way, but the same thing happens in 0.99.3.

    Thank you all.

  • 14 posts