Project Pass-Around ... Let's Build A Weird (Single Player) RPG Together!

Just a quick note here to say the front lawn is mowed!

Ha ha! Well you don't care about that at all.

What you need to know is after the lawn mowing I made the update for a configurable camera and also changed the control of the player.

So do a pull to get the latest. And on the Main Camera FollowPlayer script in the Inspector you can now choose one of four camera types: World Map Generation (just for screenshots and creating map image), Top Down, Third Person and First Person.

Note: I didn't have time to dig into the saucer code and understand how it actually works. What we need to do is make it so when player enters the saucer the current cameratype (as in the view) is saved and then the cameratype is changed to Top Down. When the saucer lands and the player exits the saucer we then need to restore the previous view.

I also have no idea if I did this in the Unity Way. I just merged the updates into the PlayerControl and FollowPlayer scripts in a way that makes sense to me. Mainly because as much as I want to learn more of the Unity Way I don't want to waste all of my time doing that and never get anything done.

However, at some point I do need to have time to actually look at the code other people have wrote in this thing. I haven't even looked at the code period. So far since this thing kicked off my time has been focused on approves, merges, testing updates, etc. And the writing here about story and design ideas and finally making the start of a map and now the camera stuff.

Okay... back to work around the house now. Dog bath time I think. The next time I get back to this I will take a look at the Saucer control thing and figure out how it is working. And if nobody else has made that camera update for it I will do that.

 

Okay, I have two clean dogs.


Now back to this project. First thing I did was move over the Outer Boundary Mountain Range from my development working folder to my local repo, commit, blah blah.

Do a pull to get the latest please.

Now I am just going to spend the rest of this game dev chunk of time looking at the source to see what is actually in there including trying to figure out how the saucer actually works. I'll probably need to add a new message type so the saucer can let the camera know to swap to the other view type.

One thing I have noticed so far is that working more the Unity way makes it easy for any one person using the component approach but it definitely seems to make understanding the project as a whole more complex when other people are involved. Whereas in a "normal" approach everything is pretty straightforward. There would be some code probably a class to handle the saucer and it would tied in with the player control or whatever. But with components everything is scattered all around completely separate which adds a layer of complexity to understanding.

Not complaining just giving my observations at this point.

 

It can. Another way to look at it is design by contract, which can be very helpful for multi-person projects. Treat the other person's MonoBehaviour as a black box in which the interface is not a set of exposed properties and methods but literally the user interface in the form of the component's inspector. It takes a little more care on the MonoBehaviour writer's side, but then other teammates don't have to dig into the code. UnityEvents are really helpful for this, as are [Tooltip]'s and other self-documenting techniques such as adding HelpBox attributes. This approach isn't always doable, but it usually works well especially when you're hooking up activity among components in the same GameObject/prefab or between GameObjects in a specific scene (e.g., pull a lever to lower a drawbridge).

Also, if any level designers join the project, they can add more interesting behavior even if they don't know how to program.

 

That makes sense but even this is all adding another layer of complexity / overhead work to such projects. I know I tend to always view things in terms of how much work (or extra work anyway) it takes to actually get stuff done. But the reason for that is because my goal is always to focus on actually getting stuff done for the game itself not managing the added complexity of using a certain approach.

Overall, it is not terrible though. I have the UFO notifying the camera when the player enters and exits the UFO. I tested player in First Person view and entering UFO correctly switched view to InSaucerView. However, exiting UFO sends the message and the previous view is restored but the actual view seen in game is a very close TopDown view. So I need to sort that out. lol

 

Ah I see... I had put the hook in at the wrong spot on the UFO control script... wrong method.

It's working now. Regardless of what view type is selected when entering UFO camera changes to the InSaucerView.
When exit the UFO the previous view is then restored.

Please do a pull.

And this is probably all I will get to for a while. Just wanted to get these basics out of the way.

I'll work tonight in a notebook planning so if anyone else wants to actively work on the project go ahead.

Also did @Master-Frog's stuff ever get sorted out?

 

