pixel animals and characters
0 comments
I don't like scratch its basicly same thing as coding but in blocks, plus I suck at coding, and I want to try somthing new instead
I need help, like how hamumu.com made his games like dr lunatic supreme with cheese it has game maker without need for code.
you can also find his game on itcho
I'm working on "LINE stickers"
presence is precious
bird hanging sweing
.JPG)
brooches
hello
this is a kind of test post.
nice to meet you.
I work in Pico Pico Cafe in Kichijoji/ Tokyo and post some pictures of things I work on.
ocojo :)
| Pico8 use 2 functions to update stuff at a regular basis. One _update() function called every 1/30s (or 1/60s since the 0.1.8 version) and one _draw() function that do the same thing. |
That allow, for a project use that use the second as a time unit, to not slow down that unit.
From manual: _draw() is normally called at 30fps, but if it can not complete in time, PICO-8 will attempt to run at 15ps and call _update() twice per visible frame to compensate.
e.g., If I decide to make a sprite move from A to B in exactly 1 second but have a render process slower than 1/30s. I can put the move process in the _update function and the rendering in the _draw() function. The animation will not be smooth but the sprite will move from A to B in exactly 1 second.
This is true if the _update() function do not take more than 1/30s to execute.
This simple separation is only used for that purpose.
For my shmup project (bullet hell/danmaku) project, it's different.
The collisions are not physically computed because it will be too slow. It's a very simple collision system that use pixel color. At each frame, if a bullet is draw on the player ship, a collision will be produced.
Using a pixel-based collision system as a caveat: If a bullet move down at 3 pixel speed and the ship move up at 2 pixel speed. They can cross each other without generate collision. Why it is like it? Because the main purpose of a my shump is not about dodging a single bullets but a wall of hundreds. It will happen for a player to cross over a bullet without touching it but he will probably hit the following one. So it's ok.
That explained, It will be unfair to compute the collision and the rendering at two different speed using the two available functions _update() and _draw(), because player ship would collide with bullets that as not be rendered. To avoid that, everything related to the gameplay is in the _draw() function, collision and rendering.
What it change? It did not produce a time-based game but a frame-based game.
This is my first post here, so greetings everyone! 😀
But i was curious how to code in collisions
like bumping into walls and enemies.
And creating boundaries for my levels.
Thanks everyone 😊
I wanna collab with other people. Who wants to collab?
Porting a classic C64 game over to Pico-8. This has been a fun project so far.
Though I barely even have a game, the very basic core elements are there.
Still have to program in all the mini-games, and work on that god-awful layout I have on screen right now.
Is that broken for anybody else?
Hello everybody! I normally use Gamemaker Studio but my graphics card crapped out on me and I only have a Linux laptop as a backup which Gamemaker Studio doesn't run on. Fortunately, Pico-8 does run on Linux! I've owned Pico-8 for a while but never really used it so I figured this was a better time than any and I'm pretty glad I did now. This program has really made me appreciate the Lua programming language. It's super simple to use and learn. Over the past few days I put together a simple starter project that lets you not worry about the boring stuff and just jump straight into making your game. The only thing I didn't write myself is the insert function which is edited from Adam Scott's "Missing Built-ins" extension.
Features:
-Sprite animations
-Sprite origins
-Automatic depth sorting
-Mouse support
Plans:
-Integrate map editor
-Collision system
-more to come? we'll see.
I tried to add a cart to this test so you could check it out but it only works when I first upload and preview it. Once I hit submit, something goes wrong and it fails to load the cart. If anybody could help me understand why, I would appreciate it.
I made a github page to see the demo without any mouse issues.
Overview
So the other day I delved deep into trig to pull out the bare minimum of what makes things move in circles.
The problem I've had in the past is that I often looked at games or demos that incorporated a lot more things, so I often would make incorrect assumptions about how to implement these types of things. My hope with this tutorial is to just show you the absolute bare minimum of what you need to get a sprite moving in a counter-clockwise circle, and explain everything line by line as best I can.
Here is what we are making:
To make something move in a circle, we have to use trigonometry. This tutorial is going to explain the trig functions we'll be using so that you can hopefully use them on your own without copy and pasting.
Prerequisites
To get the most out of this tutorial, you just need pico8 installed.
The gist
A sprite moving in a counterclockwise circle
radius = 30 originx = 64 originy = 64 angle = 0 while(true) do angle += 5 if (angle > 360) angle = 0 cls() x=originx + radius * cos(angle/360) y=originy + radius * sin(angle/360) spr(0, x, y) flip() end |
Rendering with pico8
NOTE: Skip this section if you want to get right to the trig! Just go to "Show me the trig!"
The thing I love about pico8 is that it doesn't get in your way! I can throw up an app that says draws a dot in the center of the screen its easy
Should you run the following script, you will see a dot in the middle of the screen
while(true) do cls() pset(64, 64) flip() end |
You don't need to use the update/draw/init functions that are available (and recommended, but not for this demo)
The computer is simply running cls() to clear the screen, pset() to draw the dot, and flip() to render it to the screen, and then it repeats those three commands indefinitely.
In game development, this can be called the "game loop" - because you have to update the game state and render it every frame. Often times you clear the screen first or you will combine the previous frame with the next one, which could be an unintended result.
Show me the trig!
I'll do more than show :) I'll do my best to explain how this works, but I'm not an expert so if I get something wrong or gloss over something critical please post a comment so I can update this.
Why Trig?
Before trig, if we wanted to figure out the x and y coordinates of something but all we had was its length, and angle, it would take a lot of steps to figure them out. Thankfully we don't have to do that anymore!
You might be wondering why we have to figure out x and y coordinates by length and angle. Our problem is really the fact that we have to find the x and y coordinates of something moving in a circle. Thinking about lengths and angles might not make sense at first, so let me help demistify this if I can.
Breaking our problem down
Inorder for us to move around in a circle, we need to establish a few things, can you think of some? You might want to pause before reading on, but if you want to go ahead :)
First we need to know the path our thing is traveling on. Since we know it is moving around in a circle, we can deduce that it will be traveling along the radius of the circle. Since it is traveling along a radius of a circle, then we need to decide how big our circle is.
Since the radius is how big the circle is from its center, we also have our length.
RADIUS=30 |
Second, if we want to have an idea of where it will be on the circle, we also need to decide where our circle will be. We can do this by assigning values to the origin of our circle, or the center of our circle.
I personally wanted my circle to be in the middle of the screen, and since the screen is 128x128 pixels in size, I'll just use half of that as my origin:
ORIGINX=64 ORIGINY=64 |
Last, inorder to plot where on my circle my thing will be, I need to know the angle. Since I just want something to go around in a circle over and over again, and angles go from 0 to 360 degrees, then we can just use zero and increment the angle over time to make it move:
ANGLE=0 |
Assuming we use the while(true) loop and want to move around on a circle, our script looks like this:
radius = 30 originx = 64 originy = 64 angle = 0 while(true) do angle += 5 if (angle > 360) angle = 0 cls() x=???????? y=???????? spr(0, x, y) flip() end |
The angle is incremented by 5 and reset to zero everytime we go over 360, so our thing will move. We use the spr function before flip to draw our sprite to the buffer. So the only thing missing is our x and y coordinates.
Here we basically have POLAR COORDINATES. We know the length, and the angle. The length is 30, the angle is constantly moving up then resetting.
Trig can be used to solve the following problems:
1. "I have the length and the angle, but I dont know the x and y coordinates"
This is the problem we are solving today :)
2. "I have the x and y coordinates, but I dont know the angle"
3. "I have the the length and the x and y coordinates, but I dont know the angle"
Get them X and Y Coordinates!
We use our friends SINE and COSINE. (and completely different than any other language LOL)
If you want to know how these really work, pico8 is not the best place. The reason is pico8 doesnt use them the same as you would use them in trig or in other languages. The good news is pico8 simplifies them, the bad is if you learn how to do this in pico8 and move on to another engine or programming language you will get a little confused.
If you are new to trigonometry check this out: https://www.raywenderlich.com/35866/trigonometry-for-game-programming-part-1
If you have experience using trig but dont really understand it, and also have a lot of programming experience or have a solid understanding of programming check out this article: http://www.helixsoft.nl/articles/circle/sincos.htm
If you read the second article, you might have a better understanding of why pico8 is different - you will also know how to draw circles without using trig as well. I strongly recommend reading both. I found the first article more helpful in understanding the basics of using trig, but only the first chapter. The second article was really good in understanding how cos and sin work.
In Pico8, sine and cosine work differently. You dont need to know PI or even RADIANS. Instead, you just need to know the angle in percent, meaning 100% or 1 is 360 degrees, and 0% or 0 is zero degrees.
x=originx + radius * cos(angle/360) y=originy + radius * sin(angle/360) |
Instead of using ANGLE, you can also just go from 0 to 1 (then reset at 0 when it goes over 1)
radius = 30 originx = 64 originy = 64 angle_percent = 0 while(true) do angle_percent += 0.03 if (angle_percent > 1.00) angle_percent = 0 cls() x=originx + radius * cos(angle_percent) y=originy + radius * sin(angle_percent) spr(0, x, y) flip() end |
That sums this tutorial up. I wanted to explain more about trig and triangles, but I would rather you read the articles I mentioned above. In programming you dont need to have a deep understanding of trig, you just need to know how to use practice trig. In order to practice trig though, you should be able to figure out how to solve problems using trig without copy pasting code. To do that, you're going to need to learn some trig, but most importantly learn how to solve problems using it, know how to use sine and cosine, and know what problems trig solves and what problems it doesnt. To do that, we need to practice it.
I hope this helped someone :) feel free to comment / critique / ask questions.
Being a fan of 8bit and 16bit graphical adventure games from back in the day, I've set off on the mission to create one on the Pico. With the understanding on the size limitations of the Pico-8, I'm building a game engine that is utilizing as many reusable components as possible. I'm documenting my efforts on my blog at: http://whiteoutlabs.com/game-development/pico-8-sprite-animation-basics/
Alright. I'm finally getting somewhere with my level code, physics, and... well, I'm still WORKING on my composition stuff, too. But now I'm also starting to work on enemy AI. And here's another spot I'm kind of fresh to.
See, past projects I've worked on include fighting games - which are essentially just really big FSMs, and the AI uses some conditions like player distance or input to determine appropriate responses (some MegaMan bosses do this, too)... and music games, which is really just about lining up targets with precise timing and that's really all there is to it. Making shots doesn't seem any different than making fireballs in SF, either. But making enemy AI for platformer and top-down-adventure games is kind of a different thing; and I could use some guidance - heck, maybe even outright collaboration with.
There's four titles of enemies I'm trying to reasonably replicate here:
200X - a MegaMan knockoff.
Concert of the Damned - something between Zelda II and SotN, maybe a little Shovel Knighty too.
Gentroid - Yet Another Metroid Fangame (there's a good grip of these, it seems - and Cow has the physics/feel to that DOWN! Perhaps I should just step aside...)
...and an as-of-yet-to-be-determined title that's in line with Zelda 1 and/or Gauntlet; maybe a bit Isaacy, but certainly not Isaac. Save for maybe boss influence, we'll see where that goes.
How do some of you do your enemy AI? I know really simple stuff could be handled by my "MakeTarget()" code, but not stuff that depends on terrain contact. "MakeTarget()" is mainly about making basic movement patterns - lateral, vertical, sine-waved values, diagonals, circles or semicircles, that kind of thing.
function maketarget(obj,scr,x,y,xrange or 0,yrange or 0,speed or 0,loop or 0) --x/y position relative to map obj.p.x=((scr\5)*16+x) obj.p.y=((scr/5)*16+y) --set sine motions to control local movex=2*sqrt(xrange)*speed local movey=2*sqrt(yrange)*speed --reverse direction! if (movex=xrange or movex=-xrange or xrange<0) movex*=-1 if (movey=yrange or movey=-yrange or yrange<0) movey*=-1 --diagonals or curves if loop=1 then movex=xrange elseif loop=-1 then movex-=xrange end |
So... I guess what I'm aiming for is a back-calculating method for controlling player movement, via globals. So, let's say I'm wanting a typical jump-to-same-level duration to be 90 frames; and for it to go up 3.5 "tiles" of 8 pixels apiece; with a 0.8x accel/decel rate (gravrate). I define the jumpheight as 28 (pixels) and the jumptime as 45 (ground-to-apex; so half of 90), and then use that to calculate jumpvelocity.
My usual go-to is jumpvel=2sqrt(gravity tiles * gravrate), and then letting the typical gravity accel/decel take over from there. "gravity" is seperate from gravrate, in case I want to disable it (by making it 0) reverse it (by making it -1), or reducing it (making it a decimal, usually between 0.5 and 1).
Also, working on a similar accel/decel for horizontal walk/runspeed... so let's say I'm aiming at 0.3 px/frame to be the max speed (18 pixels a second, or a little over 2 tiles, so you can jump four across, level-to-level)... I still want a 20-frame accel and 10-frame decel delta to that, to give some fluidity to the player's motion, it's not all "everything or nothing." So the actual velocity is like "0.3 - (0.015 * runframes, if less than 20)" and then at release, setting that value to 20 and reducing it 2 at a time so that the calculation still affects the movement speed.
...
I think I'm losing my mind though, so am I still doing this right? >.>
I'm increasingly forgetting stuff, and when I'm working and calculating, it's interfering with my work - and THEN when I'm off, I'm no longer calculating, and everything's kind of getting messy. Dammit!!
A heads up for Voxatron users -- the first version of the Lua api will be out next week in 0.3.5!
Pictured above is the result of drawing voxels directly into a room's map. The 0.3.5 api also provides access to actor attributes and state, spawning, camera control, and direct access to the display. The entire PICO-8 api is in there with some 3D counterparts (line3d, box, sphere), and it's possible to import a pico-8 cart into the resource tree, place it in a room, and run the cart on a single slice of the display. The .p8 cart shows up in the resource navigator, and is placeable in the room like this:
The code can also be edited to make slight adjustments for the 3d display:
In other news, I've updated the website with mobile-friendly cart listings and touch controls for the carts. It's still a work in progress -- the sound in particular is very choppy or missing altogether. But apart from that it is quite useable. If you have a modern phone or touch device please try it out!
I'm so excited about the new Pocket C.H.I.P. where I will be creating games on. That's why I just created my account.
PRE-ORDER CONFIRMED! Thanks for your pre-order! It’s confirmed in our system and estimated to ship this November . Look for another email from us to confirm your shipping address closer to your estimated ship date. Date 11/12/2016 |
And that's it. I wish all of you an awesome weekend.
