Pretty much my experience with going free for a day. It does boost sales a bit for the next few days as well but I'm not really sure it's worth it. Giving it away for free to 100.000 people to get a few hundred extra sales feels a bit wrong, and probably stops working if you do it too often. It might be more lucrative if you have a good in app purchases though.
-
Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.
Indie Game Development Discussion Thread | Of Being Professionally Poor
- Thread starter chubigans
- Start date
- Status
Pretty much my experience with going free for a day. It does boost sales a bit for the next few days as well but I'm not really sure it's worth it. Giving it away for free to 100.000 people to get a few hundred extra sales feels a bit wrong, and probably stops working if you do it too often. It might be more lucrative if you have a good in app purchases though.
lordfroakie
Member
Corel Painter 12 Education version is currently 54.99 on Amazon 
Nice, persistent upgrades or roguelike one time powerups are both good in my book. I adore Binding of Isaac. All the best on your project and I hope I can play it before 2017
PoopShooter
Banned
Hey guys, I'm currently streaming the Global Game Jam for Vancouver this weekend.
I'm actually sitting beside our keynote which is Brian Provinciano who made Retrocity rampage. If you guys want to ask him questions, tweet us at #vanggj or leave us a comment on our twitch channel twitch.tv/vanggj .
Just wanted to throw this out there since it was this is the indie thread. Also, post back here on gaf. also great.
I'm actually sitting beside our keynote which is Brian Provinciano who made Retrocity rampage. If you guys want to ask him questions, tweet us at #vanggj or leave us a comment on our twitch channel twitch.tv/vanggj .
Just wanted to throw this out there since it was this is the indie thread. Also, post back here on gaf. also great.
OccamsBlender
Member
Thank you so much for posting this! ^0^ So much useful information.
This is really really awesome! Fantastic work <3
I don't need to be a student to get this?! If so, OMG I want it!Corel Painter 12 Education version is currently 54.99 on Amazon
I've been doing pretty well with SAI so far, but this is an epic price. Ty ty
lordfroakie
Member
OccamsBlender
Member
Nope
And bought. Thanks a billion for this heads up!
Now if only Photoshop went on a Steam sale...
I've been messing with Construct 2. I dig it. It's very intuitive and you can get results super fast.
Though I've been wondering about something. They've only just added support to export desktop exe apps via node-webkit in the latest beta release. Since the engine is based on HTML5, it doesn't look like there's currently any other way to export a desktop app. Does anyone have any experience with node-webkit? It seems pretty straightforward, as it just combines a barebones Chromium build and node.js, so I figure there shouldn't be any issues. I wonder if this is good enough to potentially publish your app in native desktop app stores like Desura, GOG, Steam etc...?
Though I've been wondering about something. They've only just added support to export desktop exe apps via node-webkit in the latest beta release. Since the engine is based on HTML5, it doesn't look like there's currently any other way to export a desktop app. Does anyone have any experience with node-webkit? It seems pretty straightforward, as it just combines a barebones Chromium build and node.js, so I figure there shouldn't be any issues. I wonder if this is good enough to potentially publish your app in native desktop app stores like Desura, GOG, Steam etc...?
Ok, so this is a warning for anyone trying to create a platformer in Construct 2 where pixel perfect movement is necessary, well, or where *any* kind of precision platforming is necessary, really. This situation still hasn't been solved:
http://www.scirra.com/forum/topic62067.html
http://www.scirra.com/forum/how-do-i-limit-the-game-frame-rate_topic58751_page1.html
I already ran into this problem messing with some WebGL particle effects. Any framerate drop can result in the arc of a jump changing. This is using delta time/framerate independent motion. You can always resort to framerate dependent timing, but this will obviously result in slowdown on any system that can't render the full 60 fps, though it won't affect the physics.
This is particularly shitty for mobile games that should be playable on several generations of phones, but also for desktop or browser apps running in different browsers and on less powerful systems.
I guess delta-time is just really unreliable in Construct 2. I doubt it's a general HTML5 thing.
Which means I'm probably back to GM Studio once again. Ha!
http://www.scirra.com/forum/topic62067.html
http://www.scirra.com/forum/how-do-i-limit-the-game-frame-rate_topic58751_page1.html
I already ran into this problem messing with some WebGL particle effects. Any framerate drop can result in the arc of a jump changing. This is using delta time/framerate independent motion. You can always resort to framerate dependent timing, but this will obviously result in slowdown on any system that can't render the full 60 fps, though it won't affect the physics.
This is particularly shitty for mobile games that should be playable on several generations of phones, but also for desktop or browser apps running in different browsers and on less powerful systems.
I guess delta-time is just really unreliable in Construct 2. I doubt it's a general HTML5 thing.
Which means I'm probably back to GM Studio once again. Ha!
Ok, so this is a warning for anyone trying to create a platformer in Construct 2 where pixel perfect movement is necessary, well, or where *any* kind of precision platforming is necessary, really. This situation still hasn't been solved:
http://www.scirra.com/forum/topic62067.html
http://www.scirra.com/forum/how-do-i-limit-the-game-frame-rate_topic58751_page1.html
I already ran into this problem messing with some WebGL particle effects. Any framerate drop can result in the arc of a jump changing. This is using delta time/framerate independent motion. You can always resort to framerate dependent timing, but this will obviously result in slowdown on any system that can't render the full 60 fps, though it won't affect the physics.
This is particularly shitty for mobile games that should be playable on several generations of phones, but also for desktop or browser apps running in different browsers and on less powerful systems.
I guess delta-time is just really unreliable in Construct 2. I doubt it's a general HTML5 thing.
Which means I'm probably back to GM Studio once again. Ha!
Nasty! You always have to unlink game update from display! Then update the 'game' with a fixed step, to generate keyframes for anything that moves, then interpolate those positions/rotations just before each display. Then you can do nice things like.. sleep well at night!!
Nasty! You always have to unlink game update from display! Then update the 'game' with a fixed step, to generate keyframes for anything that moves, then interpolate those positions/rotations just before each display. Then you can do nice things like.. sleep well at night!!
I think that's what delta-time in Construct 2 is meant to be doing, according to this document: http://www.scirra.com/tutorials/67/delta-time-and-framerate-independence
Ticks (frames) are multiplied by delta-time, which is dynamic, so it should always reflect the current framerate. Although it seems rather imprecise in practice. My guess is that delta-time actually lags behind the current tick/frame, or maybe this kind of calculation can't possibly be precise in the first place and this is a rounding problem, since framerate is so unpredictable when unlocked.
The developer's suggestion is certainly very telling (and baffling):
Scirra Developer said:
from here.
1080p PC video capture of Chopper Mike. It's almost done!!
You need help on editing a trailer?
I need help alright! But I'm going to do it myself as then I've done EVERYTHING! Next game however, when I've proved to the world I can do it all, I may take you up on that offer
Thanks though!!This video wasn't supposed to be a trailer, in case there's confusion. This is just to show where I'm up to, and to get the general point of the game across to people.
darkblade77
Member
Does anyone know where I can find some decent resources on creating an editor in Unity?
I'm looking at the Editor extension tools info page, and they're somewhat helpful, but I'm not sure if I can get to what I want to do from them or not.
I have a 2d fighting game engine I'm building in Unity, and one of the things it does is manage a bunch of custom colliders according to the frame a given animation is on. Since defining/editing each collider's information would be a nightmare to do 100% by hand, I'm trying to build an editor for it.
Pretty much all I want it to do is be capable of displaying an animation frame-by-frame, and allow the user to create/modify/delete elements of a visual representation of the 2d collision boxes placed over that frame. Editing fields via text and click/drag/drop mouse functionality should both be present. That information would be written to an XML file, which the game proper would use to populate the collision data containers at load.
Initially I wanted to do this externally and use something like a WinForms application, but the animations and sprite info are provided by the ex2D framework I have for Unity currently--so it would make more sense to just do it inside Unity proper... I think, anyway.
I'm looking at the Editor extension tools info page, and they're somewhat helpful, but I'm not sure if I can get to what I want to do from them or not.
I have a 2d fighting game engine I'm building in Unity, and one of the things it does is manage a bunch of custom colliders according to the frame a given animation is on. Since defining/editing each collider's information would be a nightmare to do 100% by hand, I'm trying to build an editor for it.
Pretty much all I want it to do is be capable of displaying an animation frame-by-frame, and allow the user to create/modify/delete elements of a visual representation of the 2d collision boxes placed over that frame. Editing fields via text and click/drag/drop mouse functionality should both be present. That information would be written to an XML file, which the game proper would use to populate the collision data containers at load.
Initially I wanted to do this externally and use something like a WinForms application, but the animations and sprite info are provided by the ex2D framework I have for Unity currently--so it would make more sense to just do it inside Unity proper... I think, anyway.
I've not really dipped into modifying the editor. I guess you've tried the usual unity answers forums, etc...?
darkblade77
Member
I've put a question up on the ex2D thread on the forums there(around the same time), but I haven't gone to Answers yet. I guess that'd be next!
And to provide a contrasting viewpoint, I love to hear free game concepts from people. It's not like free ideas are going to hurt me, and if I end up using one some day, even better!
Can you remember when they left the ground and recalculate their height based on the current time vs that time and ignore the delta entirely?
I need help alright! But I'm going to do it myself as then I've done EVERYTHING! Next game however, when I've proved to the world I can do it all, I may take you up on that offer
This video wasn't supposed to be a trailer, in case there's confusion. This is just to show where I'm up to, and to get the general point of the game across to people.
No problem, just looking for real products to do work on to and expand on the things I can showcase. I don't think there are any shame in getting help on external stuff like promotion as long as the product you are offering is something you made yourself.
I know it was pure game footage and it looks great!
I suppose you could. I mean, you can ignore delta if you want. Though Construct 2's main draw is that it has really solid 2d platforming physics that require little tinkering. Even creating your own custom 2d platforming movement could be considered fairly low-level in Construct. Like, if I'm manually re-positioning/interpolating position and movement of sprites I might as well forget about using Construct 2 altogether. Though to be fair, since I'm looking for pixel perfect and frame independent motion, I will likely be creating custom platforming physics anyway, since none of the built-in stuff in either Construct or GM Studio seems to be precise enough.
What I am wondering though: is delta time generally considered to be too imprecise for this sort of thing or is it just Construct's implementation? GM Studio has a delta timer too, though I have no idea if it works any better. I mean, this is Construct WITH delta time movement and basic frame jitter around otherwise stable, but not locked 60 fps:
That's just not good enough. I'd honestly rather have good old-fashioned slowdown (which is the alternative) than this.
So, if that's really what I'm looking at with delta time regardless of the engine then... well, honestly, I have no idea how to tackle a solution that would mean manually interpolating ANY movement on each new frame. Couldn't I just frameskip instead? As long as I can guarantee a framerate between 30 and 60 fps that shouldn't cause any (collision) problems, right?
A good read. Thanks for posting!
Glad you like it. If you scale the animation down to 64x64 you will get to
the original resolution (the shades are better then).
Thank you! Took me a lil.
For sure.
There wasn't an update for a couple of weeks. During December I was doing some
restoration of some of our rooms. And that took me quite some time. But my
girlfriend will love me forever. No saying she doesn't already.
Reduced to the maximum! Hey, you won't believe, but I even had an idea using... Wicked. We're both doing 'minimal' in separate spaces of the gaming universe. I should send you a Chopper to render out!
Chopper Mike in my demonstration for a short stint xD, but I ran out of time.
For one I need to implement an ellipse rasterizer to perspective project
spheres onto the screen, since rendering that many triangles for a sphere
isn't an option at the moment. And on the other hand, I also need the write an
.obj loader to get some geometries in. But unfortunately, these things don't
have the highest priority at the moment. Meh.
I never touched the TI-8x scene. But I know that there were many cool programsNeat. What are your target platforms? PC, Android, iOS...TI-82
Looks really cool. Love your emblem, btw.
for it. Target platforms? Hmmm, good question. Since the DCPU-16 specs were
released by Notch, one might think that my engine ties to his game, 0x10c. It
does to a certain degree. But targeting only 0x10c would be pretty restricted.
Btw; Notch hasn't even released an emulator. However, the specs and esp. the
instruction set format are rather simple, one can program an DCPU-16 emulator
in a couple of days. And many did. There are about 10^30 emulators out there
in whatever language you like. Hence, to answer your question of "What are
your target platforms?", my answer is; on whatever platform you can run a
DCPU-16 emulator on.
So all the common platforms can become target. But that's not what I am
interested in. I'm a bit interested in something I may call in-game platforms.
Given the DCPU-16 specs, imagine implementing an DPCU-16 interpreter into your
game (if it fits the game, of course) to allow the gamer to interact or
control various aspect of the game, or let him create things which weren't
scripted beforehand, things that may even be used within the next iteration of
the game or be used outside of it. I find this idea very fascinating.
Given a standard, possibly the DCPU-16 specs, a platform may aris. The DCPU-16
specs are pretty low (won't be a bottleneck at all). The DCPU-16s architecture
has 2^16 ports to the outside. So a game developer can build his own devices
that do serves a special purpose in the game and connect them to the DCPU-16
to allow the gamer/(DCPU-16)programs to access them. Notch for example has
adopted an idea of a 3D projector (a vector display), the SPED-3, which was an
idea and already prototyped by the 0x10c community. He took over the idea and
redefined the specs a little to make it fit with the game. Hence, we will see
a 3d projector within the game 0x10c which can be fully programmed to display
whatever you like. Likewise, there is a disk, a monitor, a keyboard, clock
etc. device. One can even go as far as mapping real game memory into the
address space of the DCPU-16, manipulating some game data straight away. The
possibilities are virtually infinite.
If such a thing ever takes off, there will be a demand for various kinds of
programs. I can imagine my 3d engine being used by other (DCPU-16) programs
who have a need to display 2d and 3d stuff within the game. You may just use
it to drive a user programmed 3d deco element, or for displaying information
sensed by other devices, or even build a mini game to be played within your
game. It's endless.
However, I don't know if it ever will, but there will be at least one game
that pushes such an idea, it's 0x10c itself. And I expect the game will have
a large user base.
...
...
Is the 'jump arc' computed by integrating a differential equation? I imagine
that Euler integration is used. If the framerate drops, then dt becomes too
large a step such that the integrator can't follow the dynamics properly.
Making dt independent of the framerate and setting it to a proper value
may suffice, but may also lead to a timestep too small. In such a case a
better numerical integration should be used.
Made a moving platform that goes along railroads.
That looks amazing! My only suggestion would be trying to make the gear under the platform rotate what I believe is a larger gear perpendicular to it to make it look slightly better.
It's already rotating or am I not getting what you mean? Thanks for the comment!
Ok, so this is a warning for anyone trying to create a platformer in Construct 2 where pixel perfect movement is necessary, well, or where *any* kind of precision platforming is necessary, really. This situation still hasn't been solved:
http://www.scirra.com/forum/topic62067.html
http://www.scirra.com/forum/how-do-i-limit-the-game-frame-rate_topic58751_page1.html
I already ran into this problem messing with some WebGL particle effects. Any framerate drop can result in the arc of a jump changing. This is using delta time/framerate independent motion. You can always resort to framerate dependent timing, but this will obviously result in slowdown on any system that can't render the full 60 fps, though it won't affect the physics.
This is particularly shitty for mobile games that should be playable on several generations of phones, but also for desktop or browser apps running in different browsers and on less powerful systems.
I guess delta-time is just really unreliable in Construct 2. I doubt it's a general HTML5 thing.
Which means I'm probably back to GM Studio once again. Ha!
This a big javascript problem in general. You have to use system using real millisecs from the Date object.
I don't think I can change how dt is calculated in Construct. Here's what it says in the documentation:
The way it is used in this example would lead one to believe it is very precise:
How to use dt
Typically, framerate dependent motion is done with an event like this:
Every tick (once per frame), the object moves one pixel to the right. Notice that at 30 FPS this means 30 pixels per second, and at 60 FPS this means 60 pixels per second. Those are different speeds, depending on the framerate.
Remember from the example above that dt always adds up to 1 every second. So if we change the event to the following:
...the object will move to the right at 60 pixels per second at any framerate. Since dt adds up to 1 every second, 60 * dt adds to up to 60 every second. This means at both 30 FPS and 60 FPS our object moves to the right 60 pixels every second - the same speed, regardless of framerate.
The bolded is obviously not completely true as you've seen from my previous posts and from the links. Apparently there's a margin of error so huge that it basically renders the advantages of dt meaningless. And this is deemed acceptable by the developers, as they've stated here.
Shouldn't delta time be using "real" milliseconds in the first place? How else would you calculate the time between one frame and another? You would have to use something like the system date. I just don't get where the aforementioned imprecision is introduced...
edit: sorry for dp
Yes it should but it seems it doesn't in your case unless your math is off for your movement.
I was suggesting calculating the delta time yourself since it sounded like you were using some sort of third party library.
Uhh, really?
The problem is hidden. Even if it adds up to one, which may be perfectly right,
as say describe, the problem is that dt may change in unequal amounts during a
period that adds up to 1. dt might be 0.6 in one interval of said period and
the other tens of a second add up to 1 some frames later. However, such a
single large time step may already be too large for the integration rule. No
matter if the steps add up to one or not.
It's the dt implementation hard-coded into Construct 2's physics. There's nothing I can change about it, unless I create the platforming physics from scratch myself, which would obviously defeat the whole purpose of using Construct 2 in the first place, although it looks like I will have to do just that. :/
Like I said, the Construct developers claim that dt is inherently imprecise regardless of the engine:
Scirra Developer said:
I'm not sure what to believe anymore.
also try something like this for your movement
x += Xvel * ( delta / fps );
x += Xvel * ( delta / 1000 ); maybe?
and get FPS by
var new_date = new Date;
var fps = 1000 / (new_date - last_date);
last_date = new_date;
AcceptableGhost
Member
If Construct 2 has non deterministic physics and you cannot fix it, absolutely stay away from it. Nothing is worse than non deterministic physics.
That makes sense. Like I said, I could always just implement my own delta time calculation, but I will not be able to use *ANY* part of Construct's physics engine (which is the main reason why I'm using it), since dt is built into their engine and evidently not calculated with enough precision. Unless I create all of my own calculations from scratch, I will not be able to circumvent their dt implementation.
Yeah, I dunno. Maybe this works in javascript, but this is basically how they recommend to do your own dt calculation in Construct as well, so I figure it must also be how they implemented it in their physics engine, yet it still isn't precise enough. Maybe this is an HTML5 thing or just a Construct thing. No idea.
Looking good man. I don't post in this thread often, but I read it all the time. You're game has come a long way since you first started posting about it. When is it out? I'd buy it.1080p PC video capture of Chopper Mike. It's almost done!!
I don't know if it's of interest but most browsers have an implementation of the High Resolution Timer standard.
http://updates.html5rocks.com/2012/08/When-milliseconds-are-not-enough-performance-now
http://ie.microsoft.com/testdrive/Performance/WhatTimeIsIt/
You can force the engine to just stop any motion if it drops below 60 fps and resume once it can hit 60 fps again, which is entirely useless in practice, but the only way to test a theoretically perfectly stable 60 fps. If you do that - I tested it - physics are entirely predictable and you get this (3 jumps):
^ Remember that this isn't actually useful while playing, since the engine has to stop rendering several times to hit jitter-free 60 fps.
So even with basic framerate jitter at a "stable" 60 fps (58-60) you get this:
And that is *with* delta time! So, I don't know if this counts as non-deterministic...
Again, almost all of the information including the pics are from these threads:
http://www.scirra.com/forum/topic62067.html
http://www.scirra.com/forum/how-do-i-limit-the-game-frame-rate_topic58751_page1.html
But I've personally verified it all. It's easy to recreate.
Nope! Construct 2 is Game Making for Dummies lol
...which did sound like what I was looking for initially
This will just be a lesson for me... and for everyone in this thread really. Construct 2 is good for prototyping and for little iOS games, *not* for someone looking for precision and entirely predictable motion/physics. A bad match for 2d platformers in my opinion - even though that is precisely what it was made for.
AcceptableGhost
Member
You can force the engine to just stop any motion if it drops below 60 fps and resume once it can hit 60 fps again, which is entirely useless in practice, but the only way to test a theoretically perfectly stable 60 fps. If you do that - I tested it - physics are entirely predictable and you get this (3 jumps):
^ Remember that this isn't actually useful while playing, since the engine has to stop rendering several times to hit jitter-free 60 fps.
So even with basic framerate jitter at a "stable" 60 fps (58-60) you get this:
And that is *with* delta time! So, I don't know if this counts as non-deterministic...
Again, almost all of the information including the pics are from these threads:
http://www.scirra.com/forum/topic62067.html
http://www.scirra.com/forum/how-do-i-limit-the-game-frame-rate_topic58751_page1.html
But I've personally verified it all. It's easy to recreate.
Run, RUN away from Construct 2! This is some bad stuff.
BigWeather
Member
razu, was "You is dead" intended? Neat video regardless!
Haha, yeah, that seems to be the best course of action at this point. Once again, this is what the developers of Construct 2 have to say about the issue:
Scirra Developer said:
lol?
eot
Banned
I'm a little confused by those pictures because even if the framework reports an incorrect frame time your code, if it's working correctly, should give deterministic results in space, the only noticeable difference would be in time which I don't think those pictures show (unless they're jump height as a function of time). Or maybe I'm just making myself look stupid by posting when I'm too tired :e
This could be the problem, but even the 30fps plot has enough points that it should solve the trajectory much more accurately than it does even with the Euler method. I don't think most platformers use higher order methods and they still work fine at 30fps. Also, there doesn't look to be any convergence from 45fps -> 60fps, just a decrease in height. Has to be a code problem.
This could be the problem, but even the 30fps plot has enough points that it should solve the trajectory much more accurately than it does even with the Euler method. I don't think most platformers use higher order methods and they still work fine at 30fps. Also, there doesn't look to be any convergence from 45fps -> 60fps, just a decrease in height. Has to be a code problem.
There is basically no code. Literally just 4 lines simulating a jump to the right and spawning the little colored squares - this is looped 3 times with different colors. The rest is Construct's physics engine doing the work. You have parameters here to change gravity, acceleration etc., but that doesn't happen in the code or at runtime. What you see causing these wildly different jump arcs is *only* the framerate changing.
And even with no change in the framerate, this is the result due to (unavoidable) framerate jitter (+/- 2 fps):
^ And that's just one example. Every time you restart the simulation the difference in the arcs between the three jumps is slightly different. It is only predictable in the way that the framerate jitter is. In this post I described the only way to get deterministic results: forcing the engine to literally stop whenever it doesn't render at a full 60 fps. It is bizarre that this is necessary and the fact that their delta time implementation, however imprecise it may be, can't even compensate for minimal framerate jitter of +/- 2 fps is certainly baffling as well.
But rest assured, this is a fundamental flaw in Construct's physics engine. It has many of those.
- Status