Just thought I'd say overall seems like things are going well. Progress has been made. There are actually some nice things in there already. @DanielQuick I like your IInteract approach because it is logical to me. In fact, that is how I did things in my little sub adventure project and shmup a couple of years ago. Also the saucer control was easy to follow.

The "real" graphics content that was contributed looks awesome too.

Don't let my griping about keeping things simple put anyone off. lol I only do that regarding git and so forth in the interest of actually seeing the project work out. Like I don't want @Master-Frog or anyone else spending time working on cool stuff then get so fed up with "extra crap" that has nothing to do with the actual coding game dev side they say to hell with it.

 

Okay, I did mess around with the Blacksmith menu.

Basically something along these lines should work...



I have no idea how in to make the buttons pass in an index number to the same method with the Unity GUI system so instead I have 8 different button click event handlers for each of the Buy, Sell and Repair "pages".

Obviously don't have the page navigation in that would likely be needed.

But whatever... this will work. Just need to iterate through these and populate the text appropriately based on available items. Enable/Disable buttons as needed.

It's in my dev copy of my local repo and I won't bother pushing it up. I will keep working on it most likely so it is easy to work with. But I am done for tonight.

 

Just assign a method that accepts an int parameter:

Code (csharp):

1. public void Buy(int index) {...}

 

Alternatively you can create the buttons from prefabs via code in a loop. You can then assign the code to call via AddListener using a lambda function. That way you can use any combination of parameters you like.

In fact for inventory and shop interfaces where the list is being created from a dynamic collection, this is probably the best way to do it.

 

And you would likely want to set the OnClick value in code. This way you can have a Dict to hold your items and then pass the key in the OnClick call. Or use a drop down - not as pretty but if you want to keep it simple easier.

Edit: @BoredMormon was quicker

 

Awesome thanks you guys!

I had no idea had I just stuck a param in the signature it would be picked up and presented in the Inspector. Surprisingly I never did a test for that (I like experimenting) but was more focused on just getting it done.

I'll probably refactor it the next time I get a chance to get back to this project.

 

Just an FYI... @Master-Frog emailed his work to me last night. I'll focus on getting his updates merged and pushed to the repo as soon as I can. It'll probably be tonight but I might do it on my lunch break in a few hours.

 

On the GUI thing I see it like there are two main ways of doing this stuff. Either do it all in code OR do the GUI design separately making a sort of template and then programmatically work with that to show/hide items, set the visible text of the items (perhaps show an image too), etc.

Generally for GUI stuff I favor the template approach (I mean in my dev work outside Unity). Of course it will always be programmatically populated and so forth dynamically. And the code will know if it is page 3 then the items represent items #17 to #24 instead of #1 to #8.

 

Made a pull request. Now that there is a UFO, the ability to abduct cows is a requirement.

Hold spacebar to abduct. Also added a new camera to the UFO so you can use the mouse to orbit.

 

Ha ha! Sounds awesome. Interesting stuff for sure!

I ended up doing some work on my lunch break for items. Basically there is a CollectibleItem class and associated enum of type. So maybe burlap sack is type armor. Every CollectibleItem has properties for name, weight, damage, armor, blockchance, newprice and so forth. Doing this because needs to be some game stuff in there collecting items, selling items, getting money of some kind, etc.

I am working in my dev copy though. So I will merge and pull your updates down first thing after work then work on merging @Master-Frog's updates. Then I'll do a local pull and copy that as my dev working copy and move over the stuff I am working on and continue. Time permitting of course.

 

@DanielQuick your updates are in. I attempted to drop in @Master-Frog's updates as well and the project broke.
I have it fixed working again but we don't have any of his stuff done in the Scene, if there were any.
I can always check and if there are export them as a package and then import in.

So... anyone involved in this project... do a pull to get the latest.

Right now I am going to get back to what I was updating earlier because I am thinking he can easily do any scene stuff he may have had in there. And I much more enjoy actually doing the dev stuff than the repo management stuff. lol

Btw tractor beaming the cows is good fun!

 

I have a couple suggestions for this thread.

