Hello Fredrik, your friendly neighborhood Fredrik here.
So if I got this correctly, you have one prefab for each spawnable, and some of theses prefabs are in turn collections of other prefabs, parented to a ghost object? Makes sense and is pretty neat, though there is an improvement for the interface. First though, your explanation that you made a ”separate script to create formations based on the position relative to the center of the formation” is unclear. If the problem is that the updates to the subprefabs don’t propagate through the hierarchy of an already saved superprefab, why would such a script help? Are the positions/objects saved externally and then constructed upon loading the level?
Anyway, here is a fun little function you might like to know about. Resources.Load(”prefabname”) will return any object that is located in a folder called ”Resources”. Could be /Resources, Prefabs/Resources, Sprites/Resources etc. Doesn’t matter if you have multiple either. Set up an enum that maps to an array of strings containing the names of all the prefabs you want to spawn, and replace the ”public GameObject toSpawn” with ”public SpawnEnum toSpawn”. Plug that into Instantiate like so: Instantiate(Resources.Load(arrayOfPrefabs[(int)toSpawn])) and hey presto, you now have a dropdown menu in the inspector! Doesn’t get more user friendly than that.
Hey, I remember this! I think I was the first person to sit down with you and immediately broke your game. I thought it was the mouse that was busted, good to hear it worked out.
I’m actually not sure what the artifact being presented is. Playtesting? I suppose the teacher will be the final judge, but I feel like this falls outside the instructions. Maybe if the playtest procedure was explained in some detail, but this is just “playtesting is good”. I don’t disagree with that, but it’s also not a work report I can really review. I’m sure it was a great learning experience for you, but I didn’t learn anything from this. Maybe you could explain the setup of and thought behind the playtest, or explain the solutions to some of the problems that you found. Or what caused the fullscreen problems you were having and how you solved that.
Hello from summer! Just getting back to this stuff on the eve the hand-in.
Well, this post explains what scrum is and how it works just fine. Perfectly apt intro to agile and scrum, explaining the hows and whys of scrum development and even some pitfalls to look out for. It doesn’t really touch much on the actual question “how has scrum affected your development?” until the very end but I’m not counting words.
The post should probably have gone more into how it went, as at the time of its writing most of the project was behind us and the boat would have been if not boaty at least boatish, meaning we had plenty of experience with the framework and could review it not just in theory but we could actually go over what had gone well or poorly as well as what we had done right or wrong.
I rate this post buoyant/10.
Hello hello, sorry I’m late.
This is a very good explanation of the thought process that went into designing this simple AI. Although I can’t help but feel that the chosen solution is a bit unambitious and there are some very simple refinements that would clean up the code a lot, it also feels weird commenting on code structure so late after the project, when you yourself have probably learned enough to expand the AI or perhaps even did so before release. The solution which is shown in the blog post is still quite detailed with good pictures and explanations.
Also, good link, thanks, always nice to learn something you haven’t used yet.
The why of the design is also very well explained going into the design of the game and the resources and knowledge available to you to argue for why it was designed this way.
Don’t mind me, just finishing up some leftover work, move along, nothing to see here.
The post explains that playtesting was done and gives a few examples of where the game was changed based on feedback from the playtests. Primarily, as it also was for us and I know many others, this ended up being the games instructions. Seems a recurring theme that you think up some elaborate scheme for how the game functions and the stupid player sits there not getting it. Perhaps some material on proper eye-catching and intuitive UI design would be in order. I suppose us programmers will just have to hope the graphics design students get that lesson at least.
Perhaps a few more words on why you did the tests this way, or why you chose that question? Not that I can’t imagine it pretty easily, but it is missing from the blog post. Also the post could easily include a word about how you as a group thought about the playtests and the feedback you got from it.
Last post of the day/course/semester. Feels so good to finally be done with it.
Sad to hear the project left you so drained. Hopefully the next game you made was more engaging. I can definitely appreciate that a slackish attitude at the start of a project can poison the whole affair. When working solo I sometimes start comparing progress to other less productive weeks and let that low bar gauge how well I’m doing(that I am posting this less than two hours before deadline on third hand-in however is a pure coincidence). A dangerous thing that I think can only be solved the prod way.
I don’t think I ever played Fear Is In Me, so I can’t really judge how well it turned out. I would say however that the most important thing to consider is how far you would have gotten if you were given the task to start all over. That is a good measure of time spent learning versus doing chore work.
I’d wish you best of luck for arcade, but that would be four months too late.