Hello!

I'm making a trailer for a mobile game. I wanted to use some public domain stock footage of wildlife in it, but the videos I wanted to use are pretty low resolution (640x480 pixels), plus they have some quality issues (i.e. ripple effects and other artifacts).

The trailer will be on Youtube, and also (technically through a link to Youtube) serve as the featured video on the Google Play page for the game.

What would be the minimum expected resolution that is acceptable these days, for different kinds of devices?

What I have so far looks really bad when magnified past its actual resolution (640x480), but looks totally OK in its "natural" dimensions.

Also, alternatively, do any of you know some cheap sources of animal footage with high resolution that I could buy for this trailer?

Omg that trumpet is incredible hahahaha. Very charming!

-Felix

Thank you for listening! I'm making do with the samples I have... Nice trailer music -- did you have to write it according to set timed events in the video or could you influence the timing somewhat? I'm making a trailer for my own game but there I'm simply basing the video upon the timing of my music, which seems to me to be the easier and potentially more successful way of doing it, but I guess that's not how things work in the industry?

I'm really more of a programmer, but while procrastinating with regards to coding I make some music.

Here's a thing that could be used as a theme song for a spanish or wild west hero or similar...

https://soundcloud.com/lars-johan-martin-nilsson/hero-theme-1repeat

Would love some comments on this...

Hello!

I'm thinking of embarking on a project of developing a package of loopable music pieces that would be maximally usable for as many games as possible. The pieces would have some similarity in orchestration, and use different variations on a dozen or so of themes/motifs distributed over the various tracks, so as to give the suite some sense of unity. Among these perhaps a couple of hundreds of pieces, the game makers could freely choose among the tracks those that would be fitting for their particular game.

I won't give it away for free, but would sell non-exclusive licenses to use it for a small fee.

Now, the question is how to make the music as generally usable as possible. I'm thinking of making a chart where I fill out all spaces in a four- or five-dimensional grid labeled with the values of very general parameters along the axes.

For example, one of the axes of the grid would be Intensity, with values from "calm", "low intensity", "medium intensity" and so on up to "very high intensity".

Another axis could be Mood, or perhaps "Happiness" with values between "sad" ranging to "blissful" or something similar.

Yet another could be Tempo, ranging obviously from "very slow" to "really fast". Although this is partially related to Intensity, but not totally.

So the idea is to produce a piece for every combination of these values. Do you see where I'm going, and has anyone here tried something similar? Any idea for good values for the axes of the grid?

Hi!

I mostly focus on programming my own games, but have quite a background in music, so I thought I'd better post my game music portfolio here:

Skrjablin's game music portfolio (Soundcloud)

My specialties are quality of melody (tunes that you will actually remember!), but also an ability to compose music fitting for any mood required. I have experience in writing authentic chiptune music, especially for the C64 SID chip via GoatTracker, and can easily adapt to other trackers/systems/sound cards.

I can also write background music in a more extensive way, using all the bells and whistles of a modern Digital Audio Workstation, all the way up to fullblown orchestral arrangements.

I will take great care to usurp all available information that will help me develop the right mood for the tracks, such as desired intensity levels along the game play journey, desired moods and distinctive characters that may deserve a leitmotif of their own.

I am easy to cooperate with in various ways, and will make a considered effort to make your game music the most epic music that is possible.


I'm available for hire, mostly chiptuneish stuff or similar. I will probably not write your game's music for free, but rates are negotiable, so please send me a message and we'll discuss it!

Also, if it might interest you, I've previously released some tracks as public domain at

http://opengameart.org/users/skrjablin

Games (that I know of) that used my music:

Little Ninja Game
Tiny Soccer
Doge Catch
App Warrior
ESCAPE your Doom

* Haven't done much work on the game during the weekend, had other things to do, sorry.

* Touch controls are something I haven't given much thought to so far. There's really no point to me using HTML5 for this if I can't get it working nice on mobile devices. I'm thinking of giving up scrolling, since it gives a flimmer on the screen on slow devices, despite the frame rate being OK. I have tried various technical implementations, with CSS and multiple canvases and whatever.

So just levels consisting of static connected rooms then. Which I think will be OK.

Example of touch controls:

