• Content Count

  • Joined

  • Last visited

Everything posted by Deban

  1. Great! That is really useful. So... my game designer opinions: That depends in how much time you have to finish your project and your budget. Multi-player takes a lot more time and resources. Of course it will add life time to your game, but if the core of the game suffers because of the amount of efforts that the multi-player demands, then it's not worth it. Even if you have a multiplayer game, you need some sort of single player part, at least for the beginners to practice and sharp their skills (like playing with bots in a MOBA). As a note, a single player game with a multiplayer option is harder to make than a game with a single focus. You will basically be creating 2 different games with only parts of the mechanics shared between them. So, multiplayer is better but only if you have the budget and time to implement it without making another part of the game suffer for it. Similar answer. The more devices the better, but it takes a lot of time, thought and money to make it run in every place. Part of that is coding the transformations, but another large part is the game design of those differences. For example some people can be able to see more in one device than in another, having an unfair advantage. If you have a multiplayer game, this becomes one of the mayor issues you have to think your game around. The screen size, vision and even the controls. For example: using a keyboard is way faster than tapping options, a mouse is more precise than a touch screen, clicking distant things is faster than tapping them (less travel distance) and some people even have macros in their keyboard. And those topics have a lot of deep. Like the vision, it's not only affected by the screen size and the resolution, it's also affected by the user itself, as in a mobile device it will cover a part of the screen with his finger (which doesn't happen in desktop). Of course a lot of this doesn't affect your particular game, but I'm sure there are some more problems in that type of game that you will run into. I just don't know them because I never made anything similar. If you are making a single player game it's similar to the last question. The more platforms the more possible income. But it takes a lot of resources to ensure that in al devices players are going to have the same experience (and that sometimes means that they are different versions). If you ignore that, you can possibly waste resources because in one platform your game sucks because it doesn't feel right to play with that controls or it's too hard/easy. So, my advice is: if you have a multiplayer game, stick to desktop unless you are rich and want a trip through hell. If you have a single player you can focus on desktop and then adapt it to mobile (or the other way around) or if you have the resources think about both at the same time. As a note, if you don't have the experience, I strongly advice against the last one. Nowadays cross-platform, without a doubt. There are two opinions about this that I'm aware off. If you have to leave the option to the player, it's because you couldn't decide which one was better for your target, so as an easy solution let the player choose. Accessibility is one of the most important features of your game, and having an option allows your game to be played by hardcore and casual gamers alike.I think that both are true. The truth is that the less your player has to choose for you, the better. But it's also true that time and budget is limited and sometimes shortcuts are a necessity. A good enough option is having a default option and allow to change the difficulty in a sub menu. That way people can start to play without being asked to choose the difficulty, and probably the hardcore gamers will find the option to make it harder. An improvement of that is having the first level being some sort of hidden test where you test the player abilities and change the difficulty accordingly. Of course this is a lot more work. The best way is making the difficulty change dynamically based on the player performance. For this to work, the difficulty can't have big steps, it needs to have smooth changes. This is an incredible amount of work. And by the way, nobody likes the "Hey you died for the third time, looks like you suck really hard. Want me to lower the difficult for you? crybaby" Usually creating different types of difficulties is really hard. Of course I mean not just adding HP and damage to the enemy and call it done. For example in a rpg: the difficulty has to touch the amount of gold (dropped and cost of items), the exp (drop or to lvl up), any kind of commerce, the AI of enemies, the amount of enemies, the AI based in the amount of enemies, enemies reflex (reaction time) and reaction time for the player. It should be the same game, but more difficult, the same strategies work (your lvl 50 attack with a specific item should always kill that creep in one hit, for example). In your game I think it's a lot easier (I'm not sure as I don't really know everything about it) so I will go with the good enough approach because it can evolve in the testing level if everything goes right. If not, it also works pretty well that way. Cheers.
  2. Octree and quadtree are the same thing, the former is a 3D implementation of the last one. Let's see... For what I understood, you use the shapes to check if they collide. Collisions are divided in 2 phases. The broad phase and the narrow phase. The broad phase is checking what can possible collide, the idea is to avoid using a free 4 all check (everything with everything). The common way to do this is by spatial partition, dividing the space in sectors. In 2D the common approaches are: a common grid (also called hash table), a quadtree, binary space partition and sweep and prune. Spatial partition means getting everything that is in a zone, or even near a zone. You can use this algorithms even if you are not checking for collisions. Which algorithm to use, is heavily based in your game, how many objects you have, how much they move around, it's an open zone or a closed one, etc... Here is an excellent article on hash table to get you started. The narrow phase is checking if the objects that can collide actually do it. It's the common collision algorithm. Some people divide this in two steps, first a fast but inaccurate test to narrow the possibilities, even more, and then a expensive but exact algorithm. The algorithms are (in order of complexity, accuracy and inverse speed): Circles. The most basic, the distance between the centre points of the circle should be less than the sum of the radius for the circles to collide.Axis Aligned Box (AAB). Which is a rectangle that can't rotate.Oriented Bounding Box (OBB). A rotated rectangle.Separating Axis Test (SAT). This is where you start to get a lot of control. You can use any polygon to test against any other polygon. The more faces, the slowest it becomes.Minkowski Difference. This is a different way to solve the same as SAT. You can use multiple polygons checks. Choose this or SAT based on which one you understand most.This page contains all the algorithms except SAT. For SAT you can look here.
  3. That sounds awesome. It looks like you actually can make it real. It's really rare that people come with ideas and actually have the resources to be able to make them. About recruiting. You can post an ad here. As an alternative, you can post in general game development forums, like here, here and here. Remember to give as much information as you can. You probably need to ask someone about the technical details. Some examples are if your game will be 2D or 3D. What engine/frameworks are you using. How much liberty the programmer is going to have vs how much his code needs to be adapted to a system. Possible roles and responsibilities. You can ask most to your coder, he should tell you what he needs from other people to help/complement him. Anyway, your best chance is getting your hands dirty and instead of waiting for offers, go and actively search people and offer them the job. The best place for that is Stack Overflow because of the reputation system (you can think it like a score system that measures the knowledge) or this forum. This forum will be a little more difficult, as the likes is not that great measure system, hence you need to get your hands a lot more dirty. Good luck making you dream game.
  4. Deban

    Scoring engine

    How about plus and minus? var availablePeople = 0;When a room is created: availablePeople += 2;You can give each room a requirement of necessary free/available people to be created. Bedrooms have 0 as requirement for example. And then a room can generate/consume people. function OnCreation() { availablePeople += this.peopleGenerated;}function OnDestruction() { availablePeople -= this.peopleGenerated;}It's consumed if peopleGenerated is negative. If you have different pools of people to consume, create different variables. Treat it like resources, mana or gold.
  5. I'm sorry, I don't really understand (specially the pseudo code). Where you have the grid? What does it represent? How do you code that grid? I will try to help, but probably it won't be really useful (with the 3d mesh you completely lost me). This are examples to give you ideas, change it as you see fit. The grid code: var grid = [];var rowsAmount = 10;var colsAmount = 10;for (var x = 0; x < rowsAmount; x++) { grid[x] = []; for (var y = 0; y < colsAmount; y++) { grid[x][y] = new Shape(/*Chose type here*/, x, y); }} The shape constructor: function Shape (type, x, y) { this.type = type; = ++Shape.lastID || 0; this.position = {x: x, y: y};}And lastly getting the shape and it's surrounding shapes: var selectedShape = grid[selectedRow][selectedColum];var id =;//The surrounding shapesvar surroundingShapes = [];//How many shapes I will select on each size, it's like a radius but the figure of the selection is a square.var sizeOfSelection = 4;//Current positionvar posX = selectedShape.position.x;var posY = selectedShape.position.y;for (var xOffset = -sizeOfSelection; xOffset <= sizeOfSelection; xOffset++) { for (var yOffset = -sizeOfSelection; yOffset <= sizeOfSelection; yOffset++) { surroundingShapes.push(grid[posX+xOffset][posY+yOffset]); }}Without knowing how you implement things, I can't help you much more.
  6. Usually people don't like idea guys. You need to ability to create it yourself or the money to pay other people to create it. What I'm trying to say is that people won't join your project because your idea is cool, ideas are worthless without the power to make them real. If you want people to join you, you need at least to have a working prototype of your game; and even then people won't like if you are giving ideas while others work. The other way is paying them, contract people to make you game. You can even work by they side, but people won't usually work for free. That is called a consultation and it's usually pretty expensive. Think about it like contracting a specialist that gives you advice about your business. In a normal business that is pretty expensive, and in video games it's as well. For getting your team assemble: For coders you can look in this forum in the Jobs sector or search Stack Overflow for people with high reputation and contact them. For graphics you can use Deviant Art. Keep in mind that usually there are two types of artists, the ones that are more graphics designers (GUI, interface and all that thingies) and the more traditional (characters, backgrounds, etc...). For music, sound effects and voice acting have a look here. Good luck.
  7. That are not programming questions, they are game design. It's great that you answer them before asking the programmer to code them, but you programming knowledge has nothing to do with it. As a side note, if you are making your game in HTML5, it's cross-platform already. And even works in mobile, not great because of the different screen sizes, but works. Maybe knowing about how programmers usually behave will help you deciding. This is how it usually works, the stereotype, but there are lot's of types of programmers. Programmers won't create levels for you. They won't create a GUI either, they will place your images in the place you ask them, but not design it. A programmer will only create the behaviour of things, commonly even only the general behaviour and you have to do specifics (this varies a lot in the size of the project and team). Changing things is hard, sometimes really hard. Mock ups, or rapid prototypes created to test an idea can't be cleaned and call it done. It needs to be fully re-write to works. The bigger you game, the more important this becomes. That's comes to the top of my head. Good luck
  8. There is no best tool to make games fast, otherwise we will all be using it. There are two different things that helps making games faster: 1. Having a problem already solved. For example a rendering engine like Pixi, or collisions and cameras with Phaser and GMS. 2. Expressing what you want to do. The first one can be really useful or not a big deal at all, depending if your goal is set at short or long term. In the long term is not that of a big deal because you solve a specific problem just 1 time (like d13 mentioned). It's faster if it's already solved of course, but it's faster just the first time. If the tool solves you a problem they way you think, there is no problem at all, you can use it and be happy even after. But if it solves it a way that feels weird to you, it will eventually start to slow you down more and more, you will start to have problems expressing yourself. Expression is the most important thing. Expression is how you think about things, how systems relate to each other in your game, how you approach problems and the way you think. The way people think, or more precisely how they approach problems can vary a lot, that is why we have so many different tools. Actually some people are so weird that there is no tool that solve things near the way they think, so they have to create their own tools. You will spend most of the time translating your wishes for the computer, expressing your intentions, coding. The more similar that it's your engine/library/tool to your way of thinking and solving problems, the faster the translation will be; ideas will flow faster and the game will be developed faster. So it's completely up to you. If you find something that suits your brain patterns, stick to it until you change. We change and our way of thinking does also, so don't be afraid to change your tool when you feel it no longer goes your path.
  9. That could be true, but it can also become a real nightmare. Some games are really complex, so it depend in what game you are making. Also take in mind that with games you are handling a lot of things that have nothing to do with programming it self, like images, sound, loading files, keyboard, mouse, etc... I think when they say that, they mean more a snake or a minesweeper. The easy way is: world position of the character / size of tiles The size of the tiles is 32 but the world position of the hero does not exist in your library. By world position I meant the position respect of the world 0,0. Your character has a position that is the position of the sprite, not the real position of the character; and you update this position (the one of the sprite). The difference is that the position of the sprite is measure with the screen, the same values will always be in the same position of the screen no mater where your hero has move before. The world position is absolute to the world, for example your character can always be beside a river or a tree with the same values. Even if it's out of screen or the world is scrolled and it's in a different part of the screen. Let me tell you some basics about games that can help you: -First the game exist even if no one is looking at it. I'm no trying to be Zen here, what I mean is that your games run, things move and live, combats happens and maybe things die AND you have to show that to the player. The and is the main part, your game exist and lives by it's own, and a second part of making a game is that you have to show what is happening. What this means in concrete terms is that the way you represent your game, the way you show it, should be separated from the game itself. A character is not a sprite. A character contains a sprite that is it's graphical representation. The position of the sprite is not the position of the character. The graphic of something is not that something; and you should think them as separate things. This is one of the most strange things to people that start making games. There lot's of reason for this separation, one really important is that doing things with sprites (like moving) is more intensive that just doing it to normal number. In a normal game you may move your character (or a lot of characters) 4 times (move, collide with something and move out of collision, get hit and move back and use a skill and teleport to another place for example) and it will be much faster if you just update the graphic at the final position only. -The world is absolute, it doesn't move and everything exist in a coordinate in that world. When you move in the world you character moves for real in the world (change position) and, possible, a camera moves. The camera is what gets move, not the world. The function of the camera is what it sounds, show a specific part of the world. The most close thing to this that you have is the offCol and offRow (the distance of the camera from the 0,0 of the world, but in tiles). Your library does not respect this things, hence it make things really complicated to code. The code is: var characterCurrentTileX = Math.floor(character.x / 32) + offCol;var characterCurrentTileY = Math.floor(character.y / 32) + offRow;I really admire you resolution and perseverance, good luck.
  10. The most probable thing is that you turn base game won't be pure turn based. I meant that there should be sounds and music running and even animations playing. That means that your game have 2 parts, the one that updates it current state regardless of whose turn it is and the one that what for the player. The first part is like a normal game, with a game loop. That part you should know how to make. What it's generally done for the turn based is events. You wait for a specific event (like a click in done) and then inside that function is where most of the code regarding of the turns resides. Think in a Tic-Tac-Toe. Your normal game loop run animations, sounds, maybe a score or time. And when a user clicks, you do things that you would do normally in a game: check if the place is empty, then create a thing in there and lastly check if someone win. It's exactly like a normal game, you check collisions and allow to move in a place or not, you spam things in the map and check if the player dies or finish the map. The only difference is that a lot of things, instead of doing it inside a game loop, you do them in the event that represent the interaction of the user (clicking in a unit, click in a position to move the unit to, ending the turn, etc...). It's not that different from the player controls or a menu. Good Luck with your game!
  11. You seems to don't understand JavaScript. tileset is an array. tileset.state does not exist. An array is a group of things put together in one place. You can see an array as a street with lot's of buildings in it. You are trying to ask if the street is a specific building (if the array is a specific tile). That doesn't make sense to the program, of course a street will never be a building. The building is that street? yes, but is not the street itself. You are using the array and not what it's inside the array. You need to specify directions in the array. Say which is the address you want to go: tileset[x][y] That means: in the array, look for the tile that is at the position x and y. Here you are using it correctly: currentVal = map[row + offRow][col + offCol];tileset[row][col].setState(currentVal);tileset[row][col].update();Second, as I already told you. Your collidesWith is asking for a sprite, you need to send it a sprite. Third, tileset.state(GRASS) does not exist. You are using a variable as if it was a function. What you meant is state === GRASS. Fourth, you are using the if wrong. You should use an and (&&), but instead you are trying to paste all in one sentence. I think that what you are trying to do is check if the character collides with any grass tile. But that goes against the idea of using tiles. If you use tiles, just check the tile that the character is currently on (or about to move to for the matter) and not all the tiles. Anyway, to check all the tiles you would have to check them one by one, you can't send the array and hope for the best. You have so much bugs, and so much confusion about how things work in you own code that I think that you don't really know about JavaScript and basically you are trying to bite off more than what you can chew. Start with the basics. You can't hack your way into a game. You need at least to understand the very basics of an array and difference between a function an a value. If you just want to make a game and you don't really care about JavaScript, that is perfectly fine. Is a perfectly honest opinion, and you can use things like Game Maker or even Construct 2, they are pretty good tools. If you still want to know how to right that particular line here it's: if (tileset[characterCurrenTileX][characterCurrenTileY].state === GRASS) { character.hide();} For that you need to get in which tile the character is standing. But I can't assure that it'll work, you probably have a lot of bugs elsewhere.
  12. Remember that setTimeout has a minimum time of 4ms in HTML5 and in some browsers before 2010 it's 10 ms (source). And good luck.
  13. You are using x-y in your for, and i-j to access the array.
  14. Your steps are weird. Basically that is not a game. It's interactive, right, but won't give you any skills you will use to make more common games. And going from simple painting to colouring book is adding an image that you paint over that is almost no change at all. Normally people go with things like this: Or something close, like recreating the history of gaming (easier to complex). Pong, Pacman, space invaders, etc... But, it seriously depend in what types of games you are planing to make.
  15. First try to say which line is the problem, and please remove the things that doesn't do anything (like gravity). Going through all your code to find what you want to do is not fun. In your library: this.collidesWith = function(sprite){ //check for collision with another sprite....}And then in your code: if (character.collidesWith(tileset) && (tileset.state == 0)){ character.hide();}tileset is an array, and you should send an image. I thing that what you want to do is something like: character.collidesWith(tileset[Math.floor(character.x / tilesize)][Math.floor(character.y / tilesize)]
  16. -Circles of varied size. If you don't have unlimited zoom: One way is to use a circle of the maximum possible size at the maximum possible zoom and then scale it down. Another is to have circles of different sizes (in a png) and and use the one that need the less scaling. This way you will have minimum difference when scaled (up or down). Or use vectors. -Circles of varied colours. For the colour this will probably be useful: If you want to colour the outline, use a different sprite (one for the inner colour and one for the border) and put both inside a container (DisplayObjectContainer in Pixi) that way you only move your container. To learn about graphics you can use the examples from Pixi: It goes from basic to advance. -Fluid scaling. There are two types of graphics: vectors and raster (pixels, pngs). Vectors is what you want, they can be scaled however you want and remain perfect, but the performance is not really that good. For a vector the computer has to process all the points in real time, per frame. With 10 circles it can be done, it's possible. But I don't think you can do something like 1.000. Raster graphics are a lot faster (in Pixi you can use approximately 170.000 sprites) but are really bad at scaling. Commonly raster graphics are used and different zoom levels are hacked to look like a better scaling. This is having an image for 0.25 size, another for 0.5, 1, 2 4 and 8 for example. This images are done in you normal graphic editor and are pre-render, so you can edit them as you like. Then you use the image that is closer and will have the less distortion when scaled. -Clicking. This is pretty easy: For better performance you can take away the interactivity when the circle is clipped. -Hovering. I don't know if you want to hover with the mouse or the keyboard. For the mouse: use the functions for mouse down and mouse up. When the mouse is down hovering = true. When it's up hovering = false; And then you can calculate the speed of hovering by distance moved. This is a good example: For the keyboard: it's almost the same, when keydown you say that key is down, when it's up you do down = false for that key. Then if a key is down you can set the speed in the direction of that key, and even an acceleration while it's still down. There is no example of this so here you go: window.addEventListener('keydown', onKeyDown, false);window.addEventListener('keyup', onKeyUp, false);When you have the movement speed. Move your "camera" with the speed. With no clipping that would be having all inside one container and moving that container, with clipping it's a different story. Now your biggest problem is the logic part, knowing if something is inside or outside of screen and moving 1 million circles at real time. I put them together because... well, they are pretty tight together. You clip a circle if it's outside and it moves outside when it moves. The obvious way is to look all circles and if they are outside your boundaries hide their image (image.visible = false;). But of course you need to look all the 1m circles. function MoveCircle() { this.posX += this.speedX; this.posY += this.speedY; if(this.posX < lowerBoundaryX || this.posX > upperBoundaryX || this.posY < lowerBoundaryY || this.posY > upperBoundaryY) { if(this.image.visible) this.image.visible = false; } else { if(!this.image.visible) this.image.visible = true; }} A better but really more complex way is doing separation of your space. A grid is the most common one and simple one. One circle can be in one cell at a time, and the cell is bigger than the maximum circle. Then if a circle moves outside of you boundaries you clip it. The grid would be a 2 dimensional arrays, or an array that contains inside another array. Each cell would be an object (to contain different circles and properties). The code in circles remain almost the same, the real difference is that you update your circles based in the distances that they have to your camera. var gridWidth = 100;var gridHeight = 100;var maximumRadius = 20;var maximumSpeed = 40;var cellSize = 50;var currentTopLeftCell = {x: 0, y: 0};var currentBottomRighttCell = {x: 0, y: 0};var borderCellsThickness = 5; //Around your camera is a border made of cells, this represents how much cells you want that border to befunction Cell() { this.listOfCircles = []; this.framesToSkip = 0; this.framesSkiped = 0;}function GameLoop() { HandleInput(); MoveCamera(); for (var x = 0; x < gridWidth; x++) { for (var y = 0; y < gridHeight; y++) { var cell = grid[x][y]; if(cell.framesSkiped === cell.framesToSkip) { cell.framesSkiped = 0; var list = cell.listOfCircles; for (var i = 0; i < list.length; i++) { list[i].update(cell.framesSkiped); } } else { cell.framesSkiped++; } } }} The framesToSkip can be calculated inside the GameLoop or inside the panning / hovering function. It depends in what happens more often, if the camera is moved once in a while it's better to be in the panning function, if the camera is mover a lot it's better in the GameLoop (travel the grid only once). The code will be something like this: function UpdateCellsDistance() { for (var x = 0; x < gridWidth; x++) { for (var y = 0; y < gridHeight; y++) { var cell = grid[x][y]; var distanceX; if (x < currentTopLeftCell.x) { distanceX = (currentTopLeftCell.x - borderCellsThickness) - x; } else { distanceX = x - (currentBottomRightCell.x + borderCellsThickness); } if (distanceX < 0) distanceX = 0; var distanceY; if (y < currentTopLeftCell.y) { distanceY = (currentTopLeftCell.y - borderCellsThickness) - y; } else { distanceY = y - (currentBottomRightCell.y + borderCellsThickness); } if (distanceY < 0) distanceY = 0; var cellsDistance = Math.sqrt(distanceX * distanceX + distanceY * distanceY); cell.framesToSkip = Math.floor(cellsDistance * cellSize / maximumSpeed); } }} It calculate the distance of the current cell to the closest point of your camera, if it's inside the camera or it's borders there is no distance. Then it uses that distance to see how many frames it will take to a circle in that cell to arrive to the camera at maximum speed. That is how it's determined how often it should be updated, basically it's updated only if it could enter the camera boundaries. The code is a mess, is just to give you an idea. I don't even know if it works. There are a lot more optimizations that could be done, but I think that the update (and clipping) of circles was the main bottle neck. Good luck.
  17. That code has a little problem that may or may not influence in your game (beside that if your are using "use strict" it will fail). It's that the order in which balls are checked for collision matters. For example if you have a line of balls: 0 1 2 3 45 6 7 8 O-> OOOOOOOO If you check them in the same order that they are hitted, they will all move in one frame. (1 is hit so move to 2, 2 is hit so move to 3.......). But if it's checked in in the opposite each on will start to move one frame at a time. (8 was not hit, 7 was not hit....... 1 is hit so move to 2 ~ next frame: 8 was not hit.... 2 was hit so move to 3... ~ 7 frames later: 8 was hit so move) It also means that you can't collide with more that 1 ball per frame (because it will move you out of position). This could really make no difference at all in your game or it could make it feel a bit random, not always reacting at the same speed. Good luck with your game.
  18. Interesting. d13: For what I have read, your interpolation isn't correct. I may be wrong, but I think what you are supposed to interpolate is the position where it should theoretically be if it continue it's current trajectory. Of course it will be a guess and as you don't actually know if it stop or even collide with something. With your code it will be: o.renderX = o.x + o.vx * lagOffset; o.renderY = o.y + o.vy * lagOffset; //o.renderX = (o.x - o.oldX) * lagOffset + o.oldX; //o.renderY = (o.y - o.oldY) * lagOffset + o.oldY;Here is the clone of your prototype. To me the output look exactly the same (but to be honest, even without the offset it looks the same to me). Your loop looks perfect to me. alex_h: The problem with set interval is that it's fixed and that it doesn't care if you are doing something at that time, it will stack the new call. Also the time step is not constant, the call to the function is constant but in reality it changes according to different delays. Let's say you game couldn't run at 30 fps, it run at 28 which is not that of a big deal. At 33 milliseconds the first function is called, it takes 36 ms to finish running. The next update should be at 66 ms, but because your update took more time, it's run at 69. Set interval will try to call the update again at 99 and not 33 ms after the last one finished. And repeat again and again. 0 33 66 69 99 105 |Start| | update || update | Eventually you will end with a lot of callbacks that you aren't able to process because you didn't finish the last one. This will empty batteries, fill the memory and slow down your code even more. One possible solution would be to use setTimeout with the difference of the remaining times, or if there isn't any, at least don't stack the calls. Pixi uses setTimeout as a fall back if RAF doesn't exist. But it's far from optimal, for example the times aren't usually respected. And a last thing, you are rendering in vain. If your don't offset anything, you are rendering 2 times the same frame (if your RAF is 60 FPS and your update 30 FPS as it seams in the example). The idea of rendering more than updating is that rendering contains a little bit of logic, just enough to make another frame and make it look smooth. Like for example extrapolating positions, or advancing bone animations. EDIT: OH! btw d13, when you change your tab the RAF isn't call and that mean you can accumulate a LOT of lag that isn't really lag. I recommend doing something like Phaser, a maximum possible lag: if (elapsed > 1000) elapsed = frameDuration;I used 1 second because RAF has a minimum call of 1 FPS. Here is the full code.
  19. Don't paste all your code like that, it's really painful to read. Use something like, or Or at least, use the code tags. function squareBump(x1, y1, w1, h1, x2, y2)// RECTANGLE COLLISION{ //x1, y1 = x and y coordinates of object 1 //w1, h1 = width and height of object 1 //x2, y2 = x and y coordinates of object 2 (usually mid point. Use regX and regY) if ((x1 <= x2 && x1+w1 >= x2) && (y1 <= y2 && y1+h1 >= y2)) {return true;}}//(a very nice little collision function by the way, use in any framework)My eyes would really appreciate it.
  20. If you can't decide where to start, the worst that you can do is procrastinate. You can pick up something and make your game with it, if you don't like it when you finish your game you can change your tool, but you will have a finished game. That doesn't work for me, but works for a lot of people. Other thing you can do, is make small experimental games in different platforms, like a breakout clone. And that way you will know a lot faster what you like, but you won't have any finished game. I recommend trying this: Construct 2. Will give you a pretty good senses of how to think in order to make a game. Unity 3D. A lot of people seems to really love it and say it's really easy and fast. I can't understand why, but different people, different ways. Phaser. Contains all the tools to make your games but no longer holds your hand. Pixi. Total freedom, total responsibility. The common wisdom say start small, here you have an example of a really really simple mmo and as you can see its a LOT of work. Making games is pretty easy, making good games is hard work. Games are a lot more than the sum of its parts. In a game everything come together to form a specific aesthetic and a experience for a living human being behind the screen. And even then, probably different persons will have different experiences.
  21. There is no best way. It really depends on a lot of factors, like the group you work with, your experience and even your tastes. One of the important things is: why do you want to make games? For example, if you just want to create a specific game that you have in mind, Construct 2 will probably be a good ally. If you want to learn about the technology, and how games are made, you will be better reading some books. If you want to make money with games, you will probably be better with an engine. And so on, and on. To make you a recommendation, we will need more information in what your goal is. But anyway, some of the options are (but are not limited to): -The pure theoretical. If you have more a curiosity approach, you could probably be happy reading some tutorials on the web. -The game of my dreams approach. In this case you don't care about technical things, you just want to make the game. For this I will recommend Construct 2. I ran out of imagination for approaches. -You can use javascript and create everything from scratch. Really good if you want to learn how all the things works and how everything is done. Pretty suicidal if you just want to make games, you will be reinventing the wheel time and time again. -You can use a framework. That means there a lot of tools already made for you that you can use. But at the same time there isn't any methodology that you must use, you can do it the way you like. -Yo can use an engine. Not only lots of tools, but the interconnection of the tool are already done and there is a way to solve things that is already created. If the way fits with your needs and feels comfortable it will be all you need.
  22. I don't think that trying to make money with a premium version will be a good idea. Commonly the force around the opensource is greater than the force of the private parts. So basically you will spend a month (for example) to create a premium feature, only to have it available in the free version in one week. You can't really compete, not in power, nor features, nor ideas. The amount of people just make it impossible. The way I have seen this implemented is by giving services, like cloud hosting, remote compiling (so you can make an ios app from windows for example), and the likes. But it's more common to not make any money out of an opensource product, the benefit is usually improving the tool that you use to create your own games.
  23. 3) Now that you mention it... the app store is a centralized place where to find everything. On the other side, for the new web "apps", there isn't really a place to search for them, you need to search the internet for it. Maybe in the future there will be a centralized webpage (like some sort of html5 store), but for now it's really cumbersome for the end user to find them. Probably some game portals will improve their visits, but that will be all. 4) This is a matter of time, it will be hacked, sooner than later. Probably not with apple api, probably using something like google wallet. But people are pretty amazing, and I wont be surprise to see an html5 implementation of apples api. joannesalfa: You can sell to sponsors, and don't give a s**t about iaps. With this I mean, there are ways, and as time goes by, there will be more and better ways. 5) I personally don't think this is a real issue. WebGL pretty much gives all the (rendering) performance than a 2D game could need. In my opinion, Metal will have amazing results but for 3D. And taking into account that most popular mobile games are 2D, I don't think it will have that much impact. If we are talking about processing performance, 100% agree. When your screen is full of sprites and particles, there isn't much more that you can render, 2D isn't photo realistic so there is an effective limit on how much rendering performance is useful. But you can never have too much processing performance, there is always things to wast the cpu with.
  24. Strange. I always thought that apple will never want to give away it's control over apps. If they give green light to html5, a lot of apps will be outside of the app store, running in the browser. Maybe you won't have access to lots of things of the phone, but your don't need them. You can make saves and manage profiles on the cloud, and use mails as notifications. I don't really understand it. Can somebody explain why they do it?
  25. Perfect sense. I started drooling while I was reading. MightyEditor doesn't have any of those features, but hey... you need to start somewhere. Shmikucism, how about making it open source so we can all contribute to it and make it really mighty?