Over the past two weeks I've been messing around with ICE
- which is fantastic to work with! At first I made a simple game engine and it turned out pretty good. On that engine I've been making agario. Including simple AI for the enemies, making sure not to cause too much stress.
The player (you) always stays central on the screen. You can move by using the arrow keys. Splitting will be with 2nd. Eat smaller blobs to grow
The AI of the enemies works as follows: First priority is to flee from nearby bigger enemies. If there aren't any, second priority is to chase nearby smaller enemies. However stop doing this after 30 ticks. Smaller blobs are faster anyways. If those checks all fail, go to the nearest food pellet.
At the moment I feel the AI of the enemies is already pretty good to be challenging.
Source code: http://www.mediafire.com/file/xnqff537495fy78/AGARSRC.8xp
Compiled game: http://www.mediafire.com/file/sjiiv3f6qsslx48/AGARIO.8xp
- Splitting! This will be the most difficult part to implement. Especially without any floats
- Starting menu, highscore
- Optimizing as much as possible
Wow, I tried out the game and what you have it pretty cool! It's surprisingly stable, and the AI are reasonably difficult! The FPS is decent however, I think with some optimizations it could be a little better. The map seems kind of small, especially when you get to a huge size any plans to make it bigger? Speaking of being a huge size, is there a point in the game where you win? I got to a size of over 10,000 (which broke your score system, it started to display weird characters instead of numbers) and I think I was the size of the entire map, it was impossible for me to shrink or die. Also related to size, my blob was so big it took up the entire screen, will you have a zoom out feature? Final question, do you plan to add multiplayer support even if you have to use a BASIC routine to get and send the information?
I think ICE 3.0 is adding some sort of float support. You should check out the ICE thread for more info on what PT_ has in store.
Overall, great game port! I enjoyed playing it!
I'm glad you like it!
The reason the map is small (600x600 px atm) is to reduce lag. I noticed doubling the amount of food pellets significantly lowered the fps making it unplayable. I have no idea how ICE compiles but to me it seems distance checking / collision checks are the most stressful and those increase quadratically when adding enemies or food pellets.
You have a valid point about getting too large than the screen. First of I should limit the radius and display a message when covering the screen. Zooming out would be the best way to solve this but this would require floats and also require the world to be bigger. Thus a lot of optimization needs to be done.
Multiplayer has indeed passed through my mind and as long as sending and getting data won't be too costly, it shouldn't be that difficult.
This is really cool! The AI works perfectly and the game entertained me for a little while
The only downside I see is that I got so big I couldn't see anything else, so a zoom out feature would be nice.
This is looking good! I think for the movement mechanics, it is going to be hard to work around the lack of a mouse, but I think if you made it more pacman-esque then it would be easier (i.e. you keep moving in the last direction that you pressed so that you don't have to constantly hold down keys). And it has been said before by others, but zooming out is a must, as well as score correction, because currently my score is q113 and I don't really know what that means. Not that it matters, because for the last hour my calculator has just been sitting here accumulating points as it absorbs the bodies of the AI's that spawn inside of it.
I am sure that these flaws will be addressed, great work so far!
Oooh, this is really nice
As already stated by others, some zooming feature would be cool. I see a bunch of optimizations in your source code, but feel free to finish this game before optimizations
Also, I don't think multiplayer will be a thing; no idea how fast Get( and Send( are but it will definitely drop the speed a *lot*. You need to wait for USB support (poke jacobly
This is looking good! I think for the movement mechanics, it is going to be hard to work around the lack of a mouse but I think if you made it more pacman-esque then it would be easier (i.e. you keep moving in the last direction that you pressed so that you don't have to constantly hold down keys).
This imposes the limit of the four directions of the arrow keys (or at most eight directions if using combinations of keys). I have some time ago created a proof of concept program in TI-Basic which would wait for a swipe on the keyboard and approximate a vector in direction of the swipe. There should be possible to extend this concept to real time Assembly code, as it was rather fast even on TI-83+ Basic. The advantage being that you have virtually no limit of direction.
The main issue I see is that the TI-Basic code relied on the intuitive getKey layout, which is different in Assembly. But I guess there is a way around that too, some sort of lookup table would be fast enough I think.
I see a bunch of optimizations in your source code
Please tell me as you're probably the best person to know where to optimize ICE code.
but I think if you made it more pacman-esque then it would be easier (i.e. you keep moving in the last direction that you pressed so that you don't have to constantly hold down keys)
I've specifically made the decision of having 8 possible directions as it makes a good balance between having enough options and keeping it playable. You need to be able to quickly change the direction you're going in. Keeping the movement is definitely a good point. However this may be a bit difficult as you also want to keep going diagonally if one of the two keys was released a few ticks after the other. i.e. I'd need a counter for each of the 4 keys. Not totally impossible though.
zooming out is a must
I see if I find a hack to implement this without floats as I have no idea how long it will take for ICE v3.0 to be finished
Faster movement could help, or I just suck at agario in general... Probably the latter though
This is very cool. I just have to ask. Are you planning on continuing this project? This has me really excited and I was just wondering as I have not see any progress updates of any sort. Another almost stupid question, are you planning on adding cool new features like allowing players to upload their own skins and allowing them to customise the background colors? This would be really neat. Otherwise, keep up the great work!
I have some time ago created a proof of concept program in TI-Basic which would wait for a swipe on the keyboard and approximate a vector in direction of the swipe. There should be possible to extend this concept to real time Assembly code, as it was rather fast even on TI-83+ Basic. The advantage being that you have virtually no limit of direction.
Reminds me of: https://www.ticalc.org/archives/files/fileinfo/450/45003.html
I think ICE 3.0 is adding some sort of float support.
y'all need to learn how to used fixed decimals instead of relying on floating decimals.
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
» Go to Registration page
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum