QuaziGNRLnose's Forum Posts

  • we need a universal time to meet or something

    as for iso, the engine itself would be designed as easy to add on to as possible, it would basically be topdown, and then the engine 'displays' iso graphics based on the top down (the assets would be 3d obj/sprites depends what). It wouldnt be crazy complex, but for the advantages and look i think we should consider it (and it wont be too hard to explain and use since ill make a real conscious effort for USABILITY while making it, and some fine documentation to go with it aswell)

    really the reason i think it would be good is

    -you can get a better feeling of the world since it has physical comprehensible depth.

    -with the '3D' iso, buildings and big terrain objects can easily "phase" into one another, and assets will look a lot less repeated if theyre viewed from different angles etc., which is super easy in 3d

    -game world will be way more readable, buildings dont exactly look very different when viewed from above.

    -unique aesthetic

    -if instead of 3d objects we opt for 'primitive based' iso, buildings can be lit dynamically, allowing for day night cycle/lighting to look really awesome.

    -with multiple programmers the extra work wont be ridiculous. anyway, the base display struct of the engine will probably not need much work after its initially built. iso wont change much with the: randomization (if anything there can be way more, and you can be lazy since ordering and intersection becomes much less important): anything at all with inventory or ai.

    -it'd be cool to make huge open grass lands or dessert with vehicles to travese them that bump all over 3d rocks on the terrain and are physics-y and awesome.

    as for art what style are we going for?? i can always help out with graphics too, whenever need be. gritty pixelly could look good, and would severely cut back on the time required for individual assets, opening up lots of time to make TONS of gibs and graphics for other stuff, instead of wasting all our time focusing on getting animations to work we can work on gameplay (especially if we want lots of variour injury states for zombies). not to mention pixelly leaves more to the imagination so you can get a rich mental picture/atmosphere of the world (think impressionist painting vs classical)

    Those were some of my ideas and a little bit as to why. i have like a bajillion more to tell so, here are a few i already wrote down in ramble.

    The graphics could sort of look like this but more serious, higher res, but same type of ambiance

    dl.dropbox.com/u/1010927/piggy2.exe

    thats an old version of the engine with no support for object phasing tho.

    now heres a newer version (looks uglier atm cause it has no terrain stuff) that has object phasing, you can drag and drop the pieces in both demos to see what i mean. (right click) the lighting can be changed on the fly, all the objects can be defined etc.

    dl.dropbox.com/u/1010927/phasingiso.exe

    as of now, the second one can be a bit laggy, but thats because all events that should be ran only once on generation/rotation change/lighting change are running every tick, for every object, in a completely non optimized (but highly optimizable) way.

    if we were to go with these objects (cubes, pyramids, going to add ramps and triangular prisms and stuff) then id probably make a simple tool for building "objects" and texturing them, which then our engine would load for the random values etc. theres A lot that can be done, and even simple as they are untextured the buildings looks pretty great. also the engine supports movement over the objects flawlessly, so you can, if you wanted to, climb to the top etc. anything meant to interact physically with the terrain would simply have to be added to a family, and its 'type' defined through a variable.

    anyway, yea. tell me you guys' thoughts. im sorry for the general crappiness of my writing in this post in advance.

  • it'd be nice to use my iso engine since it supports lighting (with direction) and shadows, but ofc i'd need to clean it up and make a few tools for building stuff out of primitives. (or alternatively i could make a 3d object variant of the iso engine, but no dynamic lighting, lighting would need to be baked, although more complicated buildings and stuff could be made, might even be able to do dynamic lighting with texture setter.)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • yea those two games should 100% be possible in CC!

  • just

    drop

    a

    pm

  • i would love to be in on this (but i can't guarantee ill ALWAYS be available to do stuff because of school) but yea! this was basically the idea me and davio had for WHINE, but never got around to doing much on it

  • Are you using python for any particular reason, or just trying to learn?

  • i remember the ol'days when ash could only be a guy in a suit juggling light bulbs... and i thought he was a girl :P

  • wat

  • try to teach her math through an abacus, i hear people who did at a young age can easily add numbers like 1234124+141951 in their head quite rapidly, but have no idea how.

  • /b, windows IT platform.

    lol

  • well you dont need to "spawn" a bunch of stuff, you can set the width/height to the x,y size of the box.

    in essence you just need to store the initial position of your click when you click using (((floor ((MouseX/Y) / 32) * 32) +16))like you have already (and seem to understand) in a variable like INITIAL CLICK X, INITIAL CLICK Y, for x y respectively, then from there on if mouse button is down set the width of the box to ((floor ((MouseX) / 32) * 32) +32)-'INITIAL CLICK X') and height to ((floor ((MouseY) / 32) * 32) +32)-'INITIAL CLICK Y'). you might need to adjust the +32 part depending on how your sprite is positioned, but you seem like you'll be able to figure that out.

  • construct is way better at making EXE's at the moment is more likely the reason, i'd use html5 if i could do as much.

  • you can use containers if each turret is unique, but if you have lets say 4 turrets that are all the "same" sprite, as in a single object type containers may not be the best way. you'll have to give each ship an id, and then give the turrets two variables, one for their ID, and one for their ship ID. using events youll have to make a

    for each ship

    turrets variable 'ship id'=ships('ID')

    -ACTION: TURRET SET POSITION TO SHIP, IMAGE POINT = ('TURRET POS ID')

    you could try it with or without the for each, not sure if it'll make a difference, but sometimes it does depending on what your doing.

    so for each ship, lets say if they had 4 turrets, you'd have 4 turret objects that youd need to create, and give them each the same 'SHIP ID' when you spawn them (you would do this at the start of the layout, or when you spawn a ship by creating 4 instances and giving them their given ships id as 'SHIP ID'), and then numbering them 1 2 3 4 for their TURRET POS ID. that variable would tell each turret what exactly they are on their given ship. of course if you were to follow everything i said youd need to give the ship 4 image points. i realize this is a little confusing to describe in words, so if you have any trouble just reply :D

  • battleships <3

  • worst comes to worst, and gamemaker eats up all the market (which i highly highly doubt), c2 will just destroy GM on the Direct-x OpenGl game creator side of things, just like CC has been doing for years even in an incomplete state.