rayhan96-blog

[rayhan96-blog]

Project Evaluation

So here I will give an overview of how the game went so far, and my overall opinion. In particular, the game itself, and later on, the team I worked with.

Game

So the game had many ups and downs, we started off very slow, and many of our original concepts were not quite up to shape. The prototyping phase really helped us out, it took us 3 attempts to find the appropriate game for our setting (you could see in the previous posts, prototype C was a nice improvement over the rest).

Our main progress point was during the middle of the semester, it was then that we put a ton of effort in the game (from around week 6 - 9). We didn’t do much else other than focus on the game at the time, so we really did good then.

At the end of the semester we laid off a little, so that’s when the game slowly fell back a bit.

Team

Programmers

Our team had good communication, but all of my programmers had doors in their ears, so as to say that they’d choose when they’d want to hear from you and follow your instructions. This is not to say that they ignored throughout the semester, this is not true, quite the contrarily in fact, but they were never readily available.

The amount of reliability in a teammate really matters, and this is a scale made up of programming experience, friendship, collaboration and more. However, more importantly, it’s the ability to turn up on time, and always being there when called upon, and this is where both my teammates fell short.

This aside, their contribution has been of great use towards the game, and I reiterate that the game wouldn’t have been the same without them. Dan did his contributions, and so did James, and were both deserving creators of this game.

Roles

James, the lead programmer, did good for adding game mechanics and UI, though admittedly takes precedence the fastest route over quality (as seen with his rain mechanic). His contribution to programming was more so than his audio, which he unfortunately did not put much effort in, at least no more than a first year student could’ve done using free sounds (no intention for being harsh, could’ve used a little more effort, but again I understand the module was not audio based).

Dan was a great leader but often laid back and lacked the voice due to his lack of experience, though he did surprise us during the presentation phase of our game. His contributions to the game itself was low, having created just the mechanic for dragon shooting and a few UI/main menu, but again offered what he could in his skillset. He tested the game thoroughly and was a nice guy to talk to in free hours, so a good leader overall.

As a designer, I took note of ideas and noted it down from many different sources. I tried to do more than expected for the role, and debateably did more programming than the lead programmer. I coordinated art, and would get a hold of other people just to gather ideas for our game. Throughout the development process I would work my way towards a more innovative game each week, and whenever my teammate backed out, I was left to pick everything back up.

Artists

For our artists we slowly noticed a slight variation in skill, some are amazing at 3D modelling and some are not. This explains some of the outliers in our game (hint hint flameball). We also had to sacrifice a lot on programmers just to get the art up to speed, so for example me and James was sidetracked to working on the clouds and fog from ground up just to have another game level, something we really didn’t want to worry about as programmers (though the experience gain from it is nice).

Our artists were willing to do most of our tasks, and were certainly more reliable than my programmers, in that they created all of the art assets that I requested. However, I slowly noticed their lack of will power to learn, particularly on the rigging, animation, and particle effect side of things. They are good at what they do, but that’s the limit, they refuse to learn in order to help you finish an integral part of the game. This is very different from my programmers, who went from hell and back in learning new code and game engine theories for the purpose of the game.

Overall

Anyways I hope this doesn’t come across as too harsh, I love my programmers and artists, but they both have their flaws that really start to show in 12 weeks. If I am to evaluate myself, I’d say that I am very reliable, and adaptable to change, and did all I could in order to make this game succeed. In a way I acted like a secondary manager to all, as I had access to artists and programmers. I’m sure everyone would agree, I do my best to support my team regardless of difficulties.

In the end I was quite happy with the game. There are a couple of things that I wish we’d done, and a couple that I was proud of. All in all I’m sure we all learnt a lesson, from how optimisation plays a key role, to how important game design can be. Our game was heavily affected by these two main factors. So below are the key bullet points for this evaluation:

What went well

Art style

Role of cloud section well implemented

Programmer related art i.e. cloud, fog

Implementation of feedback from different testers

Procedural generation - randomised, efficient pooling

Fun gameplay with difficulty ramps, incentive for player to carry on via achievements and leaderboard

Use of discord and Facebook for communication

Trello on both sides

SourceTree for version control

What didn’t go well

A little more game mechanics couldn’t hurt

Purpose of ground area a little blurry

Too many ideas taken out, having the ground as a lootable area and cloud as survival could’ve been great for game mechanic, and incentive for players to store items before survival begins

Difficulty a little too linear and generic

Instructions for players in-game could’ve been a great opportunity for new players, and help them understand what was going on

Wish we had a more professional software for conversations other than discord and particularly facebook (artists’ fault)

These are some of the main few criticisms in my opinion. I would say a big and critical one is the implementation of game mechanics and content. One of our greatest pitfalls is that we focused on the art way too much, and this unfortunately led to less mechanics, and more art.

When a game starts looking more like a movie you definitely notice something wrong, games are meant to be fun first, beautiful second, and this is where we overshot the most. Through having learnt that, “in the future we will have a deeper focus on game design, mechanics, and content, and have art as a close second at most”.