1. Update the OP of this thread, as it is now it is not clear if the project is happening or if we are still spitballing. Creating a new thread would be better (in the WIP section).
2. Set up Unity Cloud Build to auto-generate a new HTML5 build every time the primary repository is updated. Have a link to the latest build in the OP of the thread.
3. Encourage gifs when submitting contributions (have links to gif creation guides in the OP). This would provide something to look at between merges and keep excitement up.

For this project to be at its best, it should be as easy to access as possible. Viewers should be able to play/view the game without needing to download the repo. Then they can decide if they want to download the repo, and if not they will still be able to provide input in the form of ideas / story.

@GarBenjamin If you would like help with the repo management feel free to add me to the repo.

Glad you enjoyed it!

 

YES! YES! YES! YES! YES! YES! sorry got carried away there.

These things all sound great to me.

I have no clue about using this Unity Cloud Build you speak of. My primary knowledge of Unity is how to take it.... and not use it for much more than a way to pool objects, load resources, draw stuff on the screen and play audio. See previously I was working to be able to develop games in Unity the way I would if using C# & XNA, C & Allegro, etc. So not much Unity specific information here especially not any info for related things such as this UCB thing. I remember seeing posts where people talked about it so I know of it but that is all.

Feel free to set up any of this stuff including the Work In Progress thread. I really don't (and never have) seen this as "my project". I was just the one who kicked it off. And I tried to throw out some common sense guidelines for working together. Basically to make it "fun" and not be so damn rigid like too many projects are.

But I see it like this is truly a Community Project. I will have a look at BitBucket to see about adding you as an admin or whatever it is.

Thanks very much for offering!

 

@DanielQuick okay, I think you should have Admin access now.

 

Had some time to mess around with the Blacksmith shop menu again tonight.



Buy "screen" is driven from a list of CollectibleItems in the BlacksmithInventory.
Sell "screen" is driven from a list of CollectibleItems in the PlayerInventory.
Repair "screen" is driven from the list of damaged (Durability < MaxDurability) CollectibleItems in the PlayerInventory.

And here is the CollectibleItem definition


So far this was easy enough. I mean of course this is super simple stuff as far as programming goes but I mean it wasn't bad at all to get it working using the Unity stuff. I still stumble a bit here & there figuring out how to best make the jump from my programming model to the Unity stuff but overall it is going well.

I don't know if all of the attributes of a CollectibleItem will be needed but right now I'd kind of like them to be.
Just basic stuff anyway. As you can see every item has a weight (which I figured will limit how much can be carried), and then damage, armor and blockchance come into play during battles (and even a weapon such a sword has some blockchance).

Of course, newprice is the suggested retail value but the merchant may come down a bit from that, sellprice is the buyback value of the item in "new" condition (in reality it will be factored based on this value and the current durability of the item at the time it is sold). Durability is just the current condition of the item. As it wears down we could make it slightly less effective. MaxDurability is what it starts at and what it goes back to when repaired. Probably anyway... I suppose we could make it go back to a random range from 85% to 95% of the maxdurability.

I also gave them a unique ID which is just something I generally find handy in all things.

Basically this stuff is just to support gameplay and help the player to "feel" a difference between different items. And it is all very straightforward. Since this is action based I'd say we could make each of these attributes only make a difference in a slight (scaled down) way but together all of the attributes should create a nice synergy that makes things "feel" different. That's the idea anyway.

That's it for tonight.

 

It's less a feature of Unity the engine, and more a feature of Unity the company. Unity Cloud Build. You link it up to the repository, set it to auto-generate HTML5 builds, and it will take care of the rest. All we would have to do is get the share link each time a new build is made.

I would set up the Cloud Build, but I have a pro license which gives priority to my builds. I imagine it isn't very legal to get those prioritizations on a project made with Unity Personal. I'll look into making a second Unity Personal account later today. If it isn't too much hassle I can set up the cloud build.

I'll write up a new thread for the WIP section and likely post it later today.

 

