#goocreate

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

[1stinseo]

8192 spheres with spring-based collision. #webgl #glsl #goocreate #60fps

[itsallinthemakingof]

View this post on Instagram

A post shared by Joakim Areschoug (@joakimstagram)

A nuclear warhead on legs #goofyfriday #goocreate #webgl

[thesoulharmonic-blog]

[1stinseo]

Particles and stuff. #webgl #goocreate

[1stinseo]

The perfect work station? #goocreate #vr #webgl

[1stinseo]

The birth of @MoMouthness. Assembled in #goocreate. #webgl #html5 #mouthness.

[1stinseo]

PROTON SMOG. #webgl fog play in #goocreate making everything so #80s and beautifully #dystopian

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

Behind the Scenes in the GooCreate lab project.