That said, we will certainly carry on with the game and its’ optimisations for hopeful release on mobile and greenlight on Steam. Below will be a current build for you to try, and disclaimer:

Final Week 12 Game build: https://1drv.ms/u/s!AlHqenFxGZxTgRogpTwmzVqAG-pQ

Any concept art I use in this blog are not my own and so belong to our respected artists at: https://trello.com/b/GTWtcNkW/aeonfold

[rayhan96-blog]

Week 11/12 - final presentations

For week 11 and 12 I’ve decided to put the blog post all in one, seeing as we only focused on the presentations in these last few weeks.

Week 11

So for the first week we spent our time preparing for the Friday presentation. On Tuesday we met during the afternoon, mainly practicing and doing final polishing to the slides created during Easter. Me, Dan and James got a hang of our positions, and added a few more slides particularly in our interests for publishing on Steam.

Wednesday we had a day off, editing from home. I went to the C++ lecture, but worked on the presentation again shortly after. Thursday was the final day and we ran a discord chat presentation just for practice, we knew Dan couldn’t make it to uni so we figured an online presentation would serve best.

Friday came round quite fast and we came early for the presentation. We met and talked a little, we were all a bit nervous to be frank. Once our time was up, we went through our game in front of the class. I did stutter a bit at one point, and maybe we sounded a little scripted in certain areas, but other than that we did alright.

Also our gameplay video cut out on us, it was quite laggy and really it is our own fault for not testing beforehand, so this is something we’ll have to improve (though to be fair a few other groups experienced the same issue, but still the fact that we saw some with working videos show that we could’ve done better).

Other than that however, we worked on a few artist request that was sent out to us. The artists came in so we worked a bit on Friday changing stuff such as the Main Menu layout, GUI text colour and adding lilies in for their coming presentation on Thursday next week. Once we were done, Dan sent his game in, so we were pretty much complete at this rate.

Week 12

As art coordinator I do make it a habit to keep sending new builds to the artists, and it pays off sometimes. They do act like testers sort of, when they manage to make the time. On Monday they figured out that our instructions menu and achievements would crash the game when activated, so I went on to fix that.

It turned out that on Friday while implementing our fixes we forgot to change the setActive value of some of our items to true, which was a very minor fix, but severely impacted the game main menu (hopefully Dan didn’t submit it as it were, game worked fine, just the how to play and achievements section in main menu would not work).

Thursday the industry people came in for the artist presentation. I made sure to add a final music to the main menu, which the artists have just created. Overall the presentation went well, James couldn’t make it, Dan didn’t come either, but this was expected as he told us previously. The artists managed it pretty well, and we did learn ways on how presentation plays a big role in selling.

Feedback were generally aimed at presentation skills (mainly for artists, it was their presentation so I tried not to interrupt), how dark the game would be on android, and in-game instructions to help the player. Overall it went quite well and was a lot more relaxed than ours, since they didn’t have to stand up in front of a class, though to be fair the audience did ask a lot more questions than our class.

Anyways Friday tomorrow is the last lecture and practical, so I’ll go to these to meet up, I know I was a bit busy with the presentations, but hopefully I can get a grasps of what the future holds for us.

I do plan to have this game optimised for mobile phones at some point, and surely a Steam upload, so this is not the end! but I will have to call it one for now, and submit this assignment tomorrow. My last and final post will be an evaluation of the entire project, so you will see this right above this post.

[rayhan96-blog]

Easter

For the Easter break we laid off a little, I in particular spent more time on my C++ module, while the others did a mixture of this and audio module, as well as time off.

The main things we did this Easter includes adding the rain effect for the water pickup, and a few GUI bug fixes introduced in the previous week. James was in charge of this, while I added the trees in on my spare time.

This reminds me, we both do programming, but generally I’d focus on level design, while he does game mechanics. He’s assigned to audio as well, so he develops the music too. One of the artists have connections with a few audio people, so we do get cool original audio for our game.

Dan is a good leader and updates trello, he is a good tester for our team as well, but generally doesn’t do much programming, which is my only gripe. Personally as a teammate and friend-wise, Dan is a very nice person to talk to. James is not the type that I would hang around with (well maybe not to this extent, but he is a bit hard to read), he is a little self centered, or at least that’s what I’ve learnt.

Anyways I’m not one to rant, we work alright despite this, and I don’t think I’d make it this far without them. I do believe that my design role was a bit overloaded, especially on the programming side, but I’ve learnt that no matter the role, you have to be a bit reactive to change, especially if you want your team to succeed and your teammates’ workload to be even. It makes you more reliable to others.

Last thing I want to talk about is the final presentation coming week 11. Dan has done very well to organise this, as I say, he is brilliant at written work but could use improvement for coding. He created the base presentation for us to work with, which me and james edited out in our own time to include stuff we - individually - would talk about. I built up my game design slides, while james did the elevator pitch and market release sections. We didn’t have time to meet up, but we practiced the slides together via discord chat a few times once we were done.

Artist at the time too was also relaxed, really they have all assets done, so it would be hard to expect otherwise. They added reeds for our water however, so I hope to add this soon.

