Kibbelz

It says here that resources will be automatically updated too.

Holy dude, I don't even know how to respond to this. Considering my degree is computer science with electronics this fascinates me a lot. I look forward to seeing more! I'm curious, what profit do you think you make on average per console? (the ones you actually sell of course)

anytime man, I look forward to seeing more.

Yeah, I will be aiming to do daily development streams, check out the announcement here!

NpcVsNpc combat, Npc spells, Knockbacks and admin commands! July 29th 2016 News/Updates Quite some big features here with this update, Mostly regarding NPC combat. We thought about enabling developers to make their own combat scenes and make combat vs the NPC's a little more interesting. (And fair since now they can cast spells too!) A few other loose ends to be tied up with combat such as Knockbacks, which anyone with any experience playing games like The Legend of Zelda, knows is a super cool feature of combat! Finally we have the extended admin commands with an updated admin panel client side! NpcVsNpc Combat Npc's can be enabled to be able to attack other NPC's! An aggression list has been added to the NPC editor, adding other NPC's to this list results in the NPC attacking them on sight within range! NPC's can also be set to attack all npc's! If a spell hits another NPC by accident and they do not already have a target, they will attack the NPC that cast the spell. Npc casting spells NPC's can now cast a dynamic number of spells, a random spell is selected at a frequency chosen unique to each NPC! NPC's can cast AOE, Single target, self target, projectiles and dash spells! Check here for more information on the different spell types! Admin commands Until now admin commands have been very lacking, this update we decided to add all the admin commands you should need to help manage your community in game! Server commands have been updated, showing the list of commands now available! We also now have an up to date admin menu too! Whats next? Make sure to check out the Intersect Road Map as for what features we have next planned in line! As always, feel free to post comments and questions below! We are excited to hear your thoughts on our progress! I will be continuing to stream Intersect development and myself and JC will be willing to take suggestions, answer questions and keep you up to date live!

0. Bye Bye

I like it but i'm unsure of how the desert represents summer. I like the tile sets though, a lot of variety!

I forgot to announce this but the cliff autotile is fixed for 1.6

assuming riot doesn't go down the route of building full tank = more dmg than everyone else in the game *cough* juggernauts *cough* he SHOULD (tm) be fairly balanced. (Assuming he has to actually build full dmg to be a relevant dmg source).

hey hey hey! @yeroC?

Good updates, do you have a website yet?

@Gibier the cliff autotile is 100% bugged. I'll fix it for next patch.

I can fix the cliff autotiles when i get home. They're pretty bugged right now

@WereAlpaca Firstly, I'd like to state you described my point very well. I myself am not the best when it comes to explaining but you sir I take my hat off to you. Now, I hope I can help explain to the best of my abilities. Using these 2 images: The lines represent a 32x32 tile. Imagine the red rectangle representing the 32x48 sprite you have facing in the right direction. The way how all graphics are handled are for the base of the sprite to be centred around the tile that the entity is positioned on. Hence why the top 16 tiles of your 32x48 sprite aka the hairline will be rendered on the tile above. The blue square represents a 64x64 animation being fired right of the player as a projectile. The green square actually represents the middle of this animation and in this example, the actual animation you care about. The blue edges represent the redundant white space bordering the animation, as you can see its essentially buffering the animation into another spawning position and even overlapping with the player's graphic. There are three solutions, either remove the excess "white space buffer" on the animation graphic, change the spawn location in the projectiles editor or introduce an offset when source is released. Here is another image without the white spacing buffer in the animation file. You can see how its spawn position in pixels changes. I hope this explains it for you as a more visual approach. My wording may be off so someone may have to hop in to help explain. -Kibbelz

Sup Emil, Memes are always welcome here! However please refrain from dieing whilst you're with us at AGD!

A good tutorial. A nice clean read, hopefully it will help some people!

There are only so many bugs someone can fix which is why we have you guys to find them so we can squash them! @PhenomenalDev There is a limit to what you can do without creating graphical reliance. What that means is, lets say we have a Zelda spin attack. You need the animation frames for the whole attack, even the character frames as well as the paperdoll/animations. Adding the ability to create such spells with no free to use graphics with enough resources to make a good game limits an extreme amount of people on this forum. Assuming you have no pixel talent, that would also include you. So now we have an engine that only ~1/100 users here at AGD (since we have barely any artists) can actually make something with, that is a terrible design flaw. If you're not satisfied with how combat works in Intersect, I suggest you go make your game in Eclipse or Orion+. Either that or release your own source tutorials of how you know combat should be done. @WereAlpaca This is probably because the animations you're using have a lot of "white space" between frames which can cause offsets. The animations are programmed to be in the centre of the tile, not the character. if the character is 64 pixels high and the projectile shoots out in a line in front of it, it will shoot out from the bottom of the character. This is because in an ideal world everyone would be using 32x32 sprites, of course thats never the case. Also depending on what animations you use and what sprites you use the positions of projectile to character will vary, By adding offsets in pixels in the source it will put the projectile in the right place! As stated many times before, we can't accommodate all graphic types which is the danger of advanced combat with more diverse graphics!

To all those people getting hit by cars while playing pokemon go:

I really like it, looks really cool!

No problem, best of luck fixing your camera bug.

in the 2nd part of your video you got it working.

Look how he clicks in the top left of an autotile and the tile type combo box is set to Autotile

Click on the top left tile of an auto tile and select an autotile from the combo box above. Right now you're on "normal" aka single tile.

Here is the pseudo code explaining how to set up the keyboard input handler for tile based movement: if Arrow key pressed then if not already moving then destination = calculation of current position + direction if destination is not blocked then player location = destination player moving = true if direction = up then YOffset = -tileheight / 2 if direction = down then YOffset = tileheight / 2 if direction = left then XOffset = -tilewidth / 2 if direction = right then XOffset = tilewidth / 2 All you then have to do is update the YOffset and XOffset over time based on the time it takes the player to walk the tile width / 2 pixels. When both offsets are 0 you've stopped moving and can set player moving to false. When drawing the character on the screen, make sure to add these pixel offsets to the player. I'm not the best at explaining things in English but I hope the pseudo code I gave you should be sufficient. Any queries feel free to ask.