Trash Dev Game Design

3D is back on the menu  boys Actual Driving Be careful people because Vincent Threat is in on the roads. Ever felt like the speed limit could GO #@%! itself!? In each level drive as fast as you can, smash through anything that gets in your way, and flip off other drives as you race toward the finish line. But be careful because if you slow down too much or come to a stop the cops are going to put an end to this.  How its Played W to go fast, A and D to steer, S does nothing because we aint going backwards. Shift key to go really fast and Spacebar to do mad skids and power slides. No brake button, who do you think we are?   Also while controlling the car with one hand, the other will be free to angrily point at or flip off other drivers which will be controlled by the mouse. pointing and clicking on cars as you drive by for a huge point bonus.  The controls are intentionally a little wonky to simulate the feeling of driving like an absolute mad man with only one hand on the wheel. Three

  Goodbye Merciful Space Its the end of space, on to the next dev cycle. So lets look at what happened here.  Same as last time, few things that went right, few that went wrong. Successes I actually have a playable game. I didn't kick every goal I was going for but unlike my first game this one can be played and you can be good or bad at it. I even found myself getting distracted by playing it when I should have been working on it. The art assets aren't as high quality as those given out but these ones are mine and they have character. Its got soul, and I am so proud that I'm using my own art. It also makes the game feel so much better because every part feels like it fits together.   I made a game that was my game and not just the game being used as an example in class, everyone else made a copy of asteroids. Asteroids is a good game but Merciful Space is my game, and I feel like I did so much more for that. Failures Ok so I didn't talk about this in a dev post but oh

  Looks at that exciting gameplay As you can see from the screen shot this is a playable game, a lot faster than the first dev cycle. In fact I'm not sure I could say the last game I was working on ever got to this point.  Some simple code got a score counter in the top right and I just set the bugs to move down the screen and get a little faster as they go so there is some ramping difficulty.  bit of a bodge job This is how iv set the bugs to spawn, I just have about 200 (couldn't get them all in a screenshot) of them go set up and spawned in at the start of the game. Very lazy but it works. Also all those lines and fields at the bottom are limiters for player movement and bullets. I think the game could be really improved from here by a way of spawning in enemy's procedurally or something, so lets have a go at that.  Very important red box Using the same tech for respawning I figured out in my last game I now have a red box that can spawn bugs, I also used the code from t

  Behold 10,000 hours in msPaint A new game begins, I spoke about it in the post mortem for my last game and I am happy to say that the first step of this game was to create my own assets. Pictured above are the two enemy bugs I designed, I think their kinda cute, and I already have ideas on how they might act differently and challenge the player. But before we can get to that lets sort out the most fundamental parts of our development.  First thing first, movement. This isn't our first rodeo so...  WASD, the best controls Now we can move and that screen limiter stops us from flying off screen and getting lost. So lets spice things up with a little bit of shooting. B E A UTIFL And I am on fire, this feels good. Kicking goals. We can fly about the screen and shoot, Iv even gone the extra step of shooting actually doing something by deleting the bugs my bullets hit and adding to a score variable. Next post, lets start looking at gameplay.   

Back at it again with the textbook things Last time we sat down with Tracy Fullerton's Game Design Workshop I wasn't impressed. It seemed to me that it was very introductory for a textbook. I had hoped that this would be maybe a bit more in depth, but then I suppose that in such a technical world as game design I would expect that the really in-depth stuff would be found in a more technological space, rather than an old-fashioned textbook. But I also said I would give it another shot, so today I am reading chapter 3: Working with Formal Elements. Chapter 3, Part 1: Players  First thing is an activity about changing the rules to Gin Rummy, I have never played Gin Rummy so attempting to parse this activity just confused me, moving on. There's an interesting section here on the invitation to game and the way this allows for players to move into a different head space where they are open to act in ways the usually wouldn't. It seems to me that this is mostly applicable to b

Welcome to the starship Merciful Merciful Space   Join the starship Merciful on its quest to save the galaxy from the alien hordes. Level by level encounter more and more swarming alien ships, each with their own movement patterns and gun types with a boss encounter at the end of each level. At the end of each level choose from a selection of ship upgrades before shooting off to the next battle in the stars.  How its Played Simple controls are best and as Merciful Space is being developed on my laptop why not go with WASD for movement around the screen and Spacebar to shoot, I can play with one hand. Your ship will always be facing forwards and so movement will be about lining up your guns and dodging enemy projectiles. In many SHMUPS there's really no reason to not be shooting so you would just be holding the space bar the entire time. To combat that your ship will move faster while not shooting allowing easier dodging.  Three Unique Selling Points Randomly generated ship upgrades

Goodbye Dagonet Sadly I have come to the end of the time I have for development on Sir Dagonet. So lets go over how the development went.  to bring some structure to this, lets go over some things that went well and some that went less well.  Successes I learnt a lot about Gdevelop over the past few weeks working on this project. figuring things out  like  h ow to use a Boolean value to call functions, and also smaller things like just getting my head around the dev environment. Death and respawning. I was so happy when I got this working. Death meant that my game had stakes and a player could fail to pass a level or challenge. Respawning means a player that fails a challenge can attempt it again rather than being left on a empty screen.   Thinking in design. I did two pitches for platformer games, the first I realised required technical skills I don't yet possess and also might have stretched the ability of Gdevelop. I now have a much better idea of what can and cant be done along

  Now I'm afraid Not afraid of the pink blob, I'm afraid of object-oriented code inside of Gdevelop. Turns out Gdevelop doesn't like it. That made implementing a kill function a bit difficult, but I got there in the end. Let's have a look at how it works now that it does work. Its working! This little chunk of code lets me use a Boolean like a function, if its ever set to true we run our code. Its a pretty simple thing, if I want the player character to be killed by something I set the value of kill to true.  like this You might notice that in the first code block I don't just delete the player I also create a new player object at "SpawnSprite". Well as part of this kill code I have also implemented respawning. The little guy is the spawn sprite When the player touches a flag the spawn sprite moves to sit above the active flag. When the player dies he respawns wherever the sprite is.  Now that a player can die and respawn I actually make a game