* Go left / swing left: Touching to the left of the spider
* Go right / swing right: touching to the right of the spider
* Go upwards / shorten thread: touching above the spider
* Go downwards / lengthen thread: touching below the spider
* Throwing the thread towards a new fastening point: Drag in the direction you want to throw it
* Releasing the thread: , perhaps touching with two fingers???

Would these work? Or am I better off rewriting what I have right now, in Flash?

* Finally implemented the generalised routine for swinging from moving objects.

* Movement keys somewhat changed. WASD for moving when on platforms (you can also use A,D for moving left/right in air while falling), and when swinging the keys are A and D for swinging more to the left and right, and W and S for shortening/lengthening the string. The E key is for abandoning/jumping off the thread (or should it be Q or perhaps F as default?). Mouse is for aiming a new thread. This way you won't leave the thread by mistake when running out from a platform while hanging in a thread, but just get some extra swing, which most often is what you want.

* Trying to improve performance by using several HTML5 canvases, which works, I'm running at 60fps at least in Firefox on this old mini laptop. But only ~45fps in Chrome, for some reason. And there is annoying flimmering when scrolling for some reason. Will have to investigate that. I'm using requestAnimationFrame (of course) and time based animation, which gets pretty complex with my complicated equations for the thread.

* Drawing the thread when it's loose is really slow, since it's a lot of small lines to be drawn. So I turned that off until I find a solution. Maybe all my fast equation solving was useless if the browser cannot plot the curve in time -- I might have to just use the browser-supported bezier curves to get a similar curve simply.

Neat project! I hope you get wrapping around solid blocks working! That'll be lovely to see.

I've also been doing some stuff with hooks and ropes lately, though I'm approaching it from a very different angle (using spring linked masses). It's neat to see someone else working on this sort of thing from a different perspective. There's something very clean about your approach.

I agree with what you're saying- I think there's a danger of the controls being too unwieldy or unintuitive once you start adding verbs. I'm somewhat drawn to being able to manually shorten / lengthen the web. I think that will lend itself to a lot of different applications. I think you could do that somewhat intuitively by mapping it to two axes of the player movement (though I think this would be much more intuitive in a game where up and down are absolutes).

Automatically shortening / lengthening is a neat idea. It sounds like it has potential (and removes the need for two inputs!). I wonder how it would behave in situations like swinging and climbing up to / down from the ceiling?

Thank you for liking it so far! The hardest thing will be wrapping around moving platforms and support points, because then some segments of the bent thread might become unstretched (which I do have a routine for now, yay!) or the whole thread can be "pulled away" in some direction by some moving support point going too far away. I will just have to think it through and enumerate all the different scenarios...

Yeah, I've certainly pondered the option of using a physics library and modeling the thread as a couple of linked points. From examples that I've seen then the thread could sometimes become curved even when just hanging from it, instead of being straight normally as in the pendulum motion I've modeled. And the former has the potential to be cool, and is actually quite realistic for something as light as a spider, where air resistance plays a big role. But now I've come so far with this modeling from scratch using physics equations that I might as well go with it...

Shortening/lengthening the thread will certainly be available even if I use Alex' idea of automation of length when standing on platforms. It is actually already implemented for all cases. It was not so complicated, as I store the "pendulum" position as just an angle, and then treating the angle together with thread length as a polar coordinate which I transform to an ordinary geometric coordinate to get the player position (of course taking into consideration that y axis is wrong way compared to mathematics, and other things...).

Posting to follow because I like the idea and the relatively simple pixel art you've got going (the bricks remind me of Mario).

As for the web mechanic, the mechanics you proposed (going up or down, and swinging left to right) should be fine. Combining the normal web swinging mechanics with specific times and situations in which you need to use your momentum from "short swings" caused by protruding level geometry should be fun and pretty difficult to pull off.

In your last posted example, I think it should be possible to walk off of the edge, pull up the thread, and release in time to fly through the air and land on the other side. So I think part of it is really building the level to be fun to traverse basically all of the time.

I like Alex's idea of auto-shortening the web. That sounds like it should be easy and fun to work with.

Thanks for following, and general positivity! Yeah, I guessed I could try it without automation too, so that the thread gets "too long" when you finally get off the platform, and you have to shorten it manually during swinging. It might be interesting for the player. But for other reasons of implementation I now do believe Alex' idea of automating the length while on the platform is the way to go, though.

