Game played over weeks - am I being too ambitious?

C-7 So although you do have an online storage, all the quest logic is stored locally, correct? I haven't had chance to play your game, but I assume it has the player character walking around, talking to NPCs and getting quests. I presume the logic is something like:

Talk to NPC

Check if you already have this quest

Display dialogue

Add quest to array

Then if you chat to the NPC again it'll show different dialogue like "have you completed the quest yet" etc.

It's the logic of this that I'm struggling to get my head around. I'd love to see a good example. I don't want to have the verbose process of creating individual logic for every NPC that does the same checks each time. Or am I just asking for trouble and should do it the time-consuming way?

onion

I apologize in advance if the image is huge. I store the state of someone's data online once you save, but everything else is handled locally. I have a dedicated slot in my array for each quest. I also have a private variable for each npc if I want them to rotate through a few sayings. In this example, I'm showing how the status of the quest that pertains to this NPC changes what they say or what actions happen.

<img src="http://www.adamprack.com/materials/teachevent.jpg" border="0" />

My array, called Inv is what we're looking at. At 0,7 is the quest for this person. For all of my regular quests, 0 means it is available, 1 means it is currently in-progress, 2 means it is complete.

I also have a check if the NPC is within range (it sets them to "Active = 1" if they are). I have an invisible rectangle with an id variable that references each npc, then I set the visuals for them to that position. I also check the "Speech" layer opacity so it won't let you open up another conversation if one is currently open. In the first event, if 0,7 is 2, then it shows a message if you've completed the quest. I have subevents that test if a certain story element is running or not, too. The second event runs if the quest is open and starts the dialogue for if you want to accept the quest.

Just so you can follow it all, if Speechon = 1, it fades in my speech layer. There is a triangle "Play" button that progresses. There is a variable on there called "more". If it is 0 and you hit the play button is sets Speechon to 0 and fades it back out. If more = 1, it doesn't.

I know there's a lot there, but you only have to write that once and then copy-paste and switch numbers/text for the rest of the NPCs. I'm sure someone may have some more elegant solution, likely using functions, but I really like being able to follow as much as possible right there.

But I hope that example helps!

The other possibility I'd use, onion: since you're using MySQL on the back end...when a PC talks to an NPC, you send a query back to your php with the NPC's id. Your php can look up a table with the players' id and the NPC's id to figure out if/when your've talked to them and what step a quest might be on (could hold the quest in another table...you can make as many db queries as you need). It could figure out what the NPC should say and return a the text along with a list of options the player can choose.

Present those to your player and send his response back as another query. Repeat until the conversation is done.

Obviously it would require more knowledge of php/MySQL than C2, but it would have the advantages of:

1) Being more secure. While most people won't monkey with your client code, someone's going to play with it at some point.

2) Keeping your client size smaller. Storing massive amounts of data on potential NPC conversations plus the logic to handle them on the client side will require the client to have to download all that data/logic, where as the server only has to send just the specific responses needed at the time.

3) Possibly more efficient. Most servers can run php logic scripts and db queries way faster than a client's machine can, and MySQL is optimized for this kind of work while the C2 array hasn't quite been around as long. (Not knocking Ashley and the gang, though...it's just that THIS is what MySQL was made for)

Both methods would work, however, so go with what works for you.

Thanks very much C-7, it's great that you've shared your code! Your solution is sound, but have a niggling worry about the amount of duplication you've got if you have similar code for each NPC. Although it's not much of a problem as long as you don't need to change it.

theubie I'm glad you've told me about this solution, it's what I've had in my head actually. I'm very familiar with mySQL, so this wouldn't be a problem. It essentially makes C2 the frontend and store the logic elsewhere. A bit like a webpage actually.

As a webdeveloper, this makes sense to me!

Thanks very much C-7, it's great that you've shared your code! Your solution is sound, but have a niggling worry about the amount of duplication you've got if you have similar code for each NPC. Although it's not much of a problem as long as you don't need to change it.

theubie I'm glad you've told me about this solution, it's what I've had in my head actually. I'm very familiar with mySQL, so this wouldn't be a problem. It essentially makes C2 the frontend and store the logic elsewhere. A bit like a webpage actually.

As a webdeveloper, this makes sense to me!

It's a trade-off. I could do it as a function and save on the duplication, but it would make special circumstances more difficult. I like being able to list the conditions right there because there are plenty of instances where you would want things different. As far as where you store the actual text, it makes no real difference whether it's in a database on your server or in your C2 code. I would just as soon make it easier on yourself and include it in your C2 code--I would hate to have to adjust the message length to make it fit correctly each time in your database. I would definitely not worry about file-size if you are. Minified, my game is just over 2MB plus graphics (which brings it to around 30MB). If you're worried about speed, I would spend your time being efficient with your graphics.

C-7 it will depend on two factors: Scale and Scaling of the game. If his overall scale is relatively small, say a couple dozen npcs with a couple dozen quests then the effect of keeping the code server side would be minimal. If that game never expanded beyond that point then there's a very good case for putting all the code and data for the quests client side.

However, if he has several hundred npcs and several hundred quests then it's probably better to put that info server side which is way more efficient at doing this job plus the lack of a need to send every thing to the client.

And, if he plans on constantly adding new content, then server side is a better option...you simply add new entries to the database rather than compiling and pushing a new client every time you add a new dialog tree/quest.

onion That's exactly what I'm using C2 for with our MMO UWE. Our past two versions have used plain HTML and XHTML/AJAX as a frontend to our user while the php code handles all the match and training data for the wrestlers. C2 is just a massive leap forward as it allows us to make the user experience up to the level of a download game rather than limited to a browser experience while all the grunt work of the game is done server side.

We do unattended training, so it's only logical for us to keep processes server side. I can see a MMO where most of the logic can be in the client, but again the problem you run into there is security. It's a lot easier to hack the game (which is a major issue for multiplayer games) if the game logic is on the client side.