Day: Feb 11, 2019

Wow, that’s some title. This paper is more than I need, simply put. Considering where I have come from in the recent period of time and the fact that I still feel that I am on the back foot with just learning how to code properly, I don’t think that the milliseconds of delay caused by launching an app using a virtual machine are really the main concern for me right now. I am starting to appreciate the open nature of the course and the fact that I am being encouraged to find out what I need to focus on and get to it. In that light, this is too performance specific for me to spend a lot of time on. I’m not one pretend to have looked through things I have not, whats the point? So, I just wanted to put a short post here to say that yes, I did look at this material and scan enough of it to know that its way down there in the details and the numbers. I am more interested in putting time into understanding good program design and learning the vocabulary of game design and implementation.

*Update

I might be completely wrong here. Its possible that this is exactly the right time for me to look at things like this. After some reflection over the last day, I came up with two reasons why that might be. The first is that yes, I am at the beginning of the journey and so I am not tied to any one way of doing things when thinking about mobile app development. I still have decisions to make and should consider as many factors as I can. I think that the root of the real issue for me is there. ‘As many as I can’.

I think that I feel a little overwhelmed by things at the moment and I have learned to take that feeling seriously and solve it in a practical way. The way I tend to deal with it these days is to actively downscale what I am doing, focusing in on the things that I know to be important and reducing my attention on things that I think are important. So, while I know that I need to learn another language, I think that there are more obvious considerations (and only limited space for them) like the popularity of particular languages or, more importantly for me right now, which languages work with which game engines. I’m not saying that I am right in seeing it like this, just recording that is how I’m thinking about it. The popularity angle leads to Java, JavaScript and Python (depending on the source) and from the game engine perspective it’s just C++ and C# for the engines I am interested in (Unreal and Unity).

The second reason (remember, there were two…) is that I am interested in making games and they are notoriously demanding on hardware. In that light, I should really be paying some attention to the details of how they perform given different platforms and so on. Maybe I’m just a little flustered, and I do tend to take things very seriously, although my writing style often suggests otherwise. I may come back to this article once the App Jam is completed as I feel that is going to be an intense task over the allocated 48 hours.

I also don’t want to appear dismissive of the recommendations from the teaching staff as its obvious that they put these resources together for good reason.

Paper prototyping is one of those sensible, low cost, low-risk activities that I rarely (if ever) do. It’s funny really, as in thinking about the content of this post, I can think of more than a few examples from the Serial Link project I am working on, where a simple paper prototype may have cleared up communication issues between team mates and possibly identified other less obvious issues.

I seem to have itchy fingers when it comes to implementing ideas. I get some thought and think ‘yeah, that would only take this and that and then a little tweaking and it would be there…’ Four hours later, having usually had some fun, I find out that I have designed (I use that term loosely) and implemented things in a way that makes the next obvious improvement to the idea difficult or impossible without structural changes to the implementation I have already done. I have learned to think more thoroughly about the possible extensions to whatever idea I am having and I have on occasion, mapped out the logic that I intend to use. I know that software development is iterative, but I know that I have had times where another ten minutes with paper and pencil would have saved me two hours in Unreal undoing and redoing logic to facilitate something that I really could have seen coming. I am getting better at this though.

Gameplay prototyping

I suppose that my first thought about how to apply paper prototyping to the Mobsters Vs. Barbers concept comes more in the form of a storyboard but maybe I’m missing the point. I’ve just had a shower instead of sitting here overthinking this (I tend to do that). A couple of things occurred to me. The first is that it’s obvious that paper prototyping is worth doing and the second is the reason I have been slow to catch on to it. I’m immature. As a developer I mean. I am only now having experiences that seasoned coders would call ‘fundamental’ (probably). I’m talking about Edge Case Thinking. I totally just made that up but I think it sounds pretty cool so I want a pound every time someone says it. Its that part of you that has spent three hours on the edge cases of a simple task like ‘play a clattering sound when the weapon hits the floor’ because you’re still learning what the problems are as well as how to solve them. Ok, what if the sound is already playing? What do you mean by ‘Floor’ in this context? Should it just play once? But what if it bounces? Should it play when something hit it? What if it just moves a little bit? Play the whole ‘I just fell six feet’ type sound? Should I track the velocity then? Is that expensive to keep testing at run-time? Should I use continuous collision detection? Shouldn’t all this really be in a base class? Oh my, I should redesign the weapon implementation to use class hierarchy! Geez, all I wanted to do was play a sound.

Get to the point

The point is, sometimes when I think something will take a few minutes it doesn’t. Experienced developers know this. I think that they would be the ones that say, ‘hey, lets not worry about all the if’s and but’s and lets just draw this on a bit of paper, assume we can work the details out, and see if we still like the look of the basic thing that this feature is supposed to provide’. That would be a very mature thing to do.

And so, with that in mind, I would apply this to the Mobsters Vs. Barbers concept by mocking up each screen initially, menus and so on, and then every major action in the main gameplay loops for each of the teams. Then I would ask some testers to have a couple of goes at it and see what they said. I think that the project would be so very early in its development that just listening to the first thoughts that your testers have would provide more feedback than you could implement. I would worry that more complex games that relied on multiple game systems would be very difficult to test in this way, if not impossible so I would reserve this for sections that are easily contained (inventory traversal for instance) or games that are very simple like Cut The Rope and so on.

I must admit that I didn’t really understand what the ‘remote context’ part of the question meant. If it was along the lines of ‘how are you going to test this remotely as the testers are not in the room’, then that sounds like a video chat, but that would just put a boundary between the player and the prototype. There is no location-based functionality like GPS in the idea that I described so I would hazard a guess that I would not use a remote context at all.

Next up for me is this short lecture on Lynda.com where I hope to have a couple of bubbling little questions answered. I have never looked at App Inventor so I am interested to see how is does its thing (I’m already pretty clear about ‘what’ it does and its kind of in the title!) The interesting part about this is that it’s not just a learning tool like Scratch but is a tool that can be used to develop things you intend to deploy.

So, the reason to watch, read and otherwise consume these learning materials is to, well, learn. However, I am still finding lots of things that I have not heard of, don’t know about and am interested in. The problem that I am experiencing is that everything that I’m coming across looks like something that I want to spend some time with only there is not enough time. This feeds right back into what the Doc was saying in the introduction videos. I need to be clear about what I want to do and then branch out (little programming joke there…) into areas that strengthen and compliment that. I am really trying to get through all the recommended reading and watching though, as I need to be as sure as I can be that I am indeed making the right choices when I select what to focus on. I still know that its C++ and Unreal but there is a nagging part of my mind that is telling me to become proficient with something that can be used for mobile development. Something easier than C++ though, as I’m sure that could be used.

I really like the way that App Inventor allows for such rapid deployment onto a test device. I was not expecting it to be that straight forward. A little setup and a QR scan later and there is a cat on the instructor’s test device.

This is pretty cool and I hope that there are other development environments that use this so that when I do (and I think I will have to) get round to doing some mobile device development I will be able to test the deployed version this easily!