deadeye's Forum Posts

  • It's nice that you've created a community for Construct, but please be mindful of where you post your topics. This thread doesn't belong in Help/Tech.

    Moving to OT.

  • The Construct Help/Tech Support forum is for Help and/or Tech-nical Support with Construct.

    Moving topic to Tools/Resources.

  • The link: http://www.zbrushcentral.com/showthread.php?t=090617

    What the...? DrPetter works for Pixologic now? Did he sell Sculptris to them or give it to them in exchange for a job?

    This is weird and I am confuse

  • Yes, and there have been a couple of threads about it already . Here's a link, check it out bro!

  • I woke up in the middle of the night last night in a cold sweat, realizing that I'd gotten it backwards. I was worried that at the very least I'd confused you, and at most you'd post back saying "uh that don't work!" Either way I knew the cold hand of fate would lead me once again to this thread, and with a foreboding sense of dread I settled back into uneasy dreams.

    Um... anyway. Using a loop you can disable all of the numbered groups, like so:

    +Always
    ->Set global('groupNum') to whatever group you need
    ->Set global('loopNum') to 1

+For 1 to 9
    ->System: Disable group "Group"&global('loopNum')
    ->Add 1 to global('loopNum')

+Always
    ->System: Enable group "Group"&global('groupNum')
[/code:3p0nqpo0]