@GarBenjamin Making a separate Unity Personal account was easier than expected. An HTML5 build is already in the queue.

How do you post gif files on the forum? It doesn't seem to work by attaching it as an image.

 

I just use the little insert image button and add them like any other image. However, there seems to be a size limit IIRC. I remember having to redo some of my gifs last year to make them smaller and then compressed them more too.

In case anyone wonders...

I use this to convert videos to animated gif images. Free. Works good for me at least. Might not work for others (no idea if they save what is submitted but for me I don't care one way or the other).

Then I use Imgur to host my image files.

Together they make a great combo for my needs.

 

Got it all working. Had to disable auto-lightmap baking since WebGL doesn't support it.

Latest WebGL build

And quite possibly my first ever gif (definitely need to look into making better gifs)

 

Yeah that's fun stuff and great cow models. Really nice touch with the animations on them during beam-up.

I had a lot of fun beaming them up and dropping them around the halfway point (just as you are showing) then catching them again. And trying to stack them up into a tower of cows. Course they always fell over. Need to build a thick tower of a few cows per level I think.

Anyway this does open up the option for some puzzles such as creating a bridge (should we ever have a canyon or body of water and no boat). Saucer can perhaps bring over large stepping stones for the water or even drop trees that fall over and be used to cross both.

 

Ya know... Unity is not so bad once you start getting into it.

I already had the inner zones implemented to detect when the player entered buildings in preparation for adding this kind of thing. It was dead easy to hook this up on my lunch break. Just needed to set up another message to fire off when the Exit button is pressed so PlayerControl knows they are no longer in the menu, etc.



Course, I guess that floating E back there means @DanielQuick was thinking press that to bring up the menu. So I should probably look at figuring out how that works and do it that way. Consistency is good even when doing remote random updates.

EDIT: Also... this stuff needs to go on the "real" Blacksmith building. That awesome one that was contributed.

 

@GarBenjamin The interaction is only a suggestion - if you feel it makes more sense for the menu to pop up by location feel free to remove it!

I have created a thread in the WIP section: Community Pass-Around Project (RPG)

Let me know if you believe anything is missing from the opening post.

 

@DanielQuick your WIP post in the new thread is fantastic. And it was a great idea. We've worked out guidelines, set up git repo & Trello over the course of this thread. Here it is all fragmented information as it happened.

I think your consolidation of it all into one opening post in a new thread over there is much needed and a very good thing.

After work I'll update the original post here to point to the new thread over there.

 

@DanielQuick I think using E to bring up the shop menu is good.

Originally I wasn't sure if the player would truly enter buildings able to walk around. I was kind of thinking enter a building and at most the display changes to a backdrop of a sketch say a cube blacksmith behind a counter then the menu would be on top of that. When exit menu player placed back away from door away. Could still do that even with using E to begin it all.

Everybody has their preference. I just was thinking of ways to reduce the content requirements and don't personally see any need for more than text for merchant interactions... a quick sprite doodle backdrop be more than enough. But actually entering the buildings can work too.
.

 

@DanielQuick one thing you might want to add to the new thread OP is the version thing we sorted out. Just a note telling people we are using Unity 5.5.2p4 for this project.

I updated the OP in this thread.

 

I must say @Master-Frog that [Header("SomeText")] attribute I noticed when merging your source yesterday is very handy. Certainly makes working in the Editor more organized.

Now I am using it with such gems as [Header("WIRE-UP MENU REFERENCES")].

Also, that bit that @DanielQuick mentioned about using [SerializeField] to keep a field private and still show up in the Inspector is damn handy.

One of the things I disliked about Unity the first time I tried it out was all of the code I saw that was exposing all of these variables as Public just so they could be loaded in the Inspector. But maybe [SerializeField] wasn't available back then.

Still not sure if I prefer populating the initial Blacksmith inventory in code or doing it via the Editor. Code just seems much more condense and easier to me. But I'll leave it in the Editor (and in code commented out) for now.

 

A major point of Unity is to learn how to script your own editor windows, so you can automate tasks and save yourself work.

You make a blacksmith store script, I make a store component that I can add items to through the GUI. You save time up front, I can make a dozen more shops without breaking a sweat.

If you look at how I use a combination of serializable C# classes, collections and C# editor scripts you will see the Secret of Ultimate Ninja Power.

Public is a shortcut, it works when it works. Other times serialize works better. Other times, you need logic so you have to get into the immediate mode.

 

lol Ultimate Ninja Power eh?

Well I get the component development. Components are something that has been in programming (or at least software engineering) for ages... long before Unity. At its most simplest a class can be viewed as a component. And User Controls were in VB 5 20 years ago. lol But yeah Unity is heavily based on that for sure.

I am slowly moving into the Unity Way of doing this stuff. It's definitely different. But I am in no rush. Right now I am more focused (as usual) on just getting stuff done while also learning more and more of the Unity specific stuff in the Editor.

I do have a harder time thinking in terms of components when it comes to Unity for some reason. Seems like it would be easier to think that way but I think maybe my history kind of gets in the way because I am used to doing these things differently. I have to consciously focus continually on trying to do things in more of a Unity Way. So it is kind of like wrestling with myself. So I guess maybe that is the core challenge. It has been fun though.

I'd guess after doing a few projects in this way it will click. I do see people talking a lot about the Editor stuff and I am not into that at all other than trying to change my view about hard-wiring up stuff in the Editor. I am pretty much accepting and even embracing that at this point. And that was a huge thing. lol

 

Like I said, it's specifically about making tools in the editor that allow you to generate more stuff faster than you would be able to do it on your own, by eliminating the need for scripting similar things over and over again.

I know you "get it" but allow me to explain anyway, just in case some people (who shall remain nameless) don't get it.

Right now in this game, nothing happens.

Let's say you wanted something to start happening. You would create combat and characters and all that good stuff. But then what?

Well, then you will want something like attack waves. You will want to be able to control the time until the next wave, the relative power of the next wave compared to the previous one, what kinds of monsters will be in the wave, where they will attack, where they will spawn from, what kinds of items they will drop, if they will have a harder boss type monster in their midst, etc, etc.

Now, if you wanted to, you could create a new class for each wave, which is probably what a lot of people would do. Create a new inherited class from AttackWave.cs, called ZombieAttackWave.cs, SkeletonAttackWave.cs and then put properties within those waves (maybe) that allow to choose the number of enemies, etc.

What I am saying is that is the worst way to think about game development in Unity.

What you really, really, reeealllyyy want to be able to do is instantiate a bunch of different attack waves *somehow* and tweak all their properties, with a single AttackWave script and somehow (maybe through magic) store all of these instances as prefabs that can be added to the game at any moment, whenever you want.

Imagine if you could do *that*?

Well, that's what Unity allows you to do. Create instances that can be customized, then saved into memory, all through the power of serialization. That's the True Ninja Power and, even though you "get" component architecture, I haven't seen you do that, even once and I would be so bold as to say, that's the main thing about Unity that most people don't understand.

 

Yeah I think it will just take some time. It sounds like you are talking about making very generic systems. I do it sometimes (work projects but not really in games). I am not too fond of abstract generic stuff in general. Mainly because so often people end up building these overly complex systems for simple stuff. But this is also very much a matter of personal preference and there are pros and cons to everything. At it's core it sounds like you are maybe referring to implementing the Factory Pattern in the Unity Editor or something along those lines. But I don't know.

Right now I am just trying to switch back from purely procedural-based programming to OOP, interfaces and all of the other stuff I ditched last year and get the basics down of working in the Editor for game dev. lol

 

this is more or less an example of what they are discussing , in on one of my projects i made this simple spawner , such that i can edit/create/add waves spawners in my levels , first i create mini waves , i then save all mini waves as prefabs each , then i use the same script component and create a complete level wave that spawns the mini waves , check it out .

this way you code one time and create a bunch of things of the same piece of code .

you may use it if you like the concept.

Code (csharp):

1.  
2. using UnityEngine;
3. using System.Collections;
4. using System.Collections.Generic;
5. using System;
6.  
7. //example hard coded spawn positions
8. //can be integrated as vector3 in spawner class ,instead of this as an array
9. public static class spawnpositionholder
10. {
11.     public static Vector3[] SpawnPositions=
12.     {
13.         new Vector3(-15,1,-20),new Vector3(-12,1,-20),new Vector3(-9,1,-20),new Vector3(-6,1,-20),
14.         new Vector3(-3,1,-20),new Vector3(0,1,-20),new Vector3(3,1,-20),new Vector3(6,1,-20),
15.         new Vector3(9,1,-20),new Vector3(12,1,-20),new Vector3(15,1,-20)
16.     };
17. }
18.  
19. [Serializable]
20. public class spawner
21. {
22.     public GameObject spawn_this;
23.     public float spawn_after_time;
24. }
25.  
26. public class WaveSpawner : MonoBehaviour
27. {
28.  
29.     float timer=0;
30.     public int spawned=0;
31.  
32.     [SerializeField]
33.     spawner[] spawns;
34.  
35.     int index=0;
36.  
37.     void Start ()
38.     {
39.     }
40.  
41.     void on_wave_spawn()
42.     {
43.         //pick a random spawn position from spawnpositions[] array
44.         Vector3 pos=App_Globals.SpawnPositions[UnityEngine.Random.Range(0,spawnpositionholder.SpawnPositions.Length)];
45.         pos.z=22;
46.  
47.         GameObject spawned_obj=Instantiate(spawns[index].spawn_this,pos,Quaternion.identity) as GameObject;
48.  
49.         spawned++;
50.         index++;
51.         timer=0;
52.     }
53.  
54.     float lastup=0;
55.     void Update ()
56.     {
57.  
58.         if(Time.time-lastup>=1f)
59.         {
60.             timer+=1;
61.             lastup=Time.time;
62.         }
63.  
64.         //iterate spawn times
65.         if(spawns.Length>0 && index < spawns.Length)
66.         {
67.             //spawn on time
68.             if(timer>= spawns[index].spawn_after_time)
69.             {
70.                 on_wave_spawn();
71.             }
72.         }
73.  
74.         //destroy this wavespawner
75.         if(index > spawns.Length-1)Destroy(gameObject);
76.     }
77.  
78. }
79.  
80.  

then somewhere where my level started i simply instantiated a complete level wave spawner of mini wave spawners for example :

Code (csharp):

1.  
2. public class level1 : base_level
3. {
4.  
5.     public override void level_start ()
6.     {
7.         base.level_start();
8.         GameObject wave_prefab=Factory.Instance.Create_Wave("levelwave1");
9.     }
10.  
11.     public override void level_end ()
12.     {
13.         base.level_end ();
14.     }
15. }
16.  

 

Ah yes. I do this kind of thing as well only I do it in code. Basically just defining certain "canned" things. Sometimes it is planned out. Other times it is through a process of refactoring code that results in the same thing. I think the only difference here again is the visual nature of it as far as instead of calling a method to customize parameters people are doing it in the Editor.

 

@wjbender your code and process is very similar to how I write things. In fact, Treasures of Ali-Gar works basically this exact way.

The biggest difference I think is you guys are talking about using the Editor. I jse the same approach (within reason) only it is not done in the Editor. ToA for example uses a tile map. One of the layers has the possible positions of the enemy soawners. Those are pulled out and an EnemySpawner is created at that location.

Basically apples to oranges. The general process is the same. Implementation details vary.

 

yeah , there is so many approaches that yield the same result , the approach, being a choice of the circumstances involved .
time ,effort ,complication ,functional requirements etc , i say if it works well for the scenario and you are comfortable working with it , then do so .

what matters most is those "core" aspects of the code that really need to provide most of the important functionality the game is going to be doing on a regular basis , in such cases i think what masterfrog was/is doing , is very usefull from a developement and functional point of view , i read what is going on here from time to time , at this moment it is the most interesting topic here for me .

have fun and hope to see what jumps out of the box.