Can't you just show us something? I'm curious about your implementation of the jelly bodies in Flash.
MUST SEE!!

especially for you i will make an export (after i get home today)

about 20 minutes to make and send the pictures as jpg, png, ... or directly as byteArray compressed or uncompressed.

start with this:
http://www.adobe.com/devnet/air/ajax/quickstart/jpeg_file_upload.html

be careful! you need user interaction to upload file request headers.
on backend you just accept them like anyother incoming image.
ho well it works: check out http://www.clic-clac.com/
when those numbers tick it actually transfers the 3D image and the 2048x2048 texture.
- this app also uploads all the data necessary to reconstruct the box.
I MADE THIS.

you can try to decompile, but it's unreadable. i was pretty a noob back then, but it was a step, nevertheless.

there is a chance flash player gets open source this year. now imagine that! not only you have a powerful scripting language but you also have control over it's graphics engine. what 2D is concerned, your set. and i'm sure with some modifications you can directly inject AS3 and run it. this was removed due to security reasons, but it's still there in AS2 (run at script level). anyway, a swf is the script and graphics resources mainly, so there should not be any problem to make a console out of it.

i'm beginning to feel like adobe's paladin.. good.

big huge LOL

i'm making my first game to.
if you count the prototypes it's 5th, actually, but those are unusable, because i wasn't such a programing expert back then (6mo).

keep it simple is the name of the game. if one of my classes get over 300 lines i immediately start refactoring. an this is something that anybody has to learn, and be good at it. but if you plan ahead  there is no need for it. if i start any project with a reasonable complexity, there is a good chance i get 8 classes in the first 2 hours.

you don't have to begin with puzzle if you have experience with planing. and to actually plan you have to get out of hacker mentality. there is no REinventing the wheel here, because it's inventing the wheel. there is a difference.

for that matter if you have enough know-how in code architecture and patience, you can code the next WoW and never get exhausted.

i'm talking about style. you cant do anything with learned practices. the ones that have evolved naturally in you are the best. and that you cannot explain to others. it's like writing a book. you cannot write a bible like the Bible is written, it will turn out exactly the same bible. you have to write it after your inspiration, and that's only way to find your own 'religion'. and planing is just that. the book is a good plan.

then you take the book word by word and translate it into code. "what matters is the connection that word implies" a program took this from wiki, and he's right. the ability of you to make those connections defines how well the book was written.

and keep in mind, the book has to have only one reader.

[UPDATE]

UPDATE

a somewhat major setback. all things worked perfectly, the blob blobbed, the bot break-danced but it just ain't fun. technically looked good, dodging bullets and stuff but kinda had a deep envy, i had to fire myself some. however a super-goo firing bullets it's just too abstract.

decision was taken to abandon the 25 point soft body. so i 7zipped it.

