Games Design Project

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.

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.

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.

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.

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.

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.

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).

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.

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.