Arima's Forum Posts

  • Impressive stuff! Though will my 512 MB graphics card be able to play that, or am I going to have to upgrade to 1 TB? (kidding, kidding)

    Also, what's up with the .bmps? Use PNG or JPG! Those images are like 5 MB!

  • Study the work of those who have come before you, then when you're done with high school enroll in animation mentor. It's an online school not only founded by people from places like Pixar and ILM, you are directly taught by pro animators from places like Pixar, Disney, ILM, Sony image works and DreamWorks. I learned more in two weeks at animation mentor than I had learned in two years at another art college. It's cheaper than a normal art college, and better. Since its online, it doesn't matter what part of the world you're in, you can study there. They also don't mess around and make you take irrelevant courses like math or english for an animation career - it's 100% animation. I can't recommend it highly enough.

    http://www.animationmentor.com/

  • What I think is actually going on is that time delta continues while things are loading (i.e, the time delta for the first frame of a layout includes the time it takes to load the layout as well as the time it takes to execute the events and draw the screen) but the event sheet isn't running extra times. That's what happens with my game. How I solved that was in the application properties/runtime properties/advanced, set the minimum frames per second there to something like 30. That way the time delta won't keep racking up while it's loading.

    Instead of using a countdown timer based on time delta, what you should use (again, what I'm using) is a tick timer. Basically, if value is greater than zero, subtract one from that value. Every time the event sheet runs, you'll know it by watching that value.

    As for a loading screen, you can do that too. Before going to the layout that takes a long time to load, put a black sprite or box across the whole screen and your loading image somewhere as well in the previous layout. There is a trick, however; you have to display that one frame before going to the other layout (let the layout finish running its events), or it won't draw the loading graphics before going to the other layout.

  • Objects are not fully created until the end of the event sheet. You only have been the event that the object was created in to modify anything about it until the next tick.

    event one

    conditions

    • Create object sprite
    • set sprite color filter

    event two

    • set sprite angle

    In this example, the sprite would have its color filter set but its angle would not be set until the next tick.

  • What he said. Or if that's not possible, maybe simply not draw the icons and have a list of names instead? It's a very small window, that way you could fit more into it.

  • New version WHOOO

    The OBJ object crashes if you load a model with too many polygons on my machine too. Try something with less and it seems to work fine.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Don't use spritefont. It's buggy. Use one of these other examples instead:

  • Actually, if you only edit an event sheet then close construct, it does not ask if you want it to save.

  • It's a bug, use if left mouse is down + trigger once.

    Oh, and don't use the layout object if you can avoid it. It's very buggy.

  • The bugs were so numerous that it was good we were working as a class... so most bugs only had to be tracked down once.

    This is a good point. Construct has a lot of quirks/bugs that new users need to learn about before construct can be used smoothly. Perhaps someone should make a bug avoidance tutorial.

    Many features seem to have been just tossed in without much testing. Or features are half-added and half-completed. I'm well-aware that this is open source and such, but Construct is still not at the point where it is useable as anything except the roughest of game prototypes. Or as an exercise in patience and using unstable software.

    Even professional-level tools have bugs in them that need to be worked around, so at least it's a good skill to learn (not that I'm saying the developers shouldn't try to make it more stable).

    We were also unable to merge our files.

    As has been mentioned, that's an unfinished feature. Hopefully that'll be finished for 1.0.

    From comments the teachers have mentioned, open source is not terribly useful when the libraries required to compile and hence fix some of the many many bugs, are not open source.

    The developers know about that and are going to fix it for construct 2.

    It might be an idea to stop attempting to add new features and get the current features stabilized first.

    They have actually gotten to that point. However, they have mentioned that they learned to code making construct, and therefore not only is the code in many places kind of a mess, the structure of the program doesn't allow for a lot of the necessary fixes. It would be faster to recode the thing from the ground up than to fix everything, so that's what they're going to do. It won't require a complete rewrite though so it should require less work than coding construct 1 did.

    I'm aware we were using the 'unstable release' but it is not possible to use the stable release when all help, advice, and such only refers to the most recent unstable. And the first response to any question is 'be sure you are using the latest unstable!'

    The term stable/unstable is a bit of a misnomer. Stable doesn't really mean that it's entirely stable - it means that it's stable enough, but there's not any new huge crazy bug in it anywhere so it's at least as safe enough to use as the previous one. I would vote that a lot of the time the unstable releases are as stable as the stable ones. I think they need to put a new label on them that's less confusing.

    Also, I'm not sure if you saw it already, but you should read Ashley's post on the topic here:

  • More info: http://ubi-art.com/

    What I find most intersting about it is during the presentation, the CEO said that they had made tools that not only were designed to make it as easy as possible for artists/nonprogrammers make games, but they wanted to make the tools available for everybody in the world to use.

    Sounds kind of like construct.

  • Tips for working with ginormous games:

    Split up large event sheets. They become too unworkable when there's too many events in a single sheet. Don't make a new event sheet for this - actually make layouts for the event sheets you want to include. The reason for this is an event sheet that isn't tied to a layout will list every object in the game in the expression editor, whereas an event sheet that's tied to a layout won't.

    However, because it doesn't list objects from other layouts, you need to either paste instances of the objects you want to work with in the layout or temporarily make them global.

    More benefits of doing it this way are that you don't have to copy and paste events as much anymore and you don't have too worry about any issues that could result from copying and pasting between .caps.

  • Thanks for the interest, but I'm not quite ready to reveal much about the game yet. I don't know when the game will be done, but I would like to have it done before starcraft 2 comes out.

  • It's simple enough that I don't think it'll derail the thread. You make one sprite and use 'load animation frame from file' to load from a jpg or png.