Leaderboard

Hello. I made something! The front: The back: The Battle:

[1:46:23 AM] Jamesster: dino attack took place in 2010 right? [1:46:43 AM] Jamesster: and lego city undercover takes place in 2012, according to some billboard about an election in-game or something? [1:46:55 AM] Jamesster: so did the city just sort of [1:46:57 AM] Jamesster: get trashed by dinos [1:47:03 AM] Jamesster: and get totally rebuilt within two years [1:47:16 AM] /)¢( Krysto: have you seen minifigures build? [1:47:17 AM] Will Kirkby: duh [1:47:17 AM] Will Kirkby: yes [1:47:23 AM] /)¢( Krysto: that s*** didn;t take more than 2 hours

[04:24:06] Bug Catcher: ¯_( ͡° ͜ʖ ͡°)_/¯

I already watched all the gameplay that had been posted earlier this afternoon, and I have to agree with what others have said earlier. The writing is generally better than that for the TV show (although credit where credit is due, the brothers Hageman did do a good job for their part on The LEGO Movie, with a wit I hope to see reappear on the Ninjago movie.) The writing and gags reminded me of that of LCU, which I suppose is no coincidence, and it is as ever refreshing to see TT games creating their own completely new stories. The voice acting has room for improvement, but I guess I have grown accustomed to the voice actors from TV show, and some of the characters have decent enough voice matches. As a whole, this game actually bucks the trend of TT developing games I don't want, and I could only wish to see it become more widely available. It is definitely an improvement from TT's rather stagnant pool of licensed games, just as LCU was when it came out. I suppose it is a testiment to TT game's ability to storytelling (though not necessarily QA testing.) *End of rant* EDIT: To le717 and others, it would theoretically be possible to play the game as it currently is on a PC by using a Playstation Vita emulator coupled with the ROM and BIOS accompanying the PS Vita version of the game, if legally scraped from the cartridge and converted to something comprehensible by standard computer file systems.

well then

Am I the only one who wishes this game would have made it to the PC?

[2:39:11 PM] Hugh Wotmeigh: brb, McJobless post incoming [2:39:13 PM] Hugh Wotmeigh: because f**** me [2:39:27 PM] Will Kirkby: can we cuddle first? [2:39:42 PM] Alcom Isst: Can I watch? [2:39:48 PM] Hugh Wotmeigh: ... [2:39:54 PM] Will Kirkby: haha [2:39:54 PM] Alcom Isst: I have a camera! [2:39:58 PM] Ramius Antillies: Extreme, isn't it like 5am? [2:40:06 PM] Triangle717: *Ducks out* [2:40:21 PM] Will Kirkby: oh, sorry [2:40:29 PM] Will Kirkby: can we get married first?

The last session's post has been updated. Enjoy!

Wee it's so cute! Nice job. You managed to make it have a fluffy appearance even though it's made of bricks.

That's a really nice construction. I may not be a Pokémon fan but I can definitely appreciate the accuracy of your model!

How'd you get that mouth? It's beautiful! The red octagon pieces are also pretty, and well used. And that's really quite large. Well done! I would give this a 10/10, except that THERE'S BARE STUDS ON THE BOTTOM OF THE FRONT AAAAAAAAAAAAAAAAAAAAH

Wow, it's to scale too. Nice work. Now make a pokeball and catch that sucker. Or have it go all Super Smash Bros. on Mario.

No I rotated it. The render from the previous quote is mirrored. I am sorry for the confusion. I was wrong. Connected to the triangles of the node we have once again a plane that divides the track (here the colliding infos) into to sections. If the car is on the one side go to the left node otherwise go to the right node. If you reeach a -1 there is no colliding of you reach a -2 there is an error. It is the same in the checkpoint files. But there you will have to be very carefull. As far as I can tell now the planes have to be defined so that they will not cut one of the remaining checkpoints! Is there still someone who would like to crate a custom race track? Yes because of the tree. Here is a screenshot of the first version of a CUSTOM TEST TRACK! It is only a plane where you cannot fall of. I just replaced the main file of the test track, so that you can still see the environment of the original track.

LEGO's YouTube channel just cannot get its act together. Episode 8 in English, with Korean subtitles.

This project gives me many mixed feelings. I can't come here with the opinion of a real critic, since this isn't a real game project, but.... I appreciate that everybody put effort into this, but I simply can't find anything to be glowing about except for the fact that it was a team effort. At first I had a bit of a chuckle at the initial posts and the inexperience of the team, but as things progressed I started to see and feel a lot of things, since I was being reminded of how a younger me thought game development went, and I got really depressed about this. A few key issues I've found: I don't think this can be called a game. It's an experiment. It's a team effort. It was a collaborative project. It is not, however, a game. There is no clear goal, there is no reward/feedback for completing the one goal of the game, there is only one obstacle and the boundaries of the game are not clearly defined. A good game lets you know exactly what your goal is (also remember, Show Don't Tell), rewards you for completing the goal, throws challenges towards you to prevent you completing the goal, and clearly defined the area of play. There is no way to respawn after death except with a hard reset. This is a cardinal sin of game design and something that is strictly forbidden in most TRCs (it's considered an "A Class Bug", which means that it prevents the player from continuing the game, and therefore the developer is not allowed to ship the game until it is resolved). If your player dies, reset them at the start of the stage and/or refresh the game. At the start, you added about half a screen worth of "junk space". Junk Space is area that is within game-bounds, but players cannot traverse it because they are blocked by either an invisible wall or props. Junk Space is frustrating, and players get confused about what is on the other side of the screen that you won't let them traverse. Always start your player to the left-most of the screen. The one enemy's collision only allows you to kill him by hitting the top of his antenna (I did multiple tests on this). This is an example of unfair gameplay. In Fruit Ninja, because people's fingers usually become very large when they press them against the screen, they increase the collision radius of the fruit, and decrease the collision radius of the bombs. It makes the experience better for the players. You should consider making the experience fun, instead of just making an enemy with "realistic" collision. The coins are essentially meaningless. Their placement is sporadic and confusing. Economy is usually used for two gameplay concepts; "leading" and "challenge". Coins that are placed for "leading" tell the player where to go. The first line of coins were correctly leading, but there were too many of them and they were too close together, so they felt very forced and silly. Coins that are placed for "challenge" are supposed to give the player a mini-goal of reaching those coins, leading to deeper gameplay. You lacked this challenge except in one instance which I will talk about in the next point. The House presented a massive issue. There is a gold 100-coin on the roof of the house. Collecting it requires you to jump to it first before you jump to the ground or through the hole in the house. Challenge doesn't work when your player cannot have multiple attempts at a puzzle. It becomes "frustrating", and a frustrated player soon becomes "bored" and quits. You need to add an alternate way of getting the gold coin in the event that the player falls down the hole. It's unfair to have items which can only be acquired if the player magically anticipates the answer to the question they haven't been asked yet. To elaborate; every element of gameplay is a question. Players have the responsibility of giving answers to those questions. We are basically making very fun school tests, but ones that players/students can attempt over and over again until they get it right and feel proud of themselves for it. The music was unfortunately slightly annoying, and made me want to shut my speakers off after 3 loops of it. If that was yours, Drill Master, I need you to contact me ASAP so I can discuss a few things with you privately. While I am satisfied that you added feedback for the enemy's death (the squash animation), it was slightly ridiculous, and more important it made no sense. You don't have platforms like Mario. The enemy can't fall off the ground. Ben24x7's animations were lackluster at best. Again, I appreciate you put effort into them, but they were not properly keyed and were very choppy (at least to me who has done an animation course). Furthermore, the character looks like he is taking a furious dump every time you make him jump. I don't want to perform game actions if it feels like I'm hurting the player character. There was more I was disappointed with, and I could go into numerous tirades about the way you guys approached this game from a project management perspective, but I will not since this was just a bit of fun for all involved. The point is, keep practicing, but please start to test your games more, and actually appreciate the importance of game theories and why games work and are fun. You guys have a very long way to go, and currently this project is on about the same level as those 3D LEGO fan games I regularly rip apart. EDIT: Oops! Forgot to point out three glaring bugs I found: I died by falling onto the enemy on my first go, and on the second run through of the game, the enemy disappeared completely. He came back every other time, but for some reason he didn't appear at all on my second go. When you die, you die in the exact spot you were hit. That means you can hover in mid-air. Move the player to the ground plane. I'm getting the same problem as BobaFett2; on a monitor with 1920x1080p resolution, there is a s***-ton of black space. The game should be full-screened, which should be easy in Flash. EDIT 2: I have to mention this. Going through the game code, I came across this little gem: //If player is touching enemy and above it if(world.player.y <= (EnemyObj.y - (EnemyObj.height / 2) - (world.player.height / 2)) + 10) { //Kill enemy EnemyObj.scaleY = 0.5; var enemyTwn:Tween = new Tween(EnemyObj, "y", Strong.easeOut, EnemyObj.y, (EnemyObj.y + 500), 80, false); enemyTwn.addEventListener(TweenEvent.MOTION_FINISH, onFinish); function onFinish(e:TweenEvent):void { enemyTwn.removeEventListener(TweenEvent.MOTION_FINISH, onFinish); EnemyObj.parent.removeChild(EnemyObj); } //Play sound enemyFootDeath.play(40); //And update score updateScore(50); } So instead of making a very simple to do collision sphere/cube, you went with a rather badly designed alternative that detects if the player is 10 units above or something to that affect? You can't do that my man.

In another thread there was a discussion about the bvb files (I do not know why). Since I did a little more research on them I think the content should be referenced here: I had a first look at the .BVB files. I looked into two COLLIDE files. There are vertices without additional information and triangles with additional information. I was able to create the following images with the data from the 34 and the 2d sections: The test track The 8e section fills the rest of the file. It looks like the Binary Editor could not handle dynamic (unknown) structures. I am not able to interprete the content of the 8e section yet. There are always a variable number of integers followed by 4 shorts (except the last group of integers). Here is an extract from the TESTCOLLIDE.BVB Please remember: 0x04 is an integer 0x17 is a struct that was defined in this file 0x14 is an array with 0x__ 0x__ entries of type 0x__ [...] I had a closer look at the k_8e section. And the data in that section also seems to describe a tree (I have no idea why!). 7 numbers per node: pointer to left child (when -1 no left child) pointer to right child (when -2 no right child) x y z offset triangles number of triangles x, y and z are mostly really big numbers (between 0x40000000 and 0xC0000000 (=-0x40000000)). When you divide them by 0x40000000 you will get a normalized 3d vector. I think it is something like a normal or here a colliding direction(?). I changed the values to RGB and got the following image for the test track: I already have a working replacemant (a simple box). I am not falling through the ground but I am falling over the edge :-(. Maybe it is because of the tree!?!

Even if it not necessary any longer because is working, but I found out what the four floats are for. They discribe planes (one normal and a distance) to divide the 3D world in smaller sections. By this it is very fast to find the region the car is currently in. The first node of the tree contains (float) 1 (float) 0 (float) 0 (float) 101.2483 This describes the blue plane. When the x-coordinate of the car is greater than 101.2483 (or -101.2483; I am not really sure) we have to go to the left child of the current node. That node contains (float) 0 (float) 1 (float) 0 (float) 68.672 This describes the green plane. When the y-coordinate of the car is greater than 68.672 (or -68.672) we have to go to the left child of the current node. That node contains the red plane. And so on until we reach a leafe. Then we know in which region the car is.

I gave it a try. At first I tried to use something like this: k_27[(int) 1] { k_29 // leaf (int) -1 // parent node (ushort) 0 // offset GDB_2E (ushort) 401 // number of elements from GDB_2E (all) (short) 0 // actual region (short) 0 // offset visible regions (short) 0 // number visible regions } k_2a[(int) 1] { (float) -544 (float) -404 (float) -16 (float) 485 (float) 225 (float) 97 } k_2b[(int) 0] { } But the game yelled: int expected. So I addad a value to the k_2B section: k_27[(int) 1] { k_29 (int) -1 (ushort) 0 (ushort) 401 (short) 0 (short) 0 (short) 1 // increased } k_2a[(int) 1] { (float) -544 (float) -404 (float) -16 (float) 485 (float) 225 (float) 97 } k_2b[(int) 1] // increased { (int) 0 // added } And the game runs (I do not know if it is the best solution!?!). There still seems to be a fare plane but anything else was visible. I tried to add my cube again (texture is grass). And its working!

Seems legit.

[11:35:34 PM] jamesster: "hahahahahaha. Now THAT is something." - A LEGO Universe developer speaking of legos in space [11:35:36 PM] jamesster: what is my life [11:35:39 PM] Ramius Antillies: what [11:35:45 PM] Cirevam: what [11:35:48 PM] Ramius Antillies: So they offered you a job, right? [11:35:50 PM] jamesster: lol [11:36:13 PM] jamesster: the graphics programmer went indie after LU shut down, and is friendly on twitter, we chat occasionally [11:36:27 PM] Cirevam: Wohoho, now that WAS interesting! You know, I don't tell everybody this, but here's how to log into the dev's LU server... [11:36:27 PM] Cyrem: "we chat occasionally" [11:36:31 PM] Cirevam: SELECT THE LETTERS IN YOUR NAME [11:36:38 PM] Cirevam: THEN CRY BECAUSE YOU'LL NEVER GET IT [11:37:06 PM] Cirevam: Grab a tissue when you're done. That's when the fun REALLY begins! [11:37:35 PM] Cyrem: |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| [11:39:46 PM] Slightly Seradima: wAIT [11:39:47 PM] Slightly Seradima: bEM [11:40:10 PM] Hugh Wotmeigh: Yes.