[rayhan96-blog]

Week 10

This is the last week before Easter, we listened to feedback, and made sure that the game was ready to show for Friday.

So on Monday I came to the practical to try and make the bombs spawn in rows, I was also planning to add the new cannon assets the artists just created. It was a bit of a leap as we shouldn’t really be implementing new mechanics at this stage, but I also did want the ground area to have a bigger purpose with cannons shooting.

Gary came round and gave me ideas on how I could improve the game, so I noted it all down for me to remember. Basically to make the ground to sky movement smoother, and also suggestions that cannons could be a possible decoration rather than shooting. In the end of the day we are kinda late in development so I do agree with this, if you ask me though, I wish we did more for the ground in the beginning (shows how important pre-production phase is right.. no going back now).

Tuesday I returned to the practical after having finished the bomb rows last night, and spoke to the artist about how we were still having trouble with the 2d trees. After discussing for a bit we decided that I would look up a few unity standard asset prefabs and see how they create trees, and perhaps try to implement their techniques with our own trees.

I then spent the rest of the night finishing up on ground/air transitioning, making sure that the scroll and wind pickups are the ones that determine player position. Therefore having the game level changed based on pickups rather than timers. Afterwards I sent the game to James giving him a few info on what we need design-wise.

Not much to say for Wednesday as I focused on my other modules at the time, but by then James had finished adding rain and blinding effect for the fireworks. The rain is only there in visual form however, and water pickups don’t activate rain, at least not at the moment.

Thursday again I carried on with my other modules, its getting nearer to the deadline so we’re all focusing on time management between our modules. However I did get a tiny bit of time to fix a build error in our game, every time we got to the cloud the game would freeze. It took me a while to figure it out but then I realised that we may have added a little too much particles for the cloud (I forgot I increased particle burst from 5 to 10, worked fine in the editor, I guess the build doesn’t like it).

Friday we came in our practical for some last minute changes, James couldn’t make it so we had to make do. But anyways the presentation went well, way better than last time. People liked the red glow for the bombs as well as the improved sky level transition, flash for fireworks was a little disorienting for most, but bomb rows of 3 have been noticeably effective for putting use out of the dragonbreath.

Main points of feedback were to make fireworks do something other than blind i.e. perhaps disable movement for a bit instead. Also the fireworks were a little hard to notice as a danger. Finally a notable bug captured by one of our testers was that the leaderboard would sometimes show the first ranked player twice, definitely something to fix. People particularly showed interests in the art style, though this we didn’t change, it was the same as presented last week (however we did add small islands in the background).

I just wanted to say that we didn’t have a practice presentation on Tuesday like we hoped for, will have to talk to Dan about this as he never gave us the update on trello. Anyways below is the summary for the 2 weeks:

What went well

Presented new sky mechanic

Final polishing to the game

Bomb now spawn in rows, more use for firebreath

Jump now smooth with animation

Presentation skills improved

New effects for all abilities, no more lanterns without purpose

A few other new content such as achievements and rain, though the latter is not in-game yet)

What didn’t go well

A lot of ideas were dropped out i.e. cannons, elements etc. due to time remaining

Couldn’t do practice presentation as planned previously

Ground has less of a purpose than I’d hope

Wish we kept glow specific to lanterns, but everyone does seem to like it on bombs

What we/I could do to improve

Our game was a little too ambitious I think, we didn’t account that we have 2 other modules around the corner so now we have to make up for this, this game has a lot of potential, but in the end we are making a vertical slice so I guess it evens out

We will have to make do with presentations during Easter as the final presentations are both on week 11 and 12

[rayhan96-blog]

Week 9

We are now nearing the end of our game, it looks really good, and we just need a few more mechanics to finish up.

So on Monday I came into Gary’s Monday practical to clean up the game, specifically fixing a few bugs and noting down any outstanding work on my todo list. During the day I fixed a couple of bugs such as cloud level starting before game begins, leaderboard not appearing occasionally, and sky speed being too slow. Later on I met with one of the artists to fix a few of the UI issues, keeping it to their ideal vision. We also added a few assets in together such as the transparent dragonbreath icon and added glow to the new pickups wind and water.

Tuesday I came back to Gary’s lesson, this time I needed ideas on how to add animation and trees with alpha in the game. I got round to the artist, luckily they were around so we went back to Gary’s class to hopefully get all this sorted out. After a lot of back and forth fixes we managed to figure out that the animation wasn’t set up correctly on the artist side, once that was done, we had a talk with Gary and got a basis of an idea on how to integrate the animation to unity and a few ideas for trees as well.

Once I got back home I watched a few videos on how to do the animation and got along pretty well, I’ve used unity’s animation editor before, just that I needed to brush up a little. However this is my first time importing animations, generally I’d simply animate text or an existing gameObject, so it was quite a challenge at first.

So in the end I added the animation for left and right, as well as the jump. I decided to make the jump controlled entirely by animation, as seemed a lot smoother, so I scraped my old jump script. The way I did the collision then was quite nifty, as I added the collider to the head bone, which would allow the collider to move with the animation. It’s funny since I wouldn’t have known this if I hadn’t previously taken the 3D Modelling module I did last semester.