i have taken the initial robot and made a player out of it (changed it's color to green except red). but not all was lost.

i had the problem with the distances (1px=1m) and such so i have written a little util to translate my display space to the physics space. so now with a simple change of a constant i van control the ratio.

cheers.
i'll might come back with a "demo" this week.

[UPDATE]

UPDATE

it's been a while.
a had a little bit more to do at my full-time job so generally i always arrived tired at home. but the weekend is coming so it's time to get back on track.

this is still an update, since i managed to port the soft body from my prototype into the first level tile.
"box2d works best with small numbers" - how important this is? VERY important. i have a 1/1 ratio now and for some reasons i cannot exceed a certain speed, even with somewhat extraordinary forces. after my current movement speed and response i figured i need around 1/10 ratio, added some high speed projectiles, at least 1/20. so this is one of the things i will work on. i won't post the results, because it's clear what it's gonna be.

need to implement a main logic controller on the current setup to have a place where i can code armor, life, points, buffs and such. and as well as to extend my main class to more then 10 lines (UI, creation and destruction of played levels,...).

i have still failed to find a level-designer. and i really need someone for the next week. if there is someone who is interested, just contact me. this person needs to have basic AS3 knowledge (or not really, no,.. my bad) and some skillz with vector graphics. the colab will be based on revenue share.

[UPDATE]

UPDATE

so i figured how it would be to store the vector data along with those elements

the idea works like magic. both physicalisation and dephysicalisation. it is a great feeling when you implement an idea a and actually see it work. i might say: this is what indie is all about. besides that i managed to make the first steps on creating the mainframe of the game. there are a few classes for now, but their objects communicate like magic. the great sentence:

prototyping is over
development is begun

the character and at least one of the enemies are now the main focus. when i managed to port the character from the prototypes and set up the controls, i will get back with the next update.

No thread is complete until someone tries to justify piracy in it.   

  uuuu i ain't the first.

piracy is a variable that can be dealt with in multiple ways, either one of them won't stop it. in fact i plan to distribute one product via torrent and other "unconventional" means.

how? i will do some freaky game, offer full singleplayer with a 30-60 seconds wait time when it starts, and no multiplayer. advert in the game and other annoying stuff. after buy, take all that away and offer a well polished multiplayer, no countdown and such, and support.

and if the premium version hash fails, i make the client connect to a Trojan server  .

anyway, few hacker communities hack indies in mass witch is a good thing.

[UPDATE]

UPDATE

i managed to create the script but it just generated too many points and/or was too processy. it would have been an option to lower the precision,.. but that's not an option since:

the levels will be created from predefined element anyway, so i figured how it would be to store the vector data along with those elements. i really hate additional work when creating graphics in general.

next step: figure out how to make an 8 mile long level without overloading the physics engine and still look and behave credibly.

go for a smoke (which is bad for your health, not mine) and come back later,...
so i'm back.

get the obvious out of the way and cut to the real deal. when a portal (level segment) is activated the enemies and physical elements of the portal are created at run-time. when an enemy get near the limit of 2 portals a dependency is automatically created between the portals and they behave as one. also for processing reasons the enemies will b created from 1 piece, and - lets say - when the shield is blown down from the bot it will be physicalized, and destroyed/faded out after a while. and that for any mechanical carnage; for this idea i tend to make it extensive now.

here it is 1:15 am . so i go 2 sleep .

[witch i don't, actually lying here]

thx for the tip.

i'll torrentit.

And that, friends, is a fine example of what NOT to post on board frequented by indie game developers who loathe piracy even more than their mother-in-laws. 

and that, friends was a joke. it should be taken into consideration anyway.

at some point i arrived at the conclusion that until the human mind is free, you cannot control information and piracy is just a syndrome. so when piracy disappears we have a serious problem. piracy is good to a certain level. on the other side of your angry eye i must point out, that the all the illegal stuff that i download illegally, (witch i don't, actually lying here) if there is one that it worth it, i go and buy it. the main that drives me is usually multiplayer and sometimes good support. there are exceptions too. if i see some good discount or something i just want to have in my library i just buy it without thinking.

one of witch Diablo III will be. can't wait for it to hit the stores.

that is some of the causes i mentioned (thk i did) that multiplayer as a good and soon to be essential part of an engine in order to make it profitable.

[UPDATE]

UPDATE

the blob is alive and kicking, and just about that for the moment. i am working on a class that converts my graphics into point arrays. this is useful since i am just too damn lazy to program the levels bit by bit after i create the graphics for them. this lets me implement them with some ease into box2d's engine.

[Who M. I.]

jee vee ass bee for
Jelly versus Bots. (the real name will not be widely published just JVSB)

first things first:

Who M. I.
name: szeredai akos
occupation: front-end web developer
hobbies: gaming, and.. gaming

social status: livin' with girlfriend, 2 cats, 2 parrots

JvsB

type: platform shooter

language: AS3 (flash player 10)

medium: web, mobile (touch, normal, when flash 10.1 is out), and possibly desktop via zinc or other quality/custom framework.

estimated time to develop: 2-3 weeks


the main character is a green blob. the green blob can move, jump by modifying it's surface tension, and shoot/devour their adversary. he can also turn into a heavy metallic ball rolling over enemies, the robots.

the robots are various types, constructed from multiple parts. there will be no legs in this game. the bots will "run" on one or multiple wheels. they will be stupid, heavily armored, carry gunz, and most importantly a fun to watch them disassemble on impact and die. damage control. i am planing on having about 6-10 type of these suckers and several bosses.

my main focus is to have some easy to medium complexity puzzles mainly based on physics and a decent action. also i am thinking of implementing a sense of power (big blob, many little bots to die) by introducing an enemy initially hard to eliminate and after a while make them come back in numbers and fall like rain in front of the more evolved blob.

monetization will be based on advert, most likely, that is if i don't get a good license offer. a premium version will be held back for the possibility of further licensing. and i have a link open, if one of you wants to get on board.

i am open to any suggestions, critique or ideas.

thx for the tip.

i'll torrentit.

you have a ton of stuff there that could turn your project to vaporware. i reeeeeely admire your will. at this time reinventing the wheel is the best thing you can do to advance. however if you got stuck somewhere for more then 30 min, i recommend that you search for references. it gets in your head anyway.

overlays and effects could impact your full frame redraw, i recommend that you use redraw regions. you point out the part of your array that has to redraw and you redraw only that rectangle. for this you have to have some positioning system in place (array

• [y] or something). and there is antialiasing, and so on..

anyway, good luck. (i just love these eyes) 

i think a good engine can be developed. but not by someone who has one focus or or to be more precise someone who just disregards a possible implementation.

maybe there is a way to do it in the indie community. don't really know. but games are to date considered one or the most complex pieces of software, coupled with the experience of indies, and a clear focus on the goal could lead to a good start.

and end up in vaporware. 

however there was a software i played with a while ago, it was named virtools or something. it's focus on modularity lead them to the concept of a behavioral engine. pretty impressive it was.

and still is, for that matter. http://www.3ds.com/products/3dvia/3dvia-virtools/

it was used for the creation of some of the titles. on feature which i have to point out is that you can spread the calculation of an algorithm across multiple frames thus have a very good control over (otherwise mediocre) performance.

either case, you need an initial speed.

register a force pointing towards a center and set a tangent initial velocity.
if your body moves in a circular fashion you are lucky, most likely will have an elliptical path. you must do the math to get it exactly right. trial-and-error works to for some degree.
  

I'd put a bias on solidity. If it's not stable, you'll be annoyed, and also your players will be annoyed. I'd imagine it's easier to kludge a missing feature than to fix an instable engine in the average case.

solidity is a qualitative property. and therefore it is a basic criteria.
what good it is one feature or 100 if the game keeps crashing, or run slow for that mater.
that is why i did not include it. anyway, features market, speed dose not (only if it is very fast).

but if i recall formalization was my main focus

What do these games cause then?

orgasm

The job of a game engine is to provide useful functionality, to make it easier to create games.

In my experience, strictly formalised game engines (such as ones which mandate MVC) are not useful;  they slow down and complicate the process of creating games, rather than expediting and simplifying it.  You'd be better off to throw them away than to actually use them.


I find it far more useful to have an engine which consists of useful functionality, and just have your game code call into the bits it wants to use, rather than have the engine try to enforce a strict game structure that limits what's allowed to talk to what, or try to define and enforce The One True Way To Make A Game.

"Engine" is one of the most confused words in game development nomenclature... Anyway, strict architectures != dogmatic architectures. Large projects need strict designs relevant to the task. As you say, the purpose of all underlying game code is to facilitate the game, but system architecture (architectural patters) is a one part of the solution to the problem that is the creation of the game, just as implementation patterns are solutions to more isolate problems on the way there. Structure == good. Experience == good. Best practices == good. Dogma == evil bad fail at making and having fun. And I agree with you, one pretty nasty smelling dogma is the belief that there is One True Way (to make a game or whatever), but that is not the same as "any way is good", or "all ways are equal". Generally speaking, one should have a pretty solid reason to deviate from time-proved best implementation practices, but good developers will also generally have good reasons. Saying "strictly formalised game engines should be thrown away" is an huge overgeneralisation, but I assume you've had bad experiences with dogmatic peoples' code. 

you don't to have to be an experienced programer to have a reason to deviate from time-proved best implementation practices. "proved" is OK, i have no problem with that, but "time" is a serious issue. many of the practices may not work because of a simple cause that they are outdated. for example oop or lately parallel processing, multi-threading, and so on. then there is the issue of constantly evolving languages.

another, and from my part, the most relevant. some practices cannot be applied to a type of game like to another. and as a game developer specially indie you might want and do experiment with different, new genders. so

"strictly formalized game engines should be thrown away" because they do not facilitate improvisation and invention. they are good for machines. i tend to master them not become one of.

if you browse for an engine, what is the first thing you search for?
features.
the more the better until you end up with one that is not formalized at all.

"An engine is a machine that produces mechanical force and motion from another form of energy"
"An engine is a code that produces data from another form of data".
it's an encoder

[LEZ GIT AT AWN!]

you know what the freaky hell i am talking about.

there is
LEZ GIT AT AWN!
and
We Be Jammin'
on the front page.

just please replay to the post that how genius i am, or something.