Tiny Heroes *Twitches* Must be released *Twitches*
WHEN WILL IT COME,BYOND IS GETTING BORING )::
Chainblade1 wrote:
Tiny Heroes *Twitches* Must be released *Twitches* It is true. Not enough of us are picking up the pace. Those who know how to program end up playing other games, and reading about other people's progress. | |
Having a small issue. I'm using sidrescroller in a project and the world icon size is 32, the mob icons is 96^2. The mob is not large, but certain animations cause it to move a bit, so the icons being large is not an issue, I hope. The issue that I'm having is that, when the world starts, the camera is positioned at (-1,-1) in reference to the mob. I've got the bounding boxes working find and the collisions work perfectly. For some reason the camera is just offset. It's strange. It's not a huge issue, but it is pretty annoying >_>
| |
Hey forum, i didn't really know where else i could contact you, but i have come to ask for your help.
Im currently in the process of making a Mech, Pvp, Action, Strategy, Conquer type of game. I had some ideas i rattled them down i even managed to get some art work done, but that's where the dream stopped and i came against the programming side which alwyas gets me stumped, MY game is going to need pixel movement, shooting, mouse aiming and a Lot of Ai. and from whay i have heard... that means it's going to be a cpu killer. I don't know if you saw my post or the hub of how i plan to have the game. Hub link: http://www.byond.com/games/Teka123/MechaWar It's an all original mech game which i really want to do well with. I have just tried to go threw the dm guide for this, i have followed the first steps but i still cant grasp it and it's daunting to think about how much i will need to learn to be able to accomplish what i want. I would really appreciate it, but is there any chance you may be able to help me make this game a relaity and help me get this done. | |
If you use pixel movement you'll need a higher framerate. This is what drives CPU usage up so much. If a game would average 5% CPU usage at 10 frames per second, it'll automatically be 20% CPU usage at 40 fps. People consider 5% CPU usage to be insignificant, but 20% to be much more significant.
If you're going to have lots of projectiles and reasonably complex AI, you might want to plan to use a framerate in the 25-30 range. You can always increase the framerate later, but if you get used to seeing the game run at 40 fps you won't like how it looks when you drop it to 25 fps. Going from 25 fps to 35 fps will be a more pleasant change. The game sounds similar to Bravo1's Tanx, so the CPU usage might be high, but t'll be manageable. The BYOND staff is also working on built-in pixel movement. Hopefully it'll help to reduce CPU usage. As far as getting the game implemented goes, you can post questions on my forum. I can't code the game for you, but if you ask something along the lines of "how do I do _____ using the pixel movement library", I'd be glad to provide examples. | |
Yes it was only after playing Tanx that i really decided to create this game, i had previous ideas but seeing and playing Tanx which is a really good game gave me a bit of inspiration to fully write out my idea for this.
Thanks anyway, i had expected you to be too busy or unable to help me anyway, I've thrown my idea out there but it doesn't seem that too many people share my opinion about how good i think my game could be lol :) So why would you help me when it's just another game in your eyes, i understand :) I'll hopefully gain a programmer shortly, my skills really are incapable of the smallest things though i will continue to read the DM guide to see if i can improve a bit while having this made. Anyway thanks a lot!. :) | |
I hope to add more demos to the Pixel Movement library (it already comes with quite a few) so that you can make a basic game just with the sample features provided in the demos.
For instance, to make a mech game you'd need some basic things like: 1. A different movement scheme. There are some examples in the control-schemes\ folder in the library. 2. Projectiles. There's a simple example in the performance-demo\ demo. It'll take more than that, and it still takes some skill to piece it all together. But, with a little work and some more examples, my hope is that more people will be able to cobble games together. I obviously don't have the time to teach you DM, but if you want to know how to do something with the library, feel free to ask. There's nothing wrong with learning by example. Maybe there's something about DM that hasn't clicked for you yet, but will make sense when you see an example of using it to create a feature for the game. | |
Hey Forum_account, I'm using your Sidescroller library and I'm wondering on how to determine the minx, maxx, miny, and maxy values for the Camera. Thanks!
| |
Kenny84 wrote:
Hey Forum_account, I'm using your Sidescroller library and I'm wondering on how to determine the minx, maxx, miny, and maxy values for the Camera. Thanks! The values of those vars create a rectangle that the camera's px and py are restricted to (minx,miny being the bottom left corner, maxx,maxy being the top right corner). When the camera's px and py is the same as the player's px and py, the camera is centered on the player. So, if you want to find bounds make a verb that just outputs the player's px and py. Then run the game, position the player where you want the bottom left corner of the camera bounds to be, and click the verb. Do the same for the top-right corner of the region. Those numbers will be the minx, miny, maxx, and maxy. You can also create camera objects and place them inside areas in the map editor. Then, when the game is running, you can compute values for minx, miny, maxx, and maxy based on where those objects were placed. Check out this thread on my forum for more information. | |
Tee-Hee. Time to retire your pixel movement libraries. =)
| |
FFFFF- You're going away on vacation so now there's no easy way to convert from PM into the hardcoded version. Looks like Tanx will be in the shop for a while...
| |
Resonence wrote:
Tee-Hee. Time to retire your pixel movement libraries. =) I'm not sure how much overlap there is between the libraries and the new feature. It's less than 100% and probably will always be, which means there will always be something the libraries are giving you. Bravo, I too noticed the good timing. I'm not sure how easy the conversion will be. It should be simple but I won't be certain until I have the time to sit down and implement it. | |
I look forward to you coming back from vacation and hoping you have some time so that you can fiddle with the built in pixel movement and do a test to see whats better. yours or built in.. or built in + some mods by you.
Since its also still in beta i hope they come up with a stable release before you get back to :p | |
Midgetbuster wrote:
I look forward to you coming back from vacation and hoping you have some time so that you can fiddle with the built in pixel movement and do a test to see whats better. yours or built in.. or built in + some mods by you. I plan to make my libraries have two or three modes. One is the current version where the libraries handle everything (for now, the native feature doesn't provide everything). Another mode would use the native feature for the movement, but provide the same API as the library (the move proc, action proc, vel_x/y vars, etc.). This makes the demos that come with the libraries still be useful and automatically use the new feature (and allow you to easily switch to the default behavior if you need non-built-in features). | |
I'm your biggest fan. Derp.
| |
Yut Put wrote:
Tiny Heroes is #1 on my list of games to look forward to Maybe if he stops updating all his libraries we'll finally get to play it. >:( | |
SOMEBODY CALL THE WHAAAAA-MBLUANCE!
| |
EmpirezTeam wrote:
Yut Put wrote: These last updates were rather necessary. Though, I'm leaning towards not using built-in pixel movement for Tiny Heroes because of how it handles collisions for cases where one object tries to move when it's already inside another dense object. Tiny Heroes has always been an RPG and a platformer, but the exact split has varied. I always liked the idea of the 50-50 RPG/platformer split, but the RPG elements are what had slowed me down. I'm now leaning more towards a 20%/80% RPG/platformer split and its a lot easier to work on. My original estimate was to have something playable at the end of September, and I might not make that but I won't be far off. | |
There's an issues with the new pixel_movement update. It seems that whilst in native mode I run into massive lag spikes occasionally, and I have no clue as to what they originate from. I can only guess that it's an issue caused by the set_pos fix. IT seems to me that what you do with set_pos now is you locate the atom tot he designated turf and then adjust it's offset with step(). The only issue is that I use "particles" for the trail effects on missiles. This would end up causing a lot of lag for anyone creating and deleting multiple mobs just for visual effect like I'm doing here. Should I just use native and then append a pixel offset instead of calling set_pos? The trails are purely visual so manually setting their position is unnecessary. What do you think?
| |
Sounds neat! There's an example of vehicle movement that comes with the library but it works more like a car/tank than a spaceship. If you have any questions about using the library, don't hesitate to post on my forum.