Afterwards Dan added the fire, wind, and water icon with cooldown included for the abilities to come in our game. We still don’t have clear plans for them, but having them there keeps us ready, so far I’m thinking of giving the water ability to activate rain and turn off lit bombs, but I’m not exact as of yet. We definitely scrapped the elemental dragonbreath idea though, we think given the little time we have it’d be best to keep with the original fireball and super idea, and have the elements as separate passive or active button press abilities.

James did a little bit for adding achievements in the game, and then adding them to the main menu and in-game. It’s nothing much so far but it’ll do for now. On Friday we managed to quickly brush up on the game, I added the stuff I did on Thursday to James’ version, such as no cutting between animations, fixes to sky being too fast in comparison to ground (difficulty ramps up too fast) etc etc.

We did as much polishing as we could before presenting later that day. We presented our game and got a few feedback, such as bombs should appear in rows to give purpose to the flame, and sky transition smoothed out better to less disorient the player, as well as bombs and firecrackers better made to differentiate between the good pickups.

My main worry however is our presentation skills, which I really think needs improvement. The thing is we talk too much about the game and less about the audience. Sometimes I even think we’re talking to ourselves rather than the people sitting in front of us. There’s no question here though, we even had feedback mid-conversation that our presentation skills needed adjustments. This is surely something we have to consider in order to properly present the game.

Dan has plans for us to come round and do practice presentations, so hopefully we learn from our mistakes by then. We will start doing these just before Easter, Dan’s already preparing the presentation slides for us as we speak, so likely by the coming Tuesday we will practice in one of the empty com rooms and then practice more after Easter. We know our weaknesses, and now just need to practice a ton to make sure that it all works out for our final presentation.

[rayhan96-blog]

Week 8 Alpha final

So we are now in week 8, the game has since been developing really well. During the weekend I spent my time mostly searching through the web on how to reduce lag (no lie there, I have never used unity’s profiler before). I managed to find out that the lag was indeed cpu based, as the system would more often struggle at higher resolutions than it would lower.

I did as much as I could to optimize the game, I ensured that every update had if statements and whatnot, I basically spent the entire weekend learning about the profiler, common programming pitfalls, intensive unity functions (i.e. raycasts etc.). In the end the game was noticeably less laggy but at the same time still could use improvement, as the occasional hiccup to 40 fps were still there.

On Monday the next day I worked more but at the university instead since I figured Gary was around to help. I learnt a lot more about the profiler there, as Gary knew his way around more than I did, there seemed to be a problem with something called “WaitForTargetFPS”. Besides that I continued to deleting as much empty update functions lying around, didn’t improve performance that much, but at least that’s off my mind.

Tuesday me and James went to a com room right after our audio lecture, we decided end this lag for good (we had it bad in the presentation okay.. the lag was tremendous). So after working for around 2 hours together, I can finally say we fixed it! So this involved deleting a lot of excess meta files created by our version control system, for some reason that was the issue. We did use a gitIgnore file but for some reason the meta files kept piling up anyways.

Anyways one fix after another, the game is now smooth. We capped the fps at 30 just to be sure, and I did have a feeling that it wasn’t to do with our code or art, as I did set them all inactive at some point and it would still lag. But anyways it is all fixed now and we are both very happy, we even tested it on the pc that we did our presentation in, and it worked smoothly! So we managed to add more content and reduce lag. It was funny when we showed Dan, he was clueless at first, as he never saw how laggy it was in the first place! (he couldn’t attend our presentation last week).

Ah well, we had a team meeting together later that day, Dan was off sick for around 1 week now, so it was time to get him up to scratch with what we have so far. During the meeting we did a couple of fixes to the game together, notably to the GUI and visual fixes as well as adding art assets in, really we couldn’t code in front of each other as that generally takes time, so we did what we could to polish the game. Dan left at around 3.30pm, but me and James stayed up till 8.00!

In that time we added a cloud particle system, and refurbished the game further by adding glow/lights to the bomb and lanterns. We also fixed a few texture issues, previously Gary noticed our textures being slightly stretched, so we added the resulting new texture from our artists to the floor and tilled the mountains x10 as the mountains themselves were scaled up 10 times the original size.

In the end we decided to finish off by going back to that presentation room and test the limits by going at 60fps instead. The game did suffer a little, but only at higher resolutions. 720p for example would give out the full 60fps experience. But hey we are more likely to make this game 30fps than 60 for general gaming.

Wednesday I thought up a few pseudocode on how I was to create the code for this cloud environment, really just thinking throughout the day. However this day my workload was mainly around the audio module I was also partaking at the time.

Thursday I put the code into action, the jumping is a bit jerky but the code for cloud is there, I spent the rest of the day gathering feedback and ideas for design. Came across Mario Bagnoli, and he gave good input for the game, particularly his emphasis on everything needing a purpose (i.e. houses could be shooting, bridges could use an enemy on top, collision with left mountains could be a possibility, wind power potentially pushing fog away etc.). In the end I relayed whatever ideas I received to the artists and my team, noting these as “possible maybes” once we finish polishing our game.

