#goo engine

[cm8x-arts]

I made an animation for the prompt "Unfinished" in the 3D challenge chat. This one was fun :D

[chaozagent]

Remaking Serilda's Model. I've got a bit more work to do before it's done, mostly rigging the jacket and the hair.

[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]

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]

Code issues, errors, etc.

During the week I met up with Connor to go over the complexity of the Goo Engine and the bugs I was encountering. At about this point Goo announced their update to include scripting in the Create environment. I'm not sure how this affects our work but it's going to be a plus either way if it works well. I managed to get the ResourceLoader code correct and it theoretically should have functioned pretty well inside it's basic array but Goo didn't like the port and gave me an error on all runtime tests. This motivated Connor to develop the EventHandler ahead of Schedule and allow for us to start sticking with a template and inserting the code correctly. It took him a long time to work out the correct way and I'm glad he figured it out cause after all my work I didn't manage to.

[jacksanity]

Simple environment test in the Goo Engine.

[jacksanity]

This Friday we presented our viability plan (through digitalising the game) and the issues/profits from using a virtual game rather than a physical game. We got a lot of good constructive criticism from the desk-crit. I took a long time on Friday to look at some gameplay of popular virtual card games, such as Hearthstone. Key effects such as popping, blinking and the jumping of cards on actions (to show activity and enhance visuals) were visible throughout matches and multiple times on turns. The game was more real-time reactant than ours hopes to be, (all players see every event as it's done), whereas we plan on turns to be organised and then put forward at the end of the turn for all animations to be transmitted to the other player. (separates the GUI action code from the server code and allows simpler event handling for replays etc.) After the presentation we sat down with key points in mind: allocation of tasks for the agile wall, front-end and back-end task separation and further visual thoughts on the GUI/Environment. As a side note we also introduced our 7th member, Jay Kiely who is a Sound engineer with side skills in visual design and game design. The next objective was to organise what the Card class would consist of and how it would interact with the abilities put forward by each card (as they are very distinct from each other, but have small commonalities in their active abilities). The task was allocated over the next 2 weeks to design, develop and theorise how to best develop the back-end of the cards and their abilities in order to insert into the Goo Engine. This will all be done in the Javascript and then hooked into the assets produced by Goo create. I'm not a huge fan of Javascript, but the simple aspects of it should help in faster development, even if it does mean sacrificing efficiency as well as longer testing phase lengths.

[jacksanity]

Received the account information in order to use Goo Create, their cloud-based modelling environment. In first thoughts I thought it to be a smooth platform that reminded me of a simplified Unity 3D environment. It was EXTREMELY simple on first glance, it seemed like a great place to test out modelling concepts and such, all the while in relatively any browser.

Although I won't be interacting with this side of the Goo Engine in too much depth, I am sure it is not only simple, but advanced in it's deeper end. I have little experience with modelling and rendering so I didn't venture too far into the program but I'll await Anais and Scott's interpretation.

I think it's pretty good feeling to be able to work with something so new and can't wait to start to formulate a working prototype.