Hello everyone. I won't introduce again this project I have. Yes? You still want? Okay.
My projects are most of the time remakes or reproducing mechanisms of games I loved. I started programming (on calcs and on Casio) by trying to port Pokémon Gen I battle engine To Casio AFX2.0/Graph100+. I got through some projects in the same branch, but another one (almost finished) stood up : Bust-a-Move. All of them are past. Now, I'd like to program something. A project way more complicated but that could open (at least to me) to new games. I'd like to reproduce for starters the battle engine of Mother 3 and Earthbound.
This battle engine is a semi turn based classic RPG battle engine. You ahve your party, the enemy's. each one decide its actions for the turn and the turn is going on its way. THat could be just a simple project, but here's the tweak in three(four if you count & as one) words : Modularity & Open Source.
Modularity
Modularity means that the engine should be an independant part of bigger projects. Only some functions will be needed to set up the engine and run it. I'm still planning a lot of the structure and having many design difficulties (shmibs will talk of exeprience after reading the first version's C code...) but I want it to be most clear possible to be hackable by everyone who has some good C/Axe programming skills.
Modularity means too OCP (Open/Closes Principe). I' like it to support a event system and scripted IA which could add a deeper experience to the battles. I'd like at least to be able to reproduce all the quirky events of said games (like self-exploding trees at their death, the textbox in [REDACTED]'s battle, etc...) but that's not really a critical feature.
In the end, modularity means grouping the code in modules to be able to swap them. The most important instances of this meaning here are graphism and I/O (and audio? I dreamt of a thing months ago, but that's still a dream T_T). Graphism and I/O code should be engine independant. I'd like to run the engine on computer as well as calculators. For that, lots of think are being spent on how to split the graphic data from the engine's. that's not an easy task, i.e. Casio FX-9860 are using 2-bits sprites where Black are 1 and 0 White. If someone were to use directly these functions in, lets' say SDL, that won't certainly work unless big ugly hacks are done. So graphism should too be a independant part to be free of using whatever is needed by the target. Same for file I/O or input management. That also brings a problem : where to put the UI? Graphism module? Input Module? Battle Engine?
Open Source.
Before talking about open source, there should at least be source code. The project started on calc with Axe Parser as I only had that at my hand. The code became quickly as unreadable as ancient dwarf arcanes. Forget about reading it, it has little sens to begin with. I ported the knowledge I had on HBE to C and tried to make a clean basis with Casio Fx-9860 in mind. Second failure, I got cold scoled by Shmibs and I realized that if there were more sense to my eyes, it wouldn't be the same for the others.
So now, I'm clampled to wonder and ponder. Ponder the open source from beginning, wonder how the source code should be structured. Ponder the feasability of the project, wonder if I should ask for help as I already tried in vain. I don't want it to be just lost time into a unborn project. I'd like to have better feedback from anyone with enough experience to tell me how parts of the project could be done without being taken as an inexperimented programmer. I'd like to see who are interested into this heavy project and how much they are. I'd like in the end to see one of my game project plan to be achieved with this engine and maybe other people using it.
So at this moment, I store a repository in a GitLab (http://gitlab.com) repo. If anyone wants to mess with the few headers I have at the moment, feel free to poke me and I'll make the repo public or allow you to mess around.
So yeah, so much for a simple calculator project. Something that everyone could do, but I want to do it in a way that lot of peoples would be able to help or improve. That's the real meaning behind this project. (That and the fact I'm more and more thinking about a real calc -or not- game behind that.) Thanks for reading it.
At the demand, here is the last prototype version screenshot to date :
** the link was brocen and redirected to NSFW ads. Removed it**
Let's hope that I (or we?)'ll get to something better than that.
edit: p2 removed NSFW link
I remember seeing this on Omni and Twitter and I'm glad it's still alive. A Mother clone would be nice on calcs. :) Also you should put some screenshots in here. :P
Here is a screenshot of the project. As you can see, it's the only thing I made from the refactor. I can't get to something better yet...
Actually, the project even has a document generator set for later. It'll help watching or learning the structure and force me into making documentation as I like docs.
Oh I meant the old calculator screenshots :P (with the awesome animated battle backgrounds :D)
Oh well if you want so I could still add them back but they could fool other people as the result is obviously not the same anymore.
EDIT : Added a TI screenshot.
Until your edit, after reading your post I got worried you meant that you dropped the TI version >.<. I hope it remains alive. Btw C is possible on the 84+, using SDCC. AHelper0 uses it.
Yeah, but how much memory does a C TI program have? 20 KB? I don't even know if that'll be squeezable in a TI. At least i'll do a ligt version for TI, like no events management, with dynamic loading or something in these ideas to got around the 6KB file limit. At this time, the Casio addin weights already 3KB (if I don't count the ~1KB header)... And I just had some sprite blitting routine test.
I don't remember how much, but AHelper0 was working on an entire TI-OS using C. If he can do a full OS in C then you can probably circumvent memory limits (maybe a Flash APP?).
C isn't ideal for Z80 processors, though, so I'm unsure if it would be as optimized as in Axe.
Also the file limit in ASM was 8 KB not 6 and ZStart gets rid of it.
Unfortunately, the accident I had with Manjaro and my portable hard drive made me had to migrate to a x86_64 Manjaro with my laptop's drive. So I have to recompile GCC again.... That's pretty lame but well... So, I wonder if I continue on calc or if I try with a graphical lib like SDML or SFML. In the end, input managment and graphics will be out of the engine, so...
100 posts :w00t:
Sorry to hear. At first I was scared you lost all your projects or something when I started reading, and I'm glad it's not the case. Good luck with whatever you decide. :)
My love for Git saved me! :p Remember kiddos, backup & versionning will save you one day or another, it worth the pain of learning how to do them!
Indeed. I don't use Git because during my programming days I was "raised" without it and I am not fond of changes, so I stuck to my old ways of backing my stuff up myself. I also remember some people who lost progress about 10 times on calc projects in the past, yet never learned from their mistakes. >.<
Or just plainly lose the game itself (the two meanings are intended). ;)
Yeah that's what I meant (not the other meaning that just made me lose, though <_<). I once lost an entire RPG project (with hundreds of hours from work) due to lack of backups but back then I had no way to back my files up, so it was out of my control.
Awww that sucks DJ. :c
Yeah it does, and I feel anyone's pain when they lose a lot of progress. I stopped coding entirely for 1 month IIRC when this happened to me and that was back when I still coded 10 hours a day on calcs.
So yeah, try, if possible, to find a way to backup and backup often. Hopefully the current CW userbase does that already :)
Yeah I pretty much backup the stuff I do on-calc to my computer and dropbox every time I post an update, and my Nspire stuff is backed up to github, so I'm safe.
Never had a hard drive failure or a fatal calc crash though.
Not really HBE's code relatedn but I started implmenting MAkefile-wise mutli-target system. With a variable change (here TARGET), you can choose to compile for "DESKTOP" (use your computer's gcc) or "FX_9860" (use sh3-eb-gcc). Obviously, compilations flags will depend of your target.
Now, platform dependant code is locate in {include, src}/$(TARGET) . That'll help making the engine platform independant. Does anyone has a way to make that a little bit cleaner? (like moving the source into an arch folder or something else)?
EDIT : I started to draft an UML schema to help me vizualize the struture. Here's the thing at this moment. Do you have an idea about what's going on with it? Does it seem clear to you right now?
I can't help but good to see you want to make this easier to port between platform :D
I can't read the text in the picture, though.
You need to click the image to see the full size version. :P
Also nice to see you're working on cross platform.
Quote from: DJ Omnimaga on December 05, 2014, 05:00:46 PM
I can't help but good to see you want to make this easier to port between platform :D
That's the main advantage of adopting C over Axe Parser. But the main things which will be target-independant will be mostly I/O (files), Input and Graphism. I still havn't figured how much of the engine will be target-dependant, specially with the UI, but the core itself (damage, reactions, AI, events) will be standalone.
Think the core as a black box where I'm letting only the "insert that action from that thing" button for registering an entity action (player or opponent wise), a button for "start turn", "get subturn result", "next subturn", "update engine by a time step" etc... I think I have made some progress but when managing mixed real time and turnbased actions is very hard.
The main issue is that on some platforms, some things just won't be possible. Plus screen resolution can be a problem.
That's why I'd like the graphisms to be totally independent from the engine. Maybe a version will just have text, or have a different UI from the screenshots I had. But this is implying a lot of work for dissociating them
Can we expect an ncurses version ? :P
Why not? Actually, to debug values, I'll probably start by using a custom little console interface (just printf all the things) with predefined sequences (testing purposes)
Quote from: Eiyeron on December 06, 2014, 08:45:01 AM
That's why I'd like the graphisms to be totally independent from the engine. Maybe a version will just have text, or have a different UI from the screenshots I had. But this is implying a lot of work for dissociating them
As long as the 8x version isn't menu-based, considering the work already put in those battle backgrounds x.x
That's nothing much, really. They are actually a few hundres bytes weight if we count the drawing routines. I used quite some tricks to spare the most bytes (like your trick to copy a whole row of the screen and applying it to the whole screen). They're on the Axe source I linked back on Omnimaga if anyone wants them.
EDIT : I made progress in the UML schema but I'm having troubles with arrays/ multiples function arguments. ><"
Now that I use this topic from a computer I see that Tapatalk only loads attachment thumbnails, not full size images, which probably explaisn why I was unable to read the text on the other pic the other day.
And yeah I was wondering because your previous post said you might make some game versions text-based rather than using graphics, so I got worried you might drop graphics from the calc versions. >.< Glad it's not the case.
Good luck!
Quote from: DJ Omnimaga on December 06, 2014, 02:52:23 PM
And yeah I was wondering because your previous post said you might make some game versions text-based rather than using graphics, so I got worried you might drop graphics from the calc versions. >.< Glad it's not the case.
That would kill pretty much the interest behind a Earthbound-like battle engine! No sprites, no beautiful background animations. That would be quite dull! :P
Indeed, this is why I always encourage people to put some graphics in their games (or in BASIC case, ASCII/dual-layer ASCII). People gotta start small but if it has been a year since you started coding, I feel it's usually time to take one step further.
And only the step further, because cranking the thing up to eleven won't help neither. Hello, programming stalling :w00t:
I don't know if I get what you mean, but if you mean avoiding starting massive projects that are way beyond your programming level (for example a newbie starting a Zelda clone) then I agree with you. There are exceptions, of course, but most of the time we tend to get disappointed by such project when they die.
On a side note do you still plan to create a full clone of Earthbound even if it's small?
Yeah, even though it won't be an EArthbound, it'll be a RPG. I'm having some plans, ideas for the game itself. As usual, I'm targetting something too big, but if one day I finish it... :3
Ok good to hear. IMHO the best way to start, though, for an RPG, is just have like three dungeons that you beat one after another and a place to save/heal yourself, such as a mini map. Or you could do the classic elemental crystal story mode where you defeat a boss in 4 elemental dungeon before beating the final foe at the center of the map, but using an Earthbound-like battle engine. Then once complete you can re-use the engine for more complex games.
You could even do a remake of the first Illusiat based on Illusiat 2004, but then that would mean 1 vs 1 battles. Unless it was basically Illusiat Revisited where a group of warriors must visit the Illusiat 1 dungeon several decades after the events of Illusiat 1? :P
Or having already an idea on what could happen or how it would happen. I won't spoil the thing I want to do but I can't already give some pointers about what I'd like to do:
- Era : today
- Main location : a big city.
- Atmoshpere : gritty, a bit sordid, not your usual happy RPG world
It'll need quite some work to determine what should it contains, the scenario and all the bell and whistles but that's not my priority yet.
Oh, This is becoming more and more heavy, do I need a whole subforum? ... Not yet but that idea is on the "to think about it later" list.
So that city would be Detroit, Michigan, in the United States? :P
It already looks post-apocalyptic because population went from 2 million in 1950 to 700000 in 2010 and there are entire neighboorhoods that are empty and got reclaimed by nature. I mean, most downtowns in North America suffered from urban sprawl, leaving the downtown core empty, but Detroit is by far the worst I think.
If you search for Detroit abandoned or ghetto in Google, what you will see is pretty much what you see in a post-apocalyptic sci-fi movie. :P
As for sub-forum I guess this would be a nice addition, although it might be best to wait until there is a proof of concept for at least one platform (excluding the Axe version since you planned to restart the 83+ version from scratch). Sub-forums can be for any platform, although PC/Android stuff has to be game-related (an actual game or a development tool)
Quote from: Eiyeron on December 06, 2014, 04:50:42 PM
- Atmoshpere : gritty, a bit sordid, not your usual happy RPG world
This is what I love the most about Twilight Princess. That game was epic, it's a really nice approach for RPGs. :)
Yeah, I heard some joke about Detroit's look. I'd like a pre-apocalyptic setting. Just before *that* happens. The last day of a rotten civilization. Where the conclusion -oops I'm saying too much, as I don't even have the engine done! ^^ I don't want to have a "Mother" written in the name but the mechanics are the same. I'd like to see how a darker game or setting would fit to the engine. Mother, when not about family or love, is first a silly story. When you play the games you admit the sillyness and make it part the world. How could one explain in a more realist world silly things like photographs falling from the sky to take a picture and GI back to the sky? Or when one fight an enemy a LSD-like background appear! :) These games bring a light message (except Mother 3, f*** the ending), I'd like to bring a not-so-hapoy one, bring some characters in a deep noir city and watch them struggle to survive.
Matref, if you read this, do you want to work with me on the engine and port the code to Nspire? :p
Before apocalypse would be more like to prevent it from happening or saving people?
There would be an incentive to prevent it. How it will end is left to the scenario I haven't touched ( but I have an idea! :o)
I could help you port it to the Nspire, if I'm not too busy with my other projects. :P
But first, the engine is still have to be done first, so if you don't mind working on that too, I would be happy to have some help for this project ! :D
Well I have my own engines and toolchains to write so I'll have to refuse the offer. :P
Haha, these things sure take a lot for time! :p
Yes they do. I wanna get a toolchain going for Illusiat so that I can code on my PC instead of my calc. Better editing comfort and debugger in the emulator. :D
Sooo, I've been some tweaks to port Monochromelib (FX-9860 graphical librairy). It works on SDL2 and mostly works. This help testing here and there things on computer easier than on calc (avoiding Casio's SDK, ddd to debug, etc...) Buuut:
What I need to finish
- Converting variable size sprites blitting functions (ML_bmp_(or|xor|and), not ML_(8|16)_x ). As endianess is totally different from computers, I'll maybe try implementing it the worst way possible (pixel per pixel), unless someone has some functions like that.
- Scrolling is borken for same problem : endianness.
- Finding a way to rescale the SDL_surface when I rescale the window and scale/center the output.
- Free SDL things.
- Checking with some tests.
You can use it as you would use ML but you have to do two things:
- Check ML_SCALE and change it to change the screen scale
- Use ML_Init() in main() to initiate the screen.
So you're basically making your own library for portability ? And each lib has it's own backend depending on the platform ? I'm interested in making Pokespire cross platform although it would require some modifications to the current build system. I really don't want to deal with headers and I don't know how makeheaders would react to modular stuff.
Yeah pretty much a tempoary solution to the graphism problem : I want to get a similar output than a FX-9860 and it'll avoid to make a different graphical loader before finishing the engine itself.
For your project, I don't know what makeheaders but you could try to figure where the code depends on the platform, make an alternative (i.e. computers) and put it aside.
I'm glad it uses SDL in some ways because I think this could make it much easier to port the game to nSDL. Does MonochromeLib supports grayscale, by the way? Also by similar output do you mean for bigger screen models you would prefer to stick to the same 128x64 resolution zoomed in?
MonochromeLib is a Monochrome graphical Library, so I'm letting you guess! :p. Yeah it'd be pretty to port in to nSDL if one cares to manage endianess as it should b and switches the skurce code for SDL 1.xe. And yeah I mean 128*64 with a scale factor. This is a direct port of ML for 128*64 and changing the screen wouldn't add much more as SDL2 supports hardware acceleration, so It would be quite easier to just having to deal with monochrome sprites then.
I guessed it could be monochrome, but I was wondering because Hinawa used to be grayscale ???
Only one the Axe version. Casio grayscale aren't very popular as the timer breaks often the Casio OS and forces a reboot. If I find back the way how LuaFX restores the vbr I could switch back to graysacle.
Aah I see. You could maybe ask on Planète Casio in case someone would like to help.
Quote from: Eiyeron on December 09, 2014, 04:33:03 PM
Yeah pretty much a tempoary solution to the graphism problem : I want to get a similar output than a FX-9860 and it'll avoid to make a different graphical loader before finishing the engine itself.
For your project, I don't know what makeheaders but you could try to figure where the code depends on the platform, make an alternative (i.e. computers) and put it aside.
Makeheaders is an awesome piece of software that generates the headers automatically. My makefile invokes it so that I don't have to care about them, this way I can speed up development without having everything in a single file so it's also well organized. :)
I already spplitted into multiple files though. Will it read the include in the C source and guess the headers?
Well, it generates .h files and I build a .o for each .c, then I link them together. I'd recommend taking a look at the Pokespire source tree to see how it all works. :)
Because I can't keep working on a project more than one week, I got back a little on HBE and gave more precisions to the class diagram and the source code. Now the entites does have ailments. (I still don't have any logic programmed yet. Still working on the structure.) A little overlook detail : I should add the ailment relations. An entity can have many special ailments but only one each permanent or tempoary normal ailment.
What does mushroomized so? O.O
It makes the character having a chance to target a random entity instead of the target it decided to aim. That and in Earthbound you had a vicious effect in the overworld : each 15 seconds your movement are rotated, for instance press up make the carachter go left, left for down, and so on.
Aah ok so it should be called Pothead instead then. :P just kidding, thanks for the info. :)
Quote from: DJ Omnimaga on January 15, 2015, 03:15:27 PM
Aah ok so it should be called Pothead instead then. :P just kidding, thanks for the info. :)
No, mushroomized (I want to reprogram the battle engine) Look at Paula.
(http://walkthrough.starmen.net/earthbound/image/screens/16/mashroomized.png)
Oh ok lol. Since it's Earthbound I thought it refered to shrooms :P
What kind of shroom? The ones which makes you trip balls? There are some in Mother 3. (fun part, though, yet quite gloomy at some points.)
Yes, those. :P funny how the game was rated kids to adult :P
Because it's mostly implied deaths or suggestions, no real on-screen death can be fully assumed (except the spoilerish one). But Gigyas, dang!
Oh I meant the drug references :P, but again they're illegal so no age regulation exists :P