36 replies to this topic

[Yal]

Why are you talking about saving-cheating stuff for this (not-made) game?
It's the most early alpha / hardly beta.

One of the key priorities when setting up a system to contain all the game data should be to make it well suited for saving/reading the data. Obviously it's good for us developpers to make data as hard to mess around with as possible.

...the rest can be developed a lot even without me.
All I'm asking is, would anyone be INTERESTED in making this game.

Such topics are frowned upon; ideas are dime a dozen while devotion for an idea is not. Put short; everyone has some idea about what games they want to make, so if you offer up an idea for grabs, you're essentially wasting your time typing the topic because nobody is going to make the game because everyone's busy with their own ideas already. Also, a topic that's basically "Can some1 make this gaem 4 me?" in one way or another is arrogant and lazy at the same time.


That rant might've sound a bit harsh, and I want to emphasize that I'm not accusing you for doing such a topic here.

[Koshej]

Yal
But this isn't the case!
I said, I'll make a playable demo MYSELF.
Except, it won't be a FULL game, or rather, an INCOMPLETE one.
Thus, you'd be able to PLAY my demo, but I'm looking for adding ideas and features TO IT.
Also, I'm looking for someone NOT lazy (unlike myself, hehe) to sort out and make game-usable, the whole huge Digidex - the thing I myself WON'T do for sure.
Another point was, I won't add any storyline, but I'm positive about having it, as well as any additional nice feature YOU (anyone) can think of adding, without ruining the core game.
Basically, I'll provide a "raw" working base for a development workground.
It's NOT "make it for me", it's rather "take the baby and let it grow"!

Edited by Koshej, 16 April 2012 - 01:13 PM.

[Yal]

it's rather "take the baby and let it grow"!

In that case, I'd try to market the game as "The best DIGIMON Engine ever made! Open source! Lite-friendly! Easy-to-use! Tutorial TXT document included!" rather than an unfinished project. Just saying (Yeah, I do that all the time myself.)

[Koshej]

Yal
Well, the problem is, I didn't even start doing it, still thinking about the technicalities...
I don't want to start, then be forced to redo something due to incompatibility with new ideas...
So, thinking first, writing last.

[Yal]

Beware! That approach may trap you with never-stopping planning. It's important to start working with the game sometime when you still have oodles of motivation left to actually work on the game.

[Koshej]

OK, OK, don't worry.
I'll try making the demo in the near future.

[Koshej]

Here goes my very first, very CONCEPTUAL DEMO:
http://www.2shared.c.../dm_online.html
Basically, this is just how the game will LOOK, together with the ROOM mechanics.
(Not click-wise, but VIEW-wise.)

Oh, beware, it has some additional "custom-made" MENU "buttons" being used, I found them recently and really enjoyed.
I could do the same actions through simple coding, just this way it was easier.
(I do hope it will run on a normal version...)

Edited by Koshej, 16 April 2012 - 05:25 PM.

[Koshej]

1. Why no reply?
I wanna know at least if those buttons work for "normal" GM versions, so I CAN use them.
2. I wanna hear a comment on my idea of specifically using VIEWs, instead of ROOMs.
I say, this is more preferable, cause you don't need to search for ways to store variables between rooms, only to check them when switching views.
Which is much easier, in my opinion.
Also, I'll probably use "view-specific" invisible "core" objects, to place/draw in "relative" x/y, thus I don't need to calculate the "real" ones.
3. I'll more than probably add more views, not sure yet which ones.
But I have a Battle-related question I can't decide:
What is better, multiple mons vs multiple mons OR one on one?
Same goes for having multiple mons vs always having only one, but being able to switch to the newly caught one?
The reason: this is Digimon, NOT Pokemon, so typically Tamers have only ONE Digimon at a time (typically, the same one ALWAYS).
So?

[Yal]

Basically, this is just how the game will LOOK...

Hmm... in my personal experience, starting with the core mechanics and then building upwards often make the game work better. It takes a longer time until you make visible progress, but the end result is often worth it. For instance, when writing the framework for Daemon Detective it took like three days before I got the graphics system that draws the level up, and for two more weeks there was no interface at all; when I finally coded the last bit of code so that I could press ENTER to make the enemies pathfind and walk around the grid, I was in tears of happiness.

The best thing? After like four days later, I had the entire menu system including player input up and running with all main options working perfectly. Since I had all the foundation code ready early, it wasn't that much work tying the knots together.




So in this case, I'd recommend you to start working with the data structure system first, and then the battle room with two placeholder monsters (that yellow dragon and his cousin), before you code in the overworld map. The data system of the RPG is what takes the most work to finish (the better the RPG, the more data you need to save and mess around with) so it's best to start with it and get the difficult part over with. It's better to design the GUI around the data system than the other way around, it gives you the least work in the end.

[Koshej]

Yal
Well, that's kinda my point too.
By "look", I meant exactly the programming style, not exact interface.
Typical GM games use ROOMs, but I'd rather use VIEWs, for easier variable tracking.
I should make a much more in-depth demo in the next couple days, so you'll see what I mean.
Anyways, so CAN I use "custom buttons"?
I mean, do they work on "normal" GM?