On Friday we presented the alpha, but I was pretty angry at the time as my cloud script relied on James finishing his part of the code, which he didn’t. He also didn’t turn up on that day, but ah well can’t say anything he did put a lot of effort in the recent days before. The alpha went okay, but not the best. Dan did his part in doing the water for our level which is cool, but other than that I didn’t get to showcase my cloud script.

During this weekend I completed the unfinished cloud movement myself, and yeah, managed to fix the problems. Also fixed the jerky jump and polished the original movement using unity’s Vector3.Lerp (linear interpolation function). James managed to add a leaderboard system using database, so we caught up well I think.

Sure being in this team is maddening sometimes but I wouldn’t have done it without James’ expertise in graphics, particles and now the newly added data storage system. Dan is good in that he always updates trello and do bug reports for us, and then the small additions to the game such as the water prefab. Coding definitely isn’t Dan’s strong suit but he tries more than other’s I’ve seen and is learning very fast, but yeah me and James generally cover more of the game and Dan does the paperwork ^^.

Other than that I should mention we use discord a lot for our communications, there we have a tab for general discussion, annoucements, resources, and more, all for fast an easy communication, sometimes we even decide to talk via live chat and work on the game side by side.

As for artists they prefer facebook and so as Art Coordinator I do stay in touch with them using their messenger group chat. Anything we need I ask there, and generally they do the same. They really are a good bunch and they are always a bit ahead of us. Unlike other artists they care about the game and arrange meetings quite often to see where we’re at. Honestly they do a lot to ensure we are on track.

This was quite long but it sums up the entirety of this alpha stage, below is the summary:

What went well

Chosen a prototype to go forward with (Prototype C)

Decided final roles (Me - Lead Designer/Art Coordinator, James - Lead Programmer/Audio, Dan - Project Manager/Tester)

New design ideas

Improved frame rate

New content, especially artistically

Team working well together

What didn’t go well

Framerate issues (fixed)

James couldn’t complete sky level (fixed later during the week)

Lots of new ideas now to implement

Couldn’t show sky transition in presentation

Jumping a little jerky still, body looks too rigid while jumping

What we/I could do to improve

Prioritise on the mechanics that worth implementing first, then do others

The presentation next week is a good opportunity to show the working sky

Hopefully once we get the animations, jumping will look much better

[rayhan96-blog]

Week 7 Alpha

Hello, so we are now out of the prototyping phase, we decided to go forward with our third prototype, as it had the best gameplay and a range of opportunities for improvement. The others were good, but were off course from what we wanted, which was an oriental environment with a flying dragon. The others just didn’t have a fitting theme attached, or at least we couldn’t find a suitable one for them.

Despite having done most programming thus far it has been decided that I would be lead designer and art coordinator, particularly due to having created most of the level in the game and implementing most of the artist assets. Daniel would be our manager and tester, for being the best at time management/quality assurance, and James the programmer/audio designer for working the most in terms of game mechanics and audio.

On Monday I had a meeting with the artists to come up with a few design ideas. They wanted the mountains slightly bigger along with the bridges being aligned more properly, and a few other minor fixes. Other than that, a few more ideas came up such as pickups to bind element into the dragon’s fire, making it shoot water to turn off lit bombs, or wind to push out danger.

Monday was mainly spent brainstorming ideas for our end game, we decided to keep the cloud idea but scrap the underwater one due to time constraints. We will keep the survival idea and have elemental lanterns for varying pickups and abilities. Health is a good idea, but feedback shows it is more fun without health, though we may add it as an achievement reward.

Anyways on Tuesday Dan called a meeting for our team only, which was where I taught them on what the artists mentioned. We worked on the game together on that day fixing bugs and the canvas, but in particular that day was us updating trello making sure that everyone understood their roles and that none of us felt overwhelmed.

I updated our game to include the minor fixes that the artists wanted i.e. big temple/mountains, and then sent it off for presentation on Friday. However once we came into the practical James made quick adjustments by adding a fog effect and cell shading to further polish the game for the presentation.

In the end we got good feedback, notably regarding how to reduce the lag (which was a really big problem and still is). We learnt about lod, the importance of scaling difficulty, starting music with a slow fade, and adding more mechanics for abilities/pickups. Fixing bugs was mentioned as well such as problems with pickups spawning at the side and passing through the bridge, which should be fixed once we add a jump mechanic soon.

For difficulty scaling, hopefully once we get the cloud level in that would be enough, but so far it isn’t in the game yet. Our plans for the future is definitely to reduce lag, I am no expert but I have a bad feeling that our code is the problem, and so the bottleneck is probably CPU based. I will have to figure it out but this will be my priority along with the cloud level and jumping mechanic. We plan to get all mechanics done by next week.

[rayhan96-blog]

Prototype C final