The level idea you have there is interesting.

The pixel art is actually mostly public domain tiles from opengameart.org, by someone called "surt" (with contributors "Sharm" and "vk"). (Thank you "surt" and "Sharm" and "vk"!!!). Including the spider. The ant eater sketch (will be changed to a pangolin, though), the fly trap and the fly are my own though.

And the bird is by my friend, who is a designer, and whom I have asked to do some more graphics for this and who accepted that challenge, even if he's not so experienced in doing pixel art. So we'll see how that turns out.

Automate some of the process;
say you have attached the web- while you're on the platform auto lengthen the web so that it is always taut while spider moves on platform. When the spider reaches the exact end of a platform and is moving off it, auto shorten the web enough to cause the spider to start swinging off of the platform.
I suggest this because most of the swinging will probably need to occur at the edges of platforms- so just make this process automated so you don't have to do any jumping or lengthening of the web manually(though that could still be done after the swing has begun)..
This is just one idea.

Yeah, that's a good idea! It will also let me not have to worry about how to calculate it when both ends of the rope are unstretched (one end ending in the spider, the one ending in the support poing) but the middle is lying straight across the platform. I can calculate that as long as there is just one end unstretched and I know the lenght of the straight, lying segment, but with two different loose ends it sort of gets weird.

Thank you for a great answer!

[Do you people have any ideas how to make the mechanics as intuitive, fun and simple at the same time somewhat deep?]

So, I have most of the swinging mechanics implemented now.

Now I have an interesting design question (I think...)...

With the current mechanics, you can do this:



i.e. the swinging happens conceptually "in front of" all the walls, so you can swing to the next platform in a simple step like this. (The only thing you do input-wise is click where you want to attach the thread, and then click left or right (A or D actually) at a suitable point in time to let go of the thread).

Now, I'm pondering another kind of mechanics which would make walls be actual stoppers for the thread. That would allow you to do interesting things like this:



It will be hairy to program but I've thought it over and I think I'll be able to do it. But there is a danger in that simple actions would become too complex with such a mechanic, like if you would want to do the same thing:



then at first you would just stay where you are as picture 1 shows. To actually swing you would have to walk to the right until you start to fall:



but then your rope would be so long that you would only swing to a point below the next platform as shown. To actually then get up to the next platform, you would have to press up (W) to shorten the thread, then swing left and right with Q and E to get enough amplitude to be able to finally jump off the thread to the next platform:



Quite complex. If you alternatively from picture 1 would start with pressing up (W) to shorten the thread, there is the risk that you would just boink into the platform you were on again, before and instead of swinging away over the gap:



Although I guess this last situation would be avoidable if you started from further out on the platform...?

Do you people have any ideas how to make the mechanics as intuitive, fun and simple at the same time somewhat deep?

Since the thread swinging is the main mechanics of this game, I want it to be able to give raise to many and varied situations.

* New chiptune: https://soundcloud.com/hitcomposer/potential-game-tune . But honestly I don't know if this one would be useful in Freddie. I might use it for another game that I'm planning to do, instead.

* I'm thinking of letting the swinging happen "inside" the level instead of "in front of" it, because that would be potentially cooler and more intuitive. But it would be complicated to program things like this:



Especially combined with moving blocks all the special cases would be a small hell to get right. But it would be cool I guess... could allow for some new kinds of platformer puzzles...

* I optimised the hanging rope code today thanks to a tip I got at freemathhelp.com that one of my variables could be eliminated before I did the numerical approximation. Finding the curve for the hanging thread now takes about 1ms in Firefox and 0.3ms in Chrome, this is on my 5 year old mini laptop. And that performance will be completely OK for all platforms, I think.

* I have solved the problem of how to show the thread when it's not stretched. To find the curve of a rope of a given length hanging from two points of different height, you have to solve a non-linear equation system in three variables, which must be done with numerical methods, so I implemented Newton's generalised method combined with an equation solver for linear equations in three variables, and some matrix functionality, which were needed to find the solution.

