Lately Ivoah and I have been collaborating on a new project in lua for nspire, a clone of the classic GBA strategy game: "Fire Emblem", the project name... "Nspire Emblem" (isn't that clever...)
Current Screenshot (graphics are temporary):
(http://s2.postimg.org/6k1w9sft5/Nspire_Emblem.png)
The plan is to have a semi-complete fire emblem game, with lots of items, characters and chapters, as well as a great story line. As of now, it displays the map and all of the units, and you can select units, and move them within a given range.
Stay tuned for more information, and comment if you have any ideas/suggestions!
Pretty cool sounding. I remember a planned fire emblem clone for the ti 83+/84+ but I didn't hear anything else about it. I hope yours gets done because it looks pretty pro. Good luck.
Edit. I like the title play on words.
Seems like a very ambitious project considering how big Fire Emblem games can get. I hope you can pull it off. It definitively looks good so far. How is the speed so far?
THat doesn't seem so bad. The hardest thing is chaining AI and events. THe rest should drop quite easily once you get rid of the hardest design knots. Good luck! ;)
Looks good! Though i'm not familliar with Fire Emblem...
Oh wow, that's pretty cool, need it
Quote from: CKH4 on April 14, 2015, 02:25:44 AM
Pretty cool sounding. I remember a planned fire emblem clone for the ti 83+/84+ but I didn't hear anything else about it. I hope yours gets done because it looks pretty pro. Good luck.
Edit. I like the title play on words.
Thanks :)
Quote from: DJ Omnimaga on April 14, 2015, 05:31:05 AM
Seems like a very ambitious project considering how big Fire Emblem games can get. I hope you can pull it off. It definitively looks good so far. How is the speed so far?
It is a rather ambitious project, but a lot of the engine is already complete, and I think with the two of us working on it, we will be able to finish ^.^ I don't think speed will be a problem considering we only need to refresh the screen about 2 times per second, as of now it runs perfectly fine!
Quote from: Duke "Tape" Eiyeron on April 14, 2015, 10:40:46 AM
THat doesn't seem so bad. The hardest thing is chaining AI and events. THe rest should drop quite easily once you get rid of the hardest design knots. Good luck! ;)
Thanks, I think that with the way movement is currently setup, a decent Ai won't be too difficult to do!
Quote from: Cumred_Snektron on April 14, 2015, 01:20:59 PM
Looks good! Though i'm not familliar with Fire Emblem...
Thanks, and you should change that! ;)
Quote from: jamesguessis on April 14, 2015, 03:54:48 PM
Oh wow, that's pretty cool, need it
Thanks!
So I assume that in Lua, the main speed problems are with graphic rendering and math is fine? If math is fine then hopefully you can have moderately complex AI with many units at a time without slowdowns :) (especially that you don't need to move every single unit every turn)
Quote from: DJ Omnimaga on April 15, 2015, 01:33:45 AM
So I assume that in Lua, the main speed problems are with graphic rendering and math is fine? If math is fine then hopefully you can have moderately complex AI with many units at a time without slowdowns :) (especially that you don't need to move every single unit every turn)
Yeah pretty much. Although the graphics aren't slowing it down very much, we just draw the map as a single pre-rendered background, and the troops shouldn't make a very big dent in the speed.
Do you pre-render the background on-calc from smaller tiles or do you have to create a 320x240 picture on the computer then store it as data in the code? The HP Prime can do both, but I don't remember about Lua. I hope you don't have to store massive images, since that can get quite large fast, although I am OK with the extra file size if the game is good :P (on the HP Prime it's the opposite: Graphics are ultra fast, but program control, especially For loops, and to a lesser extent math stuff are a serious speed drain).
Anyway I wish you good luck in this project to you and LD Studios. Hopefully it won't end up in LD Studio's defunct project list like the Medieval Platformer and Portal >.<
Quote from: DJ Omnimaga on April 15, 2015, 03:46:55 AM
Do you pre-render the background on-calc from smaller tiles or do you have to create a 320x240 picture on the computer then store it as data in the code? The HP Prime can do both, but I don't remember about Lua. I hope you don't have to store massive images, since that can get quite large fast, although I am OK with the extra file size if the game is good :P (on the HP Prime it's the opposite: Graphics are ultra fast, but program control, especially For loops, and to a lesser extent math stuff are a serious speed drain).
Anyway I wish you good luck in this project to you and LD Studios. Hopefully it won't end up in LD Studio's defunct project list like the Medieval Platformer and Portal >.<
We create the background on the computer and store it with the game. This shouldn't increase the game size too much if we have ~10-15 levels, plus, size isn't really a problem on then Nspire. Hopefully with two people working on it, motivation will never drop too low :)
Ah ok. Do you use compression for the background? Because 320x240 in 16 bits colors is 150 KB large, so if you have 50 levels, then the game would be over 7 MB large. Unless Nspire Lua uses a much smaller image format or lower color depth?
Yes, the way Nspire Lua stores image takes up much less space. We already have a pretty solid chunk of code, and one full screen image and the file is still under 35 KB. I think the full version shouldn't be more than a few MB.
Ooh that's better than I expected then.
Does they have a good compression system? That's nice of them. YOu could be able to put a lot more into the project! ;)
Quote from: Duke "Tape" Eiyeron on April 16, 2015, 07:19:40 AM
Does they have a good compression system? That's nice of them. YOu could be able to put a lot more into the project! ;)
I don't know much about their compression system, but memory isn't really a problem anyways on the Nspire.
It depends of the calculator model and OS I guess. On ClickPad/Touchpad models OS 3.9+Ndless combined leaves about 2-3 MB of Flash to the user, which is even less than the CSE. I guess just as long as the game doesn't take 50 MB alone then you should be fine. But I personally don't judge games solely based on file size if the size is justified so I'm gonna give this a try no matter how large it is, providing that my Nspire CX can run it.
By the way what is the minimum OS requirements for this Lua game? I know that many people decided to stick to OS 3.1 since it's smaller and they find Ndless less annoying to use on it, but by now most have switched to 3.6 or can't downgrade lower.
Quote from: DJ Omnimaga on April 18, 2015, 05:37:56 AM
It depends of the calculator model and OS I guess. On ClickPad/Touchpad models OS 3.9+Ndless combined leaves about 2-3 MB of Flash to the user, which is even less than the CSE. I guess just as long as the game doesn't take 50 MB alone then you should be fine. But I personally don't judge games solely based on file size if the size is justified so I'm gonna give this a try no matter how large it is, providing that my Nspire CX can run it.
By the way what is the minimum OS requirements for this Lua game? I know that many people decided to stick to OS 3.1 since it's smaller and they find Ndless less annoying to use on it, but by now most have switched to 3.6 or can't downgrade lower.
We use apilevel 1.0, so I think that works on 3.1. Also would this work on the B/W Nspires since it uses color?
Yeah, images before OS 3.6 are stored as a string rather than an actual image file, which is why they take up a lot less space. Starting with OS 3.6, images are implemented completely different and they take up a lot more space. We're using apilevel 1.0 which means smaller image sizes and available on every OS supporting lua (I think...). And yes ivoah, it should work on BW calcs, but it might not display well depending on the color contrast.
Yeah, on grayscale calcs the colors are just converted to grayscale. Also I am surprised that strings take less space considering on the TI-84+CSE xLIB sprites stored as strings inside TI-BASIC programs instead of appvars take twice as much space.
Do you think we should try and make it look good on grayscale calcs?
Considering that they're discontinued since 2011 and that most people are getting the CX now, I think you should focus on color calcs. I doubt it will look that bad on grayscale calcs anyway, plus people stuck to monochrome calcs for years before. Just make sure to not do stuff like middle green text on red background.
Mmh, some work could be done on monochrome sprites. They could be a good work on contrast and how to manage to have a black and a white team without losing details or visibility.
LD Studios: Think you could make custom sprites so we don't have to rip assets from FE?