Here we finalise the game to show for friday, so coming from last week I really wanted to make up for being slightly laid back. Our artists added new art for the ground, and had the dynamite pickup all ready, so it was time we started adding everything in and at minimum have the ground polished and the cloud ready to implement.

The artists added a mise en scene to help us in case we confuse their concept:

Fast forward to Tuesday, I added all I could including the revamped map. The game is now more polished, and I fixed a lot of bugs on my way there. Other than adding new designs such as random generation of bridges/buildings, I also made the ground plane spawn randomly, so everytime the player traverses, there’s going to be a different set of terrain ahead.

See this is where the artists did a really good job, because they added 4 ground assets, but all links with each other in any order, so I could easily make it random and this combined with varying building spawns, make the game look very different everytime you go past.

However as the artists haven’t started on the cloud environment I didn’t have a chance to implement it, so in the meantime I helped others by staying up on discord whenever I could and also fixed the movement of the player which I know James was having trouble with.

Dan added the fire ability I wanted, and included a working cooldown icon. He also made a few bug fixes to the UI and added instructions on-screen for the player. He was mainly the best help I got this week for building up core mechanics, as he should, he was the lead programmer. He also added audio to the fire effect, for being lead audio an all.

I know this week James had been dealing with personal issues which I guess seems legit, so he will not be coming to the practical this friday, but I do believe him and he does have high goals for this game, in the end he added the dragon asset, adjusted the camera angle a bit better, and fixed a few bugs.

We haven’t decided which prototype we are to bring forward yet, but if I were to choose I would use Prototype C as it is our latest one and has a more promising future due to it’s cloud/water/ground transition nature (even though admittedly they haven’t been implemented yet).

For designs I gathered ideas from a bunch of people including the artists, friends, other groups and Gary, and I’ve decided that the movement will be 3 lane only, just to make it easier for mobile phones. However I will also have a swipe up mechanic to allow the player to do a slight jump, just to keep 6 lane a thing, but not used very often. Besides it will also help make the angled view of the dragon a lot easier.

My plan for the cloud is to make it a survival mode area, where only bombs spawn be it dynamite crates or bombs. It will last for a short duration before the player gets towed back to the ground floor. This will give the player incentive to relax during ground waves and store as much power as they can i.e. dragon flame super, for the sky waves. The sky area will have it’s own score counter that displays the player’s prowess in the survival area, and may be increased by surviving, and/or destroying bombs/crates if feeling uber confident.

We may make pickups fly in more diverse paths to make things harder, and also have a health system for the game. This way we can add rare health items that glides back and forth between lanes to make it hard to catch, and possibly a wave of 2 bombs side by side taking up 2 lanes to make it harder for the player. Of course we can have these come up more often as difficulty ramps up.

In terms of powers we really need more ideas on what the dragon can do, but for now we are thinking of an upgrade system for the game, or some sort of achievement system which would - once achieved - give the player specific stat boost from the get go i.e. “You now start game with full fire charge meter”, “You now get an additional health point when starting the game” etc.

These are a bit ambitious but they are what I hope for in maybe the next six weeks to come, hopefully we can do as much as we can now that most of our level is already done.

But anyways here’s the summary for prototype C:

What went well

Level design for ground floor is complete

Everything is now in art form (except flame)

Workload is even

Great ideas for future

3 prototypes done

Doing good as art coordinator

Game modified to look like how the artists envisioned

What didn’t go well

Cloud hasn’t been implemented

Pickups are the same variety, 

Not many abilities in-game, fun factor isn’t there, or at least not yet

A lot to add before the game is fully fleshed with real goals for the player

What we/I could do to improve

Once the artist add their cloud art, we can add it in, but in the meantime we should add the code to make it work

I mentioned a few ideas above, these should help increase pickup variety, though we still need a few more to further increase variety

For abilities it is similar in respect to the above, but here is the real problem, we need to understand what more the dragon can do other than just shoot flames

[rayhan96-blog]

Prototype C

So this is the end of the first week of prototype C, for this prototype I was the Lead Designer and Art Coordinator. My role was to communicate with the artists, gather ideas, and apply these into the game.

For Design I came up with the idea of having fire-breath for the dragon (it was implied before, but never had a defined role), along with a super version that would destroy all pickups within a certain range. As a result of this, we decided to include a dynamite crate which will be destructible by the standard flame, and keep the bomb as indestructible unless using super.

I also thought of a cloud environment that would offer a new playstyle with new pickups to play with, but for now it has been decided that the water area will not be included, at least not until we have the extra time after everything is well polished.

For art coordination I logged into our art team’s facebook group. Dan left as he was now programmer and lead audio. It was a bit funny at first, as the artists had no idea why we kept swapping roles, but they quickly got used to it and we even managed to learn a bit about each other’s module actually.

So working with artists went pretty well, and even had a meeting with them on Monday (just me) to sort out what we wanted i.e. area in the clouds, possibly water level, 6 lanes etc. I guess because I was more active on the chat, updates to the artist on the game’s current status improved, and also because I was the one who always implemented their ideas and art once they put them out.

