Candescence

@Serephim: Just be warned, Construct Classic can be buggy at times. The instability is partly why Construct 2 was redone from the ground-up. And the EXE wrapper... I've tested it, and it works perfectly. I was wondering why the next C2 release was taking so long, incidentally. Can't wait for being able to export via the wrapper.

Yep. Even when you save projects as a single file, they're just practically zip files. And project folders are perfect for team projects.

To say Construct 2 is a 'shitty' program compared to Construct Classic is, to be frank, quite an exaggeration. Scirra have been, with each new update, adding features from Classic into C2, the latest being families. At this point, the only major feature left from Classic that needs to be implemented is containers (and that's only if you don't include behaviors and objects), though feel free to correct me if I'm forgetting anything. C2 is much more stable and intuitive, in my opinion, and it improves on old features as well. The main thing it's lacking is the number of built-in objects, behaviors and no effects, but with WebGL support the latter will inevitably be included. Unless you use WebGL, which is uniformly very fast on all browsers... Except for it not being used by IE, but fuck IE. Honestly, C2 is rapidly improving, and I have no doubts that it'll eclipse Construct Classic eventually. The modular export system will, in time, allow C2 games to be exported to any platform there is an exporter for, and HTML5 already means C2 games can be played on way more platforms than Classic games can, web or not.

Alright, Gen set up a poll in the thread, and, well, there's a massive majority that thinks this is a good idea (28 votes total, 22 say yes, 2 say no, and 6 say maybe). Looks like this is probably gonna be happening, folks, something I am very eager to see.

Just yesterday, Gen came into Sonic Retro's fangaming forum and posted a rather lengthy proposal concerning the idea of a 3D Sonic game engine that is built from the ground-up rather than relying on other engines such as UDK and Unity. Here's the topic itself. Okay, I'll admit. This was completely unexpected in many ways. It's certainly not something I would've anticipated at all. But then I looked through his post, and I rubbed my chin, considering all the ways this could actually be of benefit to 3D fangame makers. Among other things, features can be included in one package that some engines have but others don't, come up with features that none of those engines have, tailor the engine to be able to suit the needs of people who want to make any kind of Sonic game, scripting, easy-to-use level editing... The works. This will require a considerable amount of planning, but I think that, if a proper team was assembled and people are actually motivated to do it, this could actually work. Comments?

A gameplay trailer is something they should've shown in the first place. They're trying to string us along again with a teaser and concept art. Until they do show us something of actual substance, fuck off, Sega.

I wasn't gonna play SxT anyway, Dan outright being killed off was a big enough insult as it is. Bad box art Mega Man, even though it was originally Inafune's idea, still feels like trolling - it would've been a lot funnier if, firstly, Legends 3 and Universe hadn't been cancelled, and secondly, Mega Man was actually in MvC3U. This just seems mean-spirited on Capcom's part, otherwise. With Mega Man's 25th coming up, Capcom better have something really special planned.

This problem wouldn't exist if driver vendors actually provided some security against this sort of thing in their drivers. Granted, the actual need for it hadn't appeared until stuff like WebGL appeared, but still... I think Khronos and browser makers will address these problems at some point, they've already stated that they will. Better than goddamn Flash, though, as far as performance goes. Seriously, whose idea was it to give UE3 and Unity (which has its own web applet, no less) the capability to run games through Flash? Flash is pure shit. If Flash's video streaming can bring multicore, multigigahertz computers to their knees in order to jerkily fail playing h.264 video that would run silky smooth on Pentium IIs or G3s as unwrapped files, I cannot fathom how it could run modern games at a reasonable speed even when using the GPU. Java should have filled the niche of web-based games that Flash mostly owns.. except that early versions of Java were so slow and so unnatural looking that Flash actually looked good in comparison. By the time they fixed it, Flash had become the de-facto standard for this kind of thing, much to the chagrin of just about everyone except Adobe.