The loop cycles through all the groups and shuts them down one at a time, then the following event activates the one group you need.  And instead of a loopNum variable you might be able to use the loopIndex expression, but I don't recall off the top of my head if that works with For loops.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The price of admission is lower than going the Apple route. I mean, to be certain, getting your game on the iphone is going to cost you a lot more than the $99 Creators club fee from MS, and if you wind up needing some Apple hardware, then you're really in for it.

    I will concede that the total cost to publish on the iPhone is much larger than on the 360. There are pros and cons to all of these options. I still think that when everything is tallied up, the cost to benefit ratio for the iPhone shows a higher potential for profitability. And if I'm being perfectly honest, I don't really have any data to support that theory, it's just a gut feeling.

    At any rate, as far as smart-phones go, Android would probably be a better choice, seeing as how you don't need any special hardware except the phone itself. And there's a need for good games on the Android right now, but I guess that doesn't really matter because by the time C2 comes out it'll have plenty. Still, people will want their fart-noise apps and Bejeweled clones!

    > Likewise with the PS3... there is no XNA or XBLIG equivalent.

    >

    There's this thing called PS3 Minis, but I have no idea what the hell is that. Maybe someone can shed light on that?

    I'd like to hear more about this as well.

    Ooohh.... just had an idea for a game! A BEJEWELED CLONE THAT MAKES FART NOISES WHEN YOU CLEAR GEMS! I'm so copyrighting this.

  • Nice. The way the ship angles towards where it's moving slightly is very slick, and surprisingly simple.

  • You can use an expression in the name field for your disable group action. Say you name your groups Group1, Group2, Group3, etc. You pick the number by whatever means and store it in a variable. Then you can do ->System: Disable group "Group"&global('variableName')

  • You can put them all under one master group and just disable that one.

  • Ray:

    As far as Mac/Linux prevalence goes, sure I guess I'll concede on that point. Though if there were a Linux port you'd be about five inches away from an Android port as well, so two birds down with one stone there. And I'd wager that the percentage of Mac and Linux users in the indie community is much higher than average, again judging from aforementioned Windows-only complaints.

    At any rate, OS support would still be more inclusive imo because as I said before, everyone has a computer, with one OS or another. Not everyone has an iPhone or console.

    >

    > I really don't think that's true. If you have a source on this I'd be happy to get schooled though . And anyway, as time goes on smart phones will become even more prevalent, and console owners still won't be able to carry their consoles around and play them.

    >

    You're far more likely to walk into a home and find a Wii, 360, PS3 or PS2 (PS2 especially) before you find an Android or an Iphone, and even if you did find one of the phones it's highly unlikely that person is using it as their primary gaming device which makes sense since gaming consoles and PC's are still the best option for serious gaming. There is a reason why single console games still sell in the millions of copies and phone games generally don't do anything close to that number even while being priced as low as 50x less than the average console game.

    Sure, you can walk into just about any home in the country and find one of any number of different consoles. Maybe even two. Rarely will you find all three current-gen consoles, though.

    Anyway, let's leave Wii out, since you can't make and sell a game without a publisher, or at least a license and a dev kit, all of which are well out of reach for most indies. And PS2 may still be quite popular, but... well, you can't sell games on there either so it's a rather moot point. Likewise with the PS3... there is no XNA or XBLIG equivalent. You need to get a license and devkit in order to develop there as well. At least, as far as I know. I don't know much about the PS3, but I couldn't find anything out there like that. Sooo... that leaves the 360.

    And yes, if you total up all the Wiis, PS2s and 3s, and 360s in American households, the number probably outshines the number of smart phones out there. But we're not totaling up all those consoles because the only viable dev platform for indies out of the lot is the 360, you can sure as hell bet that game sales on the iPhone are a hell of a lot more common than game sales on XBLIG.

    And the point is rather moot but I was under the impression that there are 3rd party programs like Torque and such that can publish on XBLIG too...?

    Also I don't mean to be rude but being able to publish to Zune and Windows Phone is... well, it's kind of like saying you can publish your game on a unicorn's butt because really who the hell owns a Zune or a Windows phone? So in that regard "Being able to make games for 4 platforms" is really just two platforms, and since Windows is one of those platforms in Construct already then that leaves 360 as your second and I've already put too fine a point on why I don't think that's really a priority.

  • There are pros and cons to both clicking and typing. As you mentioned, sharing bits of code would be much easier with a typing style of interface. And for people who type fast, yes it would be a lot faster.

    But... with a typing interface you would be required to learn syntax, and as Ash mentioned typos would be a problem. With the current clicking system, you don't need to learn coding syntax at all... everything that Construct can do is plainly shown in a list that you select from. It's much more noob friendly. You don't need to memorize commands or structure. You don't need to wonder if such-and-such function is available or not, because they're all right there in plain sight.

    And while it may be possible to create a hybrid system that parses what you type into normal events, that's kind of a tall order to lay on the devs, especially this late in the game .

    Anyway, if you're more comfortable typing and you don't mind learning programming syntax, then I might suggest using a program that has an actual coding environment, like XNA or Flash or something. After all, Construct is supposed to be for people who want to make games without coding. That's the whole purpose behind it .

    At any rate, I'd suggest keeping at it for now. The clicking might seem cumbersome at first, but once you become more familiar with where to find things in the list it'll get a lot faster. I promise

  • > I suppose there could also be a "During Message" condition that would activate every tick that animation frame is showing too.

    >

    This is what I was trying to say

    Fire an event = send a message. The event is On Message

    Ah, okay

    Only one event is needed, which fires as long as the frame is on (so that would be "During Message"). Why? because the event system already has "Once while true". ^^

    Good point, using Trigger Once in conjunction would suffice.

    Anyway, I was thinking about this whole messaging system a bit more... it seems to me that ALL game objects could benefit from it. In addition to the On Message condition for every game object, you could have a Send Message action. That way you could set up some very complex interactions between game objects very easily, and it would have the added benefit of making encapsulation* much easier. The fact that you could broadcast messages defined in sprite frames would just be additional functionality to the basic message listening system, a perk of the sprite object if you will.

    *For those that are wondering, encapsulation (wiki link) basically means keeping your various game functions as separate and independent as possible. For instance, if you have fifty different sound effects that each need to play under certain conditions then you will be setting up a whole lot of +On collision between such and such -> Play sound, +If global(score) >= 10,000 -> Play sound, etc. conditions. This means your sound engine is dependent on knowing what the other objects in your game are doing. The thing is, XAudio2 doesn't actually ever need to know why it's doing anything. All it needs to know is when to play a sound, period. If you have a bunch of sound events that are all dependent on knowing what other objects are doing, like things colliding, player input, etc. then when you make changes to your collision or input events you could end up breaking your sound events and you've just doubled your workload because you have to fix those too. But if you have all of your sound events run off of message conditions alone, then you don't have to touch them when you're working on the collision stuff in another event sheet. By limiting the information that XAudio is dependent upon to work you've effectively created a stable, autonomous entity that can easily roll with any changes you make to the rest of your game. Additionally, good encapsulation practices can help immensely with debugging your game, since your events are streamlined and easy to read.

    But anyway, yeah... I suppose I should bring this idea up elsewhere because now it's getting off topic

  • Progress Report:

    What progress?!?

    Before I left there was some kind of platform bug or something that was holding up production of these tutorials. But I've been gone so long that I don't even know if the issue was addressed, and honestly I don't even remember what it was off the top of my head*. I'm still trying to catch up with the changelogs and whatnot for the builds that have been released in my absence.

    I still have all of my files though, and as soon as I'm all caught up I'll be continuing the rest of the lessons.

    *Actually now that I think about it I believe it had something to do with the player sprite not detecting walls properly in certain situations.

  • Well, the ground tiles do have a bit of a similar style to them. But you can say that about a lot of games really.

  • > ... I would suggest something that looks almost the same but it's not: being able to fire an event, which can be used in the event sheets to do the good stuff you can doo in event sheets. This would allow complex interaction with animations right off the bat!

    >

    It seems opinions are split on the call functions feature, which I was expecting. What I mainly wanted to suggest with the call function feature was added functionality, rather than a specific set in stone feature. Figuring out what that funcitonality would be is the point of this thread, among other things.

    I like where you're going with the function idea. I think it needs to be a little simpler though. Instead of specifically defining "play sound x" for the frame, you could do something akin to Unity's message listening type deal. In the box where you have "play sound blah blah" you could simply type in a message that will get broadcast every time the frame plays. So you could type in something (anything you want) like for instance "footstep."

    Now in the conditions for Sprite, there could be an "On Message" trigger. Now you can craft an event that says +On Message 'footstep' -> XAudio2 play 'step.wav'. The On Message trigger could be used for all kinds of events. +On Message 'fire' -> Spawn bullet, for instance.

    Now, if you have an animation with several frames of footseps hitting the ground, you just need to copypasta your 'footstep' message into all the frames necessary. And if for some reason you need to reorder your frames later, the step sounds will still play at the proper time. Likewise, having just one action for playing the sound would make it easier to change the audio source or volume or whatever if you need to, rather than having several "On frame 3," "On frame 8," "On frame 12" events each with their own duplicate actions.

    I suppose there could also be a "During Message" condition that would activate every tick that animation frame is showing too.