So basically being designer I decided to do programming specifically based on level design, which is good, since most of my recent programming has been related to procedural generation and the level itself. I added the art in, there was no ground asset so I had to make do for that, but everything else such as the pickup asset, bridge asset, bomb asset and others were implemented and coded in the script.

Things didn’t turn out as expected though, as on Friday when the artists saw the game, they realised that our bridges were the wrong way round. So this is something to fix for next week.

Other than what I’ve done, Dan has been programming extras in the main menu such as instructions, and focusing on the few bugs that came in. Meanwhile James started on the new bug report and put up a few orders on trello, as he was now the manager and tester.

We didn’t do too much this week, last week was pretty tense with the guest coming and all, but we made a step in the right direction by adding the art in and fixing a few bugs. Overall the work is definitely more spread out now, but I hope for next week to do a lot more and possibly change the camera angle, add art correctly, and all in all have a nicely polished game for Friday next week.

[rayhan96-blog]

Prototype B final

So the preparation for the presentation, this week was a combination of pain and excitement as we heard that a special guest would be coming for our practical.

As promised from last week I was determined to get my team in shape, so I put up my concerns on the discord announcement page, and even used trello to give out new orders, displaying the high priority that is our unofficial meeting on tuesday. Needless to say we all attended and I must say it is one of the great reasons to having friends as teammates in a group.

I went through the generation code with them, and surprisingly they understood very fast, I even managed to learn a few things from my own code!

I explicitly pointed out these key points:

How to add new pickups to the existing generation code

How to add new floors/background for the map generation

How the generation for both of these work, both in the editor and within the script

And finally a few conventions we decided to stick to i.e. having pickup scripts and platform scripts in different folders (our scripts were getting a bit out of hand)

In the end dan managed to add a bomb pickup + game over script in his own time at home, and james worked on a score system for our game, so this meeting was definitely well spent. By Friday we had mechanics fully built into the game, and we decided to scrap the “free-flying” mechanic and add lane restrictions for the player instead.

I guess I was partly to blame for not having the meeting sooner, and also I understand it must’ve been hard for james to settle as lead programmer, but he definitely made up for it in that last week. We managed to show a well made prototype on friday and actually get pretty good feedbacks!

So right now, our plan is to add the art in, fix all of the current bugs, and change the camera angle. Once the artists are done with the dragon + rigging, we also hope to learn more about using a rigidbody system for the head, in order to make the body somewhat follow the head's movement. These were some of the feedback that we received from the guest, and hope to implement in the coming days ahead.

The plan for the next prototype is to add some sort of second level for the player to transition to, a cloud/sky level to be exact. So right now we only have ground and it's been like this for both prototype, but hopefully if we add ground, water and air transitioning, the game will be more engaging, especially if there are a unique gameplay pattern to each of them.

So below is the summary for this prototype:

What went well

Management was great, team now know how to modify game, and conventions to stick to

Team working together towards finished game

Have nice plans for next game

Version control up

Lots of bugs recorded (7, I will add it in a link below)

Game has improved from the original prototype, lots of new mechanics added

Communication with artists improved

Feedback and ideas from Friday

Workflow has definitely improved, everyone has done their fair share of work

What didn't go well

Game art has not been implemented yet

Many bugs now to fix

Hard to see ahead when the player or pickup is at the top lane and close to camera

While the game is fast-paced and fun right now, it is a bit lacking in mechanics and incentive to keep the player engaged for longer

What we/I could do to improve

The artists have already uploaded their models up, it is a good idea to turn them into fbx and start implementing them as soon as possible

Bugs should be fixed depending on priority, as always progress is more important and bugs will probably be fixed along the way, but keeping an eye on them will ensure better quality control

Our original game idea is not that of a fast-paced game, so we need to tone down the speed and add meaningful mechanics such as fire-breath, health, and possibly additional pickups to increase the game’s fun-factor and stick to game theme. - This is not a skill-based game, more so a fun and interactive game that the user can enjoy, possibly being skill based only when difficulty ramps up to a certain level.

Bug reports:

https://1drv.ms/u/s!AlHqenFxGZxTdbY_k63cov2hXh8

[rayhan96-blog]

Prototype B

So a lot has changed now that we went onto the second prototype, and we're already starting plans for our 3rd game. But with that out of the way for now, I will discuss the events of prototype B.

So for this prototype I was the project manager and lead tester, my role was to keep trello updated, add version control, create bug reports, and do a bit of programming.

I decided to use sourcetree for our version control, it was a bit of a pain to set up at first, but I think I've gotten the hang of it. In the end me and James thought it would be too easy to work on unity's variant of this, as we wanted a bit of commercial experience while we were at it.