Yeah, I know, if done right, they CAN work well. And then sometimes they just make things hard to actually see shit when everything's varying shades of brown. I just personally find environments that are heavily desaturated and/or mostly brown to be incredibly boring most of the time.

Guys, I think you misinterpreted my point completely. I didn't mean at all to say that UDK does brown and desaturated games best. I was saying that pretty much nearly all the example maps included in UDK are desaturated and brown, while the CE3 forest example is vibrant - I just like that one map better for that reason. Of course it's all down to artistic choice, thinking otherwise is, well, kinda stupid. Granted, brown and desaturated is generally a stupid artistic choice, but whatever.

Well, I understand what you're getting at. Though, for the input management thing, resetting all values to zero was pretty much what I did, on a family-wide scale - saves on actions, really. Unless I'm overlooking something. From what I can tell, the part that I'm doing wrong is the controls (the "Family_Player" picking bit is fine, from what I can tell). The input management setup should be solid - in theory, anyway. The problem is how to make each Player respond to the separate inputs properly, so I think the Control Management area is where I'm gonna have to look at more... Unless there's something in the Motion Management/Movement area that I've overlooked.

Well, I've got more of it working better, but now I honestly feel like I've hit a brick wall. Here's what I've done: - Added 'Player' variables to a few objects and families - Added an 'Input' family to store multiple InputPlayer objects, and changed every condition outside of the Input Management group so they adhere to that, not just the original InputPlayer object. - Re-worked the inputs for the Input Management events to work with multiple inputs - Used a 'pick by comparison' event for Family_Player to ensure that every set of sensors sticks to the right Player object - Used similar 'pick by comparison' events so each Player and Input object pair should do its own thing, in theory. This has been less than successful, as explained below. - Managed to get animations working separately. - Got sounds working separately as well, to a degree. Problems so far: - Player 1 only runs and jumps with P1's controls. - Player 2 does absolutely nothing, except jump... When Player 1 jumps. - Sound weirdness when both Sonics are idle. Here's the cap. If Streak or anyone else has any idea on how to make this work, go ahead. It's better than before, where both Players more or less did absolutely nothing no matter what input was given, but... I know not everyone wants to have multiplayer in their games, but I still think it's neat to implement that kind of functionality early so it can be easily implemented if the developer wants to, and it could be used for other things such as a Tails follower (or other characters), AI (to whatever degree the developer wants, if they're capable), etc.

Out of boredom, I tried rigging together some rudimentary multiplayer functionality by adding a "Player" variable to a bunch of stuff and modifying the events to accommodate. Thought it would be pretty easy. Turns out that shit is harder than I thought.

Yeah, I was talking about browsers such as Chrome, Firefox, Safari, Opera, etc. I haven't even heard of Seamonkey and Midori. Also, I know about the alledged security concerns, but I believe that's mostly Firefox-related stuff that I think has been fixed by now. On a slightly more unrelated tangent, Microsoft have been trying to bury OpenGL for years while trying to promote DirectX as superior (which isn't really true).

Oh, yeah, it does. One of the main options upon export is 'minifying' the script, which is enabled by default. Basically, it makes the source code as it is virtually unreadable. Plus, the actual assets are stored in folders away from the script and the page itself, so unless you can actually somehow get to those files as well, the source code is virtually worthless. Actually, that is MUCH less of an issue now that Construct 2 HTML5 games uses WebGL by default, making performance uniform across all browsers that support it, and much better than if the browsers were doing it by themselves. The only browser that doesn't support WebGL right now is IE, naturally, because Microsoft don't want to touch OpenGL with a ten-foot-pole. The easiest solution in that case is to advise users to get a better browser.

Ah, I understand. What you've made right now is a very solid foundation anyway, good enough for anyone else to build on it. Well, I can understand how one can feel that. Why not just ask Dami? He's actually stated on Retro that his Egg Engine isn't really being used by anyone right now, and he outright offered it to the Sonic 3 HD guys. Well, to be perfectly frank, HTML5 isn't really mandatory, just the only export option at the moment, as the developers are working on features before they can consider working on an OpenGL executable exporter. HTML5 was chosen as the starting export option mainly because it can be played on a very wide range of platforms (including iOS, which doesn't support Flash), and Javascript is a relatively easy language to learn for plugin developers, which has been more or less optimized to hell and back by browser makers. And... Correct me if I'm wrong, but you can't simply rip a HTML5 game out of a web page like you can a Flash file.

Brilliant! Honestly, this was the original route that my version of SCW was meant to take, but due to my lack of experience with MMF2 (and inability to properly read the event code) and my lack of experience with making static engines, I scrapped it in favor of trying the Custom Movement route. And when I tried that with Construct 2, the way that behaviour works there rendered me unable to recreate that engine, so, yeah. To see someone with much more experience with Sonic Worlds re-take the static engine route and succeed where I failed is a joy to see. I threw in a few solid slopes, and I can confirm that slopes work perfectly, as well as gravity and all that jazz. This is a fantastic foundation for a proper Sonic engine in Construct. Streak, you win a million internets. What's more, once families are implemented in C2, recreating this engine there will be a non-issue (minus most of the camera and input plugin stuff (no plugins for that, unfortunately), and C2's audio system can't do positioned sounds (yet), but, oh well). May I ask why that would be the case? Doesn't exactly make sense for an open-source project.

Of course, the first step in doing this is for someone to make a Sonic engine for this in LUA. Who would do it, however, is another question entirely.

I know. Though, we need a topic on it in the right place and with, well, a lot more info, haha.

Though the iPhone controls aren't exactly spectacular, this version of Sonic CD is the best, hands down. Honestly, I really want this to sell well for the sake of sending SEGA a message to do more Sonic titles like this, but unfortunately, this game was used as a marketing ploy for Sonic 4, and thus knowing SEGA, they'll think it sold well because people want more of that, instead, and therefore we'll get more shit.

A while back, the CryEngine 3 SDK was released to the public for noncommercial use. However, it really hasn't garnered much interest so far in the Sonic fangaming community, especially since there's nothing like the Sonic GDK for UDK that people can work with. However, the SDK seems to have a rather straightforward and informative manual, and, as of more recent versions of the SDK, it includes a demonstration level, a forest on a coast. It's even better-looking when you actually play it.Sure, it's not Unreal Tournament, but that's not what that fan-game makers are wanting to work with, and the map isn't brown and desaturated as fuck. The Sandbox editor seems quite neat, and it includes a visual scripting system. Or, if flow-graph scripting isn't your thing and you're not afraid to try out actual scripting, the SDK uses what is arguably the best scripting language in the industry, Lua, which I hear is quite easy to learn and use. Any thoughts?

@Chronic: I guess "less is more", huh? If simplistic visuals can work for, say, Iji, then I guess I can't complain.

That looks pretty damn nice, Icedrink.

Might as well show off a couple of things for Aria of Destiny. Firstly... The image below is something I've been working on a bit recently, it's an attempt at creating indoor concrete tiles for the player's 'home base', which appeared at the end of the demo for the Construct Classic version of the game, but I wanted to expand it considerably to allow for rooms for each character, and to prevent things getting cluttered. Unfortunately, the assets I originally used, from Mega Man ZX Advent, weren't exactly suitable for this purpose, so I took what I could use (the floor tiles) and made additional tiles using their colours. I'm not an artist, however, so the results are simplistic and, well, attempts at making 'decay' were as subtle as a brick to the face. Better than nothing, I guess. I also decided to make the general screen size for the game itself much wider, to 640x480, and decreased the size of the 'bottom screen' to allow for a much larger player view. The 'bottom screen' is now half as tall as it was before, but also twice as long.

We Aussies have to put up with that shit all the time. We pay twice as much as the US, despite the aussie dollar usually being on par or better than the US dollar these days. 360 and PS3 games brand new tend to be around $110.