Notes!
This commit is contained in:
		
							
								
								
									
										56
									
								
								NOTES.md
									
									
									
									
									
										Normal file
									
								
							
							
						
						
									
										56
									
								
								NOTES.md
									
									
									
									
									
										Normal file
									
								
							@@ -0,0 +1,56 @@
 | 
			
		||||
# Notes
 | 
			
		||||
 | 
			
		||||
The problem I'm facing right now is I really need to figure out how Quest 
 | 
			
		||||
Objectives will work.
 | 
			
		||||
 | 
			
		||||
Primarily there are a few different objective types;
 | 
			
		||||
- "Code" controlled
 | 
			
		||||
	Covers anything that can be triggered by the code itself, usually using the
 | 
			
		||||
	event system. Here are a few examples;
 | 
			
		||||
	- "Go talk to this person"
 | 
			
		||||
	- "Go fight this boss"
 | 
			
		||||
	- "Activate this switch"
 | 
			
		||||
- "Check" controlled
 | 
			
		||||
	Basically these are objectives that can be completed and potentially
 | 
			
		||||
	uncompleted again if the circumstances deem it so.
 | 
			
		||||
	
 | 
			
		||||
	Consider;
 | 
			
		||||
	"Go find 3 potions", could happen automatically, but if the player were to
 | 
			
		||||
	then consume any one of those three potions, then the objective would
 | 
			
		||||
	un-complete.
 | 
			
		||||
 | 
			
		||||
	I think in this scenario the actual turn-in is either going to be an active
 | 
			
		||||
	checker that turns the quest in automatically, e.g. consider the "find 3
 | 
			
		||||
	potions" scenario I put above;
 | 
			
		||||
	You would get the quest, go find 3 potions, and the instant the third
 | 
			
		||||
	potion was collected, the game would trigger a cutscene and the quest would
 | 
			
		||||
	be complete as part of that.
 | 
			
		||||
 | 
			
		||||
	Alternatively the player could have to collect 3 potions and then turn in 
 | 
			
		||||
	with an NPC, who would check when interacted whether those items were in
 | 
			
		||||
	the players' inventory or not. This is particularly so for key-items which
 | 
			
		||||
	in theory cannot be uncollected, but would still require this "collect and
 | 
			
		||||
	then turn in" approach.
 | 
			
		||||
 | 
			
		||||
	Thinking about it further I think these check controlled objectives really
 | 
			
		||||
	are the same as code controlled, I would just need some other kind of code
 | 
			
		||||
	to be doing the actual checking.
 | 
			
		||||
 | 
			
		||||
Next Steps;
 | 
			
		||||
- Create looping event type(s)
 | 
			
		||||
	Loop Event
 | 
			
		||||
	Allow go to Event can go back to parent and re-start it
 | 
			
		||||
	Restart Event
 | 
			
		||||
- Create an ever-present event type
 | 
			
		||||
	This is an event type that will process "constantly" (realistically I think
 | 
			
		||||
	this is an event type called "AutoStartEvent", with options to loop)
 | 
			
		||||
- Create more conditions for checking if player(s) have items, take items, and
 | 
			
		||||
	more.
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
COOKING
 | 
			
		||||
Next I need to create some events to send you to a cooking mini-game. Cooking
 | 
			
		||||
mini games will just be a different kind of game scene that can't be exited.
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
		Reference in New Issue
	
	Block a user