exmachina64
Banned
Edit: Nvm.
So my assets for Apexicon have slowed down (my partners in crime are doing summery things), so I'm going to switch to a quick (hopefully) Wii U game idea that I'd like to release fast on the eShop.
Currently titled: Psyscrōlr
I'll show some development tomorrow!
i feel like unity doesn't give me as much control as i would like.
anyone ever write their own engine?
Psychic Norse mythology!gangnam style?
What kind of control are you looking for?i feel like unity doesn't give me as much control as i would like.
anyone ever write their own engine?
It's a big move taking Mike out of the chopper, since now you have to deal
with a lot of stuff which will make the game a bit more complex to create.
What was the line of thinking doing so, initially? Vehicle switching?
Nice, nice! The craft may fire the boosters as well to stabilize itself upon
firing. Might be a feature to be turned on/off depending on the situation.
i feel like unity doesn't give me as much control as i would like.
anyone ever write their own engine?
i feel like unity doesn't give me as much control as i would like.
anyone ever write their own engine?
A new low poly experiment, this was actually really tricky:
It is fully shader based, no animation and no particles, running in the UDK.
A new low poly experiment, this was actually really tricky:
It is fully shader based, no animation and no particles, running in the UDK.
Looks great.
When you say it's fully shader based, what triangles are you drawing? Is it just a quad with all of that in it? Or are the smoke clouds a draw call each...?
I think as soon as he could switch vehicles it felt natural to be without vehicle, as the constant is Mike.
I'll have to do the animation and code for that. But a character is actually a lot more manageable than a vehicle when it comes to trying to talk to NPCs.
I think you'll spend most of your time in a mix of vehicles, doing missions. Then spend a little time talking to people as Mike.
Toying with the idea of being able to switch vehicle at any time, as you can now. It's kinda fun
I'm always super impressed by what you put out.A new low poly experiment, this was actually really tricky:
It is fully shader based, no animation and no particles, running in the UDK.
Ramp textures are used there, mainly with normal/fresnel but also based on distance. Vertex colors are used to mark different intervals and some amounts.Everyone seems to be going for this look. Are you using textures or vertex colors?
Well, there is still also geometry that shader is applied to. Basic geometry that have their vertexes moved through world position offset in the shader. It is one shader but with 3 different variations of settings, for the fire part, the sparks part, and the clouds part. So the whole is then 3 draw calls.Looks great.
When you say it's fully shader based, what triangles are you drawing? Is it just a quad with all of that in it? Or are the smoke clouds a draw call each...?
Zero animation, all shader. I had to paint some vertex colors though to define amounts and intervals, for the embers I just generated the vertex colors with noise.I'm always super impressed by what you put out.
I like the little embers; did you have to hand-animate every piece of this?
What if all the NPC's were in vehicles too? So you could drive alongside somebody as you were being told the next mission, or flying your helicopter in (a simple) formation? If you wanted you could mix them, have Mike hover over a car in his helicopter as they head to the next waypoint for example?
Oh damn, I didn't notice the line under the gif.Zero animation, all shader. I had to paint some vertex colors though to define amounts and intervals, for the embers I just generated the vertex colors with noise.
A new low poly experiment, this was actually really tricky:
It is fully shader based, no animation and no particles, running in the UDK.
You'd still have to have different monobehaviours for different things though, right? Which would then have to implement all the interfaces of the underlying structure, just to pass them on, and every time you add something, you have to remember to update your 'main' monobehaviour for that thing.How so? Instead of doing everything inside multiple MonoBehaviour scripts, I have a couple of interfaces with functions, like Update(), that are called from one MonoBehaviour script.
There is one GameObject which has a MonoBehavior script. Instead of a couple of interfaces, there now is one base object class. Every object adds itself to a list when instantiated.You'd still have to have different monobehaviours for different things though, right? Which would then have to implement all the interfaces of the underlying structure, just to pass them on, and every time you add something, you have to remember to update your 'main' monobehaviour for that thing.
Don't get me wrong, I didn't really like the component design at first either, but .HasA is so much easier and cleaner than big huge hydra-classes that just grow and grow.
Howdy all, I need a program to do some 2d animations in and I was hoping you guys could help me. I'm using Haxe+OpenFL+HaxeFlixel, so I need my animations in sprite sheets. So far I've just been piecing images together but that sucks a lot. I'm willing to spend some money, but not too much. Hopefully under $100. Any recommendations?
TL;DR - I need a drawing program that supports animations for under $100.
Mac preferred!
Spine is pretty nifty, and has served me well so far. It has a Mac distro and a Haxe runtime (which I think means you don't actually have to rely on spritesheets, since none of the runtimes I've used do). Unfortunately, although you can get the $60 essential version, I can't in good conscious recommend something less than the currently $250 professional version. Still, there's a demo of the software that you might like to try out.
Did you also wrote the rendering backend? Stated otherwise, are you usingI do.
Me and my college wrote an engine using XNA framework for our game Snails and then we ported it to iOS using Xamarin.
Then, I rewrote and restructured the whole thing using c++. This is the engine I'm using to write my new game.
I want to write simple 2D games, and for that purpose this homemade engines do the trick.
Beautiful! :+ Well done!A new low poly experiment, this was actually really tricky:
It is fully shader based, no animation and no particles, running in the UDK.
... I spent today doing some character art. I'm kinda iffy on the second design, Pupus, but the rest I'm pretty happy with:
Hmm thanks! $250 is really expensive though. Arrrg. Is there a particular reason the Professional one is much better?
Also nice art! What did you use to draw it?
Thanks! I'm using Adobe Illustrator. I've heard great things about Inkscape, which was free last time I checked, but I've never had a reason to use it. Illustrator's the industry standard, and I was raised on it since my dad was in clothing design when I was younger. So Inkscape hasn't been something I've ever looked into.
Regarding Spine, the main reason I'd advocate for professional is the use of auto-keying animations. When you move stuff in a new frame, it automatically stays there instead of you having to manually confirm it each time. I pretty much always have auto-key on, and can accidentally lose a good amount of work if it accidentally gets toggled off. Most of the other pro-only features have been pretty handy as well, but not necessarily essential to my workflow. To be honest, it feels a lot like they cut out some features from the software so they could get away with charging more, but I like Spine enough and it's helped me enough that the price was worth it.
But maybe you find you don't need that. It's why I mentioned that Spine has a trial version. If you find yourself able to work well without the pro features, don't let my discouragement keep you down!
To further elaborate, my general process is this: draw the character in Illustrator, specifically drawn to be in segmented articulations. Export the art as a PNG at 2x2 size to get better interpolation. Import the art into Spine. Build the skeleton. Animate it there. Export the animation and load it in my runtime (GameMaker Studio).
This is what Saepe looks like drawn in AI, first to scale and then split up into her individual articulations. Spine builds the actual texture atlas for you, and does it much more efficiently than I have here.
Then it's pretty simple to build a skeleton in Spine and attach the images to it.
That's great! Thank you! I'm gonna try the trial when I'm done with finals tomorrow. Hopefully I don't need auto-keying. By manually confirming do you mean what he's doing here: https://www.youtube.com/watch?feature=player_embedded&v=Eg7M43MoPu8 ? Like pressing K or clicking the key icon for every frame? I know I've used onion skinning before and it's been very useful (but not necessary). Hopefully I can get by without it.
When you draw your characters, do you draw each segment in a new layer? I must admit I'm not the best artist so the thought of planning a drawing like that kind of scares me.
Are you making an OS there, Missile?
Would you be running Mac? On my previous game I used Spine along with Sketch, which is a vector drawing program. I believe it's not too expensive. The export workflow was pretty nice too. It was quite easy to export the pieces separately to png or whatever format you need.Spine looks great! But it looks like you need to have the images drawn beforehand? I could work with that. Thank you! Maybe I'll buy Sketchbook Pro with it for a total of $120.
Any cheap alternatives to Sketchbook?
I think I figured out a low-impact way to synchronize different animations. This was for the specific goal of synchronizing palette-swapped animations, but it should work for any animations with the same number of frames.
I also made a super simple palette-swapping command-line utility. The sad part is that of course there are probably 50 other tools that already do this for free, better, AND probably 50 ways to implement it more efficiently and effectively than the couple of days I spent on it. But hey, it seems like it works well enough, and I just have to get all the palette colors figured out.
I'm using my own rendered, but it's pretty simple. It only draws sprites, and a sprite is nothing more then a quad with a texture on it.Did you also wrote the rendering backend? Stated otherwise, are you using
more then just "put/setpixel" for doing all of the rendering, or are you using a
third-party graphics API?
A new low poly experiment, this was actually really tricky:
It is fully shader based, no animation and no particles, running in the UDK.
Yea, it is fresnel combined with a ramp texture, so it defines it with a gradient from front facing faces to away facing faces.Oh damn, I didn't notice the line under the gif.
That's even more impressive knowing that. I take it that the brightest center area continues to face the camera if it rotates around? Shader stuff like this is so damn cool; I love the experimental stuff you post.
It is made with the lovely Unreal Engine node based shader editor, you have a instant preview there. There went also quite a lot of try and error into it.Well... hot damn.
I wish I had even an inkling on how to start on that.
I mean, I can do something similar in pure code, but shaders have no real data lookup and persistence except in textures, right?
Would you be running Mac? On my previous game I used Spine along with Sketch, which is a vector drawing program. I believe it's not too expensive. The export workflow was pretty nice too. It was quite easy to export the pieces separately to png or whatever format you need.
Correct. There's a key binding, default K, which sets the rotation/translation of the bone for that frame. That probably seems pretty simple. For me, since the trial lets you test out auto-keying, it became pretty evidently superior in only a short time. But that's just for me, so maybe it won't for you.
In Illustrator, I don't work with layers very often. It seems a bit redundant since all of the shapes are vector objects. But I do group the vectors together (cmd-G) that make up each articulation.
And it definitely takes thought regarding planning. Figuring out how things will need to overlap, what order they'll need to be in; those kinds of things take practice. But Spine helps out a lot with this. For one thing, nothing's stuck on its hinge, so you can pan images around in addition to rotating them if it sells the movement better, and you can change the draw order on any frame of the animation, and the pro version of Spine also has mesh warping so you're not limited to rigid movement.
Nice! That's quite some work spent. That C/C++/SDL thing is a solid one,I'm using my own rendered, but it's pretty simple. It only draws sprites, and a sprite is nothing more then a quad with a texture on it.
I add features to the engine when I need them, at this moment the engine includes:
-Simple renderer - draws sprites, filled quads and lines (opengl/opengl es)
-Scene manager- scenes are loaded in groups, so it's possible to switch scenes without any loading time
-Objects in the scenes have parent->child->child->child(...)hierarchy . Childs follow the parents
-Box2D is integrated at this moment with minimal support
-Simple scripting language that I use to perform simple tasks (usually in menus)
-Asset manager - this asset manager controls the assets used in the game and it makes sure that the the same asset isn't loaded twice
-Audio manager - it's working, but needs to be reviewed
-Input manager
-Sprite animation editor
-Font editor
The engine is developed in c++ and uses SDL. It's multiplatform and is currently running on Windows, iOS and Android, but it will run in MAC and linux also, I just don't want to waste time with that. I'm only interested in targeting mobile devices . I'm looking into porting to Windows Phone too.
You were rised by Windows, right?Are you making an OS there, Missile? ...
I was thinking the same thing. You want low-level control of everything, you want to render all pixels directly instead of using libraries, you're making a window manager, might as well finish making the OS!