As mentioned I did keep trello updated as per my role, I gave everyone jobs including myself, dan was the leader before so we got to learn trello a bit and how to transfer admin to a different member (to me that is, as I'm the leader now).

In addition to all these I also set up bug reports for the game, which I will include as an attachment. Generally I started out with a couple of bugs at first, but then managed to find 4 as time went on. If you open the files you will notice that each have their own priority, none really game-breaking, but bugs nonetheless, I will upload as soon as i find more since it’s a pretty low amount at this time of writing.

On the other hand the game concept did change this time around, if you remember from the previous post, we didn’t like how the player was moving on the ground, so this time we created smooth flying with acceleration, and added pickups spawning in the air for the 6 different lanes.

The week started out rough as I tried to understand how to work with source control, james also had a hard time getting the hang of endless generation. Dan was fine as designer and art coordinator, it was the beginning of time where we actually had decent communication between artists and programmers.

At the end of the week we got bad news from James as he was having a hard time with the generation, so we decided to have him expand on the original prototype A generation script as a backup plan. Despite all this I managed to nail down source control by wednesday giving me time on thursday to work towards the game which we then show to the artists during the friday practical.

What I want to mention for this 3rd week though is that while things went okay, I can’t help but feel that I worked the most on the game despite being manager. I highly believe that this is to do with james deciding to use my script, so he had no idea what he was going into. So as manager my plan for next week is to have a meeting with both of them, explaining the code especially the random generation line by line, in a possibly 1 hour unofficial meeting.

[rayhan96-blog]

Prototype A final

So before I go on to prototype B I just want to go back over the first prototype and mention the programming practices I used. Since we are making an android game, it would only be fair to discuss the code involved. So to begin with, I made sure to include the basics for our group, such as commenting, spacing and indenting. So far we haven’t set up any android expressions yet, but we do have plans for it in the future. I used a few more complex tasks such as using instances/singleton pattern to get access to other scripts as well as using unity functions such as get component in order to quickly access certain attributes of gameObjects. I made use of folders for each asset i.e. scripts, mats etc. and also good naming conventions.

Basically I stuck to good OOP structure and also game engine structure (for lack of better words). We know some of the restrictions placed on mobile devices, so we made sure to have tiles recycle on a procedural basis (without destroying objects!). The good news with starting like this is that I now have a code structure for which my team can follow up to, and with this in place, we can consider an understanding of each other’s code as well as efficiency of our programs.

To summarize this prototype I will go over the things that concurred throughout it’s development:

What went well

Good start to the module, already finished up on procedural generation

Had game ideas + mechanics right at the start

I did a good bit of audio and programming

Our team worked well together, lots of discussions and ideas taken forward or in the bin, James did his part for designing the main menu, and Dan set up trello for management (though we also used discord for chat quite often)

What didn’t go well

We mostly used the artists’ ideas, we hadn’t thought of our own, or at least our’s were not as good as theirs. Not much of a problem but its good for the future if we could have good arguments to compare with theirs

In the end we realised that the artists didn’t want generic jumping left/right endless runner, and neither do we (the dragon should be flying in a 3x2 gridspace), so we probably will not see this prototype being used for the future

At the beginning we didn’t have much info in the way of roles, so while we tried our best to interpret what our roles meant, some of us missed out on a few key points

What we/I could do to improve

Construct better communication between artists and programmers, this would’ve lead to less confusion upon seeing a final product from one another

Try to keep ideas realistic but also with a good balance of mechanics, originality and fun-factor in order to keep the player engaged

The VLE is constantly updating, keeping an eye on it can help the team identify roles better

Improved workflow across the team would’ve lead to less pressure on certain individuals and would’ve certainly resulted in a better first prototype

[rayhan96-blog]

Prototype A

Okay I am a little bit behind in the blogging, been caught up with programming, but I will try to outline everything up to today. So right now we have completed prototype A and halfway there with prototype B. For Prototype A I was the lead programmer and audio designer. I added sounds such as the music and the jump, which was taken and slightly modified from a website that I will link below.

The programming was my main task for this prototype, I added fairly solid programs for the random generation as well as endless recycling. I tried not to focus on the art aspect too much, so I ended up creating a fairly plain environment displaying the very basic of our plan.

This plan was to create an endless runner in a temple run-styled manner, except with a sort of 3x2 grid for a vertical approach. The theme will be oriental with a Chinese dragon as the player and lanterns/mountains for score/environment. This was particularly the artists’ idea, but we decided to take it on as our ideas weren’t as well thought of at the time (we started the module and on that day they had everything planned out, so we figured being a sound plan it would give us an advantage out of the planning stage).

^^^^ Okami - One of our inspired games ^^^^

Below are a few of our concept arts

That said we did question a few of their plans, particularly how far fetched some of their ideas were i.e. changing endless path to the right, diving underwater, in a tunnel, free movement etc. The thing is we far from seasoned developers, certain things we can learn, yes, but we don’t think it would be ideal to spend most of our time learning and the rest implementing. We believe that if we just stick with our experience, we would be able to create a more refurbished game, and once that’s done, then we can learn and adapt new features in (which we definitely want to do).

The first few weeks were pretty much introductory, so we didn’t have much time for the prototype (we created an endless runner, yes, but core mechanics weren’t implemented at the time), but luckily we have our ideas set now and are now ready for the next two sub-games.

Audio files taken from:

https://www.soundsnap.com/search/audio/boing+one+low/score

https://www.soundsnap.com/search/audio/paper+crane/score