[Koshej]

Semi-bump, semi-note.
I'm gonna stick to English names, cause I like them much more.
(I hate "Vamdemons"...)

[Koshej]

Hi.
I'm in trouble...
http://www.2shared.c.../dm_online.html
I can't make it to read pictures correctly.
And I can't find the mistake.
I tried a whole bunch of approaches, but none worked...
HELP, please...
It does READ the keys from the ini correctly, as you can see that it names the choice right.
(And this is my general idea for the entire game engine.)
But somehow it's impossible to change sprites the right way...
So, can anyone see into it, please?
The best I ended up with, was having all objects with the last found sprite - and I can't find out WHY...

Edited by Koshej, 26 April 2012 - 03:17 PM.

[Koshej]

Hey!
Can anyone PLEASE help me with that problem?!
I really don't see the error, but the result is a failure...
PLEASE!!!

[Koshej]

http://www.2shared.c.../dm_online.html
Guys, quit ignoring my requests for help, PLEASE!!!
I changed it a bit, and I can see now the problematic code - though I don't get the PROBLEM itself...
HELP!!!!!

if (i<32)
{
i+=1
instance_create(64*((i-1) mod 8),64*((i-1) div 8),pic)
ini_open("choice.ini")
keychoice="choice_"+string(i)
choicespr="choice"+string(i)
name=ini_read_string("choice",string(keychoice),"")
unlocked=ini_read_string("unlocked",string(keychoice),"")
if ((file_exists("Pics/"+string(name)+".png"))&&(unlocked="TRUE")) {sprite_replace(string(choicespr),"Pics/"+string(name)+".png",1,1,0,0,0)}
if ((!file_exists("Pics/"+string(name)+".png"))&&(unlocked="TRUE")) {sprite_assign(string(choicespr),nopic)}
if (unlocked="FALSE") {sprite_assign(string(choicespr),locked)}
ini_close()
}

This is in the Step Event of the CHOOSER object...
The problem lies in THIS: "string(choicespr)"...
For some reason that I can't understand, it fails to work properly...
What happens, is that it takes the LAST sprite option and applies it to ALL sprites...
Meaning, I can see how the first sprite turns into the right one on Step1, then turns into "nopic" on Step2, though it should apply ONLY to the NEXT sprite, not this one, and then it stays so until it turns into "locked" when the objects reach that point...
And it definitely has nothing to do with the ini, cause the NAMES/Locking works perfectly...
Also, THIS is the only code of the PIC object, in the Create Event:

i=instance_number(pic)
sprite_index=string("choice"+string(i))

This is where the stupid error doesn't make sense...
The object changes its sprite_index at CREATION, thus the next step, it shouldn't even change...
This definitely shows, that the fault is of the CHOOSER object, it somehow applies the evaluation/change to ALL "choice" sprites...
HELP, PLEASE!!!

Oh, and btw the idea of this "update" is also about "unlocking choosable Digimons".

Edited by Koshej, 29 April 2012 - 03:36 PM.

[Yal]

Only so you know, you can't use string() to get the name of a sprite. My guess is that when you feed that function with a string, it interprets it as "-1" instead, which is Game Maker's internal "current" constant so thus it changes the current sprite.


To fix this you can do either of these things:
1) use sprite_get_name() instead
2) use execute_string() to actually be able to use the name strings.

[Koshej]

Thanks, FINALLY...
Yeah, I had a feeling, it was THE reason...
...
I tried this and that, all fails anyways.
Generally, this means that the (external-source-based) sprites are THE constant problem...
...
It seems, that I'll just have to end my project, or drop the MAIN idea I so wanted to implement.
Can you PLEASE test for a WORKING alternative code, I already give up - this program hates my ideas...
(The TEXTUAL use of inis is perfect, though... Maybe I will use at least THAT for something...)
...
Or is there a chance, that someone would spend some precious time and provide me with a WORKING code for my idea?
(I so doubt THAT, unfortunately... )
You can view it as a "programmer's challenge" vs GM.
(Oh, and don't think, that I'll start demanding "to do my work for me" - all my other ideas are usable, even semi-tested, only this one is a stopping block, due to program's weirdness.)

Edited by Koshej, 02 May 2012 - 12:57 PM.

[Yal]

Sheesh, dangit! Just read up on how stuff works so that you know what you're gonna do works in beforehand, I always do that. That means that when something doesn't work, I've just made a mistake somewhere and all I gotta do is to find it, correct it, and then facepalm. Trying to experiment forth an algorithm, on the other, means that you'll never be sure you'll every produce the desired result.

So put short: planning, although boring, is useful and makes your work more efficient.



And as said in my previous post:
YOU CAN'T GIVE sprite_assign() THE SPRITE NAME AS AN STRING ARGUMENT, YOU GOTTA USE THE SPRITE IDENTIFICATION NUMBER INSTEAD. I'm surprised you don't get error messages from doing that!

I'm gonna close this topic now. Make a Team Request topic if you need teammates, make a Novice And Intermediate Users topic if you need help, or provide stuff do discuss if you want to make a Game Ideas And Design topic.