But unfortunately the method takes about 4ms on my 5 year old mini laptop to find the solution. That means I won't have time for much more than this during a frame. And the problem gets worse on mobile platforms, which I intend to target. Maybe I can make some simpler solution for the mobile platforms.

Animated gif of the thread hanging from two moving objects coming tomorrow, provided I can install some of those gif making programs.

If you are interested in the details of this, please tell me! It was quite complex... in my humble opinion

* Work on the revised player movement mechanics continues, slowly.

* A new chip tune, for "swamp" level or something: https://soundcloud.com/hitcomposer/freddie-the-spider-swamp-theme

* I'm thinking that Freddie on his journey will get into a human's house, which will mean level themes like "The Garage" and "The Toy Box" or similar. But maybe not for the first demo, as this means I will have to design new enemies that seem fit for such levels. And more artwork, of course.

* You will not be able to swing from most enemies, but just from moving blocks and platforms. This restriction comes about since otherwise it would be really hard to restrict player movement enough when doing level design. So it's a design consideration, and not due to technical constraints.

* Today I implemented "jumping blocks" as a new example of movement pattern for moving blocks.

* And I have the swinging from a back and forth moving block (x(t) = k*sin(mt)) finished, and the routine can easily be generalised to swinging from a block moving in any pattern, as long as there is some way for me to calculate (i.e. derive) or estimate the acceleration of the block each moment. So tomorrow I will implement that generalised routine, and then you will be able swing from blocks moving in circular or oval patterns or whatever.

* Slow progress with trying to get swinging from a moving object to work -- it's all about chaotic differential equations...

* But at least we now have a bird:   

I'm not a platformer-lover, but this looks like it could be fun I like the idea of swinging as opposed to jumping. I don't think there are TOO many of those.

Thank you for being positive about this! There are lots of things to be done before the game or even the demo is ready, though...

Yeah, most of the ninja games and similar have swinging rather as an addition to jumping and wall jumping and lots of other stuff, my approach will be more minimalistic: only swinging and no jumping. Although you will also be able to walk on walls and in ceilings as I said.

* Today I didn't do much, but I talked to a possible graphics artist where I live, he's not so experienced in pixel graphics but will probably give it a try. More about this later.

Today:

* Slow progress in the player movement code, which has to be rewritten to a large extent to incorporate all features I want
* Design decision: the more flies you catched recently, the more silk production you will have. Larger silk production means that you can throw your thread further away.

Features (to be pruned later) that I want for the initial demo/version:

- Ant eaters (enemy): like a goomba, dies when touched from above (and perhaps below too)
- Birds (enemy): they bite off your thread, fly in different patterns, kill when touched
- Frogs (enemy): have a rotating tongue
- Venus flytrap: static enemy, can sit on walls or floors or ceilings -- fills the same function as spikes, used quite often in level design to prevent climbing on walls or similar
- Blocks that disappear when touched or hanged from, but respawn again a bit later
- Iron block -- cannot be hanged from
- Moving blocks and platforms, which can be hanged from, too
- Flies with various paths (to be eaten, fill the function of coins/fruits) 

Rethinking a bit.

You will be able to walk on walls and the under-sides of platforms (ceilings), just like real spiders can do. Although there will be a lot of wall spikes in levels to prevent this. 

Swinging in a thread happens conceptually "in front" of the rest of the level, i.e. your swinging will not be prevented by walls. Only when you let go of the thread will you float/fall in the air to the closest floor/wall/ceiling, where you will stick.

There will be wall elements to which you can't throw your thread (i.e. iron or similar material). And there will be wall elements which can only bear your weight for a short time before they crackle/disappear (but will probably respawn again after some interval).

You can latch your thread onto moving things, even most enemies.

I think these things will make for interesting levels.

I'm thinking of making fly catching connected to some kind of important meter, not just points. For example, silk production. But not sure of this. I want the player to be able to do exploration without being afraid to run out of silk. One thing I won't do is make fly catching raise your HP, as this most probably will be a game where you only have 1 HP (but if you die you just restart at the beginning of the level, or something).

What kind of projectiles would a spider semi-realistically be able to throw? Or, what other mechanics besides thread-swinging would be natural to add to a spider game in order to make up for more variation? The creation of actual spider nets is out of the question, sorry, this will be one of those spiders who don't build nets. Maybe spitting poison?