jacksanity

[jacksanity]

Final Reflections

MAD virtual game development was a bit of a sticky one, first of all I'd like to point out that the engine is a great thing to work with in theory and all of it's aspects would work pretty well, but it has several underlying flaws. The engine is programmed using Javascript which is a very basic scripting language and cannot perform much at all in the way of real game development. The engine itself was also poorly defined both in documentation and by the development team at GooTechnologies as well. Most of the edits we did on the game engine were of our own work and there were LOTS of workarounds we had to perform in order for the engine to even remotely perform correct. So the engine was not all that good to work with, but with a lot more work by the GooTech team it could have been a lot better. I do not want to go on about the engine too much but it was the main drawback with our prototype development, the outcomes were way too little for the amount of work being poured in (and there was a LOT of it, even though it didn't look like it).

I was one of the programmers on the team and my main role was to work on the game code alongside the engine visuals. For instance I would take the create bundles (the models, textures etc.) and I would implement them so that they function and move correctly within the engine code itself. The system of doing this was extremely unintuitive as the GooCreate team did not use any repositories to store recent bundles or bundle updates, many things broke in continuous development. I hope to improve this next semester by taking a strong stance on it and teaching all team members who are unsure on how to use proper file revisions. I did not like organising certain animation parts because the modelling team could not stick to one basic system, I'm not blaming them as they aren't programmer types but they did mess up on several occasions old work when trying to introduce new work. GooCreate also doesn't offer team project hosting which is a bit of a nuisance. I would have rather just use the animations and states they gave me knowing they would work without having to fix them up before implementing into the engine. I enjoy being the visuals AND backend connection developer though, someone needs to control the two links.

I feel like the roles that used my abilities the most were the instantiation of new cards from existing entities in the scene, rather than create and load them all on start up, they are loaded as new primitive box objects as they enter the game. This took a LONG time to get correct as the engine is very poorly constructed/documented. Another area that I proved useful was maintaining the entities through key handling and mouse clicking (ray casting), this allowed for actions on the visual cards to affect the back-end code.

I learnt that you may be able to do everything possible in this engine but it will just take ungodly amounts of time, and by that I mean very ungodly. I spent several late nights on the project as the outcome to time-spent ratio was extremely poor, any programmer on the project will agree. I had to manage my time around my other units and often put this project above them whilst maintaining a healthy gap left over for the other units to be completed with a satisfactory ability. I maintained the time distribution well and spent a lot of time working on my University assignments without much distraction, which was nice. We held several meetings and were continually in discussion online and in groups, this is extremely nice to have in group projects as every other project I've had at Uni saw hardly any communication being done and a low result as the outcome.

For the next phase of the project I hope to switch to a different engine that allows us to better extend our abilities and produce more efficient code at the sacrifice of not using WebGL technology. Right now we're not going to be able to finish the game using the GooCreate engine, no matter how hard we try. It was a good prototyping engine but I doubt it could hold up to something like Unity or UDK in the final phase of developments.

All in all, the project was very exciting and although lots of time was spent with not much final result, I did enjoy working with the team and producing the game.

[jacksanity]

Game Description and Critique

Game Description:

M.A.D. (Magnificent Machines and Devious Devices) is a Card game that allows the user to manipulate the world by crushing it into submission. You take the role of a mad scientist who like all mad scientists, lives to plot world domination and for his signature creations to be at the corner of every street reeking havoc and spreading his will or world prophecy.

MAD is a card game like all cards games, but it plays an important role in setting itself apart. Unlike most card games, MAD allows the players to control their entire set of cards as if it were an army (and in many ways it is). Such armies are all independent of one another but have the main purpose of dominating the world and in order to do this they require a specific point count, (30 points on any one card marks the beginning of your rule as world domination). Eventually all cards (devices) must work together with the control of the player to reach 30 points on any card through the use of abilities, special attributes and passive tactics.

Components are the resources used to provide devices into their active state, for instance a card may require 2 Chemistry components to be activated, but once activated it is playable and can use it's abilities as well as gain domination points. The more cards out, the more points you gain each turn on each individual device. Abilities are used to reduce the the points of your enemy or increase your own points, they can also disable or completely destroy enemy devices! A combination of skill and timing is required to achieve world domination and that's the key strategy of the game, outplay your opponent with the competition being in multiple places at once, with many different winning states... how many devices can you keep track of?

Critique of MAD the Card Game:

Like I said above, the game requires your full attention in several places at once, your opponent could be holding 5 devices, each with key abilities that could all be played in sequence to achieve victory on any one of his cards, he is gaining points every turn and so are you... I love this aspect of the game, it allows for strategy of really large scale, every game will be different and it's guaranteed to make for surprising victories where your 2 turns to victory may not be so close as you think. Here's a visual example of devices and their domination points as clearly visible as possible in the MAD virtual designs.

The above is simply concept art, but our game prototype is fully capable of producing visuals on the point system, though issues with the 2D Graphics limited us to the following, still effective prototype, points can be seen in console. The programming structure behind the points is working perfectly albeit without much visuals.

Another part of the game that was absolutely crucial to implement smoothly, and was completed in that manner (I created the methods myself) was to zoom and select individual cards to read them at a large scale as most cards aren't significantly large in their original positions. In order to zoom all a user must do right now is to right click any card on the field it will then zoom to the left location with all features readable.

One thing I didn't like was the representation of components (resources) inside the Goo scene, I felt it brought away from the strategic play and hence it was unknown how many components you had at any exact time. I mean with experience you will know by the models but I feel a counter of some sort would have been very justified for both players to plan a lot easier. The game is going for a casual audience though so I don't think it will be an issue if this does not get implemented in the future and is probably just an opinion of mine.

The game is extremely fun to play and I can see myself playing the virtual game even after developing it. The strategies are by far my favourite part as I've mentioned and the re-playability that is offered by the numerous different cards and play styles.

[jacksanity]

This is a picture of our final design and it's functionality. We hope to improve this in the future by adding more modules or increased visibility for important areas of the game, such as where the junkpile is located (at the moment the bottom left) and more.

[jacksanity]

Unity 5 boasts a really interesting aspect that we could use A LOT. The only drawback is that Unity 5 is not available for several months at minimum and could be released as late as early to mid 2015. If we had access to Unity 5's WebGL functionality right now there would be no doubt we would be switching through to it during INB380. Unfortunately that is not the case right now so we must explore our options.

[jacksanity]

Mock-pitch to Game Lab presentation - 30th May 2014

Our pitch went okay but with the problems we've been having with our prototype we were unable to provide any detailed footage of the gameplay and instead had to rely on the gameplay mechanics and our visual designs. As always the issue isn't in our work hours, it is incredibly to do with the engine we are using and it's really difficult environment to create in. The presentation went fairly okay considering our downfall in the gameplay area. I am going to do some more work and attempt to get more functionality added to the game but as it goes I have been really, really busy with University assessment at the moment and have not had the large amount of times that I had earlier to work on the project, as it does require a large time.

I hope our main pitch goes well with the work we've done so far, we have been discussing the talk of switching to a more versatile and proven successful engine before our second phase (INB380 unit). This would increase our ability to produce the game at the cost of not working in a HTML5 WebGL technology. I personally welcome the change as one of the people who is putting hours upon hours into the project without getting much return, in fact all the programmers are feeling this way and we really cannot work for as long as we have been doing this Semester, at least not successfully. All of this was accounted for and there were several team meetings over the last 2 weeks to discuss our move if there were to be one. The negatives are heavily outweighing the positives for a functional project to be developed in Goo alone.

[jacksanity]

Behind the Scenes in the GooCreate lab project.

[jacksanity]

Desk-Crit Friday 23rd May

The desk-crit this Friday was a huge improvement on all the others, Laz and Michael both agreed we showed improvement on our game design AND code. That is because our team finally solidified it's thoughts into one scene design and the code team spent hours upon hours on the game mechanics. Unfortunately because we spent so long on the project we had to take a lot of time off the project to work on our other assignments that were due, we left them a week before because of how much work we were putting into the game code. I feel if I was forced to work on the game at the same speed as the last 2 weeks, (but in this week) then I wouldn't get my assignments done so I am tuning down until I complete my other assignments.

[jacksanity]

The hardest part about using this engine is it's connection between visuals and code. A lot of the time states on the cards (animations, locations, and other transitions) have to be manually altered by the GooCreate team and then implemented by the code team. This brings about all kinds of issues as the states aren't always correct when being placed into the game code. This is a very annoying aspect and I do not like having to expend several hours just on these issues as they will not be allowed the time we are devoting to them in our next phase of the game project.

The top image displays states going to locations that are incorrect and rotations that are incorrect, although they can be fixed it is really tedious to code whilst they are like this.

The bottom two images display the same thing but in the hand cards, where states are on the same z axis (in picture to the left) you can see through half of one card and half of the other as they compete for the same plane of view. The right just shows the cards out of scale when states are not reverted correctly.

[jacksanity]

Card Data has been synced with the game/server. We now have all cards represented in good quality textures and their data represented in JSON format on the server. We can create at max 60 unique devices now, their abilities have been set out into ids but are yet to be converted to code from plain English.

[jacksanity]

Delegation of work hours, working on the Game code majority AND finalizing the design concepts. Death symbol represents the intensity of our sprint's goal.

[jacksanity]

Goo introduced 2D Graphics into the engine, which are A MUST in our card game. Displaying the GUI, card attributes etc. require a form of 2D Graphic.

The issue in integrating them into our game was that our engine code did not support the canvas that is required for the 2D Graphics to function correctly. I solved this earlier today after a few attempts and it seems to be working fine. I am extremely glad that updated modules such as this, timeline, etc. from GooTech are all easy to integrate as other things have been a bit more difficult.

[jacksanity]

Working with Animations and Game Code

I've been working on altering the game code to introduce visuals through the use of a FSM (Finite State Machine). This was extremely troublesome at first, the Goo API is horrific and did not demonstrate any of the functions used by the FSM or how to alter them. I had to make use of the Development console to navigate around the engine code. Eventually I got a product that I wanted, the cards are being placed into a state of "ZoomedIn" when they are picked by the Mouse (clicked by raycasting). When you stop zooming, by clicking the card again, it returns back to it's position. This was a hard to arrive at stage but eventually it proved to be worth it as the final look and feel is fluid and responsive. An issue that arose was that the FSMs for each created card entity were all identical and so changing one produced a change in all the others, this was the one hurdle that took the most time, but eventually was flattened.

[jacksanity]

Final approach to GUI.

This is the design that has made the most sense to me and finally the team has agreed upon it. I really like the work done by the Create team to include every module and detail of the GUI so that we're understanding everything that is required by the Engine in planned and agreed form.The only thing that will be removed from this GUI design is the component values, which is the 4 Icons and their Numbers to the bottom left, these will be visible somewhere in the scene and will be updated with animations as you draw new component cards.

I'm not too much of a fan of the hand layout, (some cards will be upside down and require flipping) but overall it is a lot better than the previous revisions. My favourite part is by far the docks for cards at the top of the bottom GUI segment, (the doors), cards will be activated into these locations with nice animations (clamps or claws move them into place).

[jacksanity]

Friday, 16th May (Desk-crit)

This desk-crit was a rude awakening for my team, and myself (didn't update blog as much as I'd like). I was trying to get the ball rolling on the team deciding on specific aspects of the GUI for many weeks before now but I didn't get anywhere, it's not anyone's fault though. I am extremely glad that we have finally readied on a constant design that I can start to take into account instead of a new design every week like we have been doing, as code becomes redundant after each week because the visual system continues to change. I posted an image earlier in this blog, with my opinions, of the GUI we've all agreed on (without component counters).

The next few weeks will be a "MAD" sprint to the finish line for this project, we have a lot of work to do because of the slow start we followed through with.

[jacksanity]

These are a few of the card designs that have been converted to digital format. The designs are well made, I really like the way that the generation points is easily identifiable with the component requirements right next to it. It is laid out like a standard card you'd find in any ordinary card game, but the key to that is that the design works in most cases and so the standard stands. They could have been done without the bevel on the edge in my opinion, as a graphic designer I understand where these cards are weak and where they're strong, in my opinion the bevel adds an unneeded bump to the cards, it is also a very old design in most digital graphics. The card fits well with our theme.

Now that we've got all the cards converted from physical form to analog form (rather simply) we can now use them anywhere in the Goo Engine. The next step is to layer these images onto the actual card textures, (i.e. the ones with backing and side tiles), which shouldn't be too hard. They have been tested in game and are of good enough quality that they look good in any scale.

The chalk-drawing is my favourite part of these images, converted straight for pencil drawing on physical form they are extremely well fit for our theme of MAD scientists and world domination plans.

[jacksanity]

Week 10 main focus [GooCreate movement]:

We have the code structured well and the EventHandler is parsing turns and so we've got turns functioning with cards being dealt to both players and their hands increasing, deck decreasing etc. But they were only being mentioned in the game code itself and the screen was virtually blank of any visual effects. The struggle with this was learning the way in which Goo can recreate cards on the fly without interrupting the game code event loop. i.e. they have to run independent of each other because we do not want the game to be stopped to wait for a certain animation to play, we need the fast pace to continue and the animation to simply act on it's own timeline.

I was able to do this, with much trouble as the API confused me and certain aspects were left out (by the GooTech team) so I couldn't access certain methods with allow entities to be animated via Engine commands. I still appreciate the time I took to do this though as I understood the limitations set by the Engine and also worked around the future development of GUI items like card visuals etc. I focused firstly on getting the cards to be drawn into their relevant place in the hand (or wherever the hand was at the time based on GooCreate environment). This was annoying at first because the coordinates cannot be accessed anywhere other than on GooCreate projects and so I had to do a lot of trial and error into getting the cards into their appropriate locations, we wanted a better solution to this and hope to discuss it at next meetings. Another development process I implemented was the picking (clicking with mouse) of items so that you could click a card and then it would zoom into the camera for a closer representation (See image above) and then zoom out after a certain amount of time. This was a rough implementation but it allowed for a good module that is required for any gameplay to take place. Eventually we'll use the system to manually click and drag, or click then place cards. I didn't think it would take as long as it did but the Goo Engine is really hard to do things for the first time, it's a steep learning curve.

[jacksanity]

The main GUI is coming together relatively well. I like this version a lot more than the previous but I do still think there could be major improvements to make a more fluent gameplay experience.