What is this thing?

0 What is this thing? 0
This is just a place for projects to honorably get canned. Thrown out assets, projects that break which is unfixable... by me at least. Projects in which I have lost interest or drive. In many ways it is a sad place - but I'd rather see it as a really happy place, where things that would've never seen the light of day got to go outside anyway. Even though they are ugly - broken. Even though the creator has been mad at them for the most part.
However they know- they've got to know- they know that the creator is merely mad at himself, disappointed even. These small lively things are loved and they are all part of a journey.
Enjoy them! And take them for what they are.

onsdag den 1. februar 2017

Road to Roskopops


A tiny road and a bus stop. Wonder where it leads. They should get off the road though.

tirsdag den 31. maj 2016

KOC II

Doom clone, KOC II




Debug text in corner, don't mind.

---o0o---

This is how #001

Ok, I got some things that is just super hard to find solutions for on the internet, maybe it is because no one wants to do the things I want.

How to make a bullet (ie) "draw on top of fog" in Game Maker? Well I didn't find a way to make it draw on top of fog with it's own colors, but I can at least keep the bullet visible by "fogging" in another color than my standard black fog color.

  • d3d_set_fog(true, c_yellow, 10, 400);
    d3d_draw_sprite(!!!);
    d3d_set_fog(true, c_black, 10, 400);
Wise-crack: "But can't you just..." - 
Me: "FARK yes ofcourse!!!"

torsdag den 7. april 2016

Size

VR,Size,Stretchscale,up/down,all the way up/down,time changes,voice explains,other side of the realm,inner side of the realm.

mandag den 4. april 2016

3D in Game Maker, Family game

I finally figured out how to manage to get 3D to work in Game Maker! There are not much on this anywhere, and the stuff there is is super vague actually.

I might be posting some usable things that I've discovered later.

One thing that I still haven't got a grasp of is the d3d_transform scripts, it's like they do not behave the way I would imagine.


Sadly, because I haven't wrapped my head around the d3d_transform scripts I haven't found a way to point the sprites directly towards the camera. Here I must look directly at YoYo for not having implemented a d3d_draw_sprite and d3d_draw_sprite_ext script for exactly this. I would expect such script to be part of the package, and it would be able to draw a sprite in depth, pointing directly towards the camera, without perspective deformation at the fringe of the view, and the _ext could contain an angle argument for rotation around the forward axis of the camera and the usual scale arguments. Tsk Tsk Tsk YoYo.

Anyway - here is my d3d_draw_sprite script, it is super simple, and all it does is to hijack the d3d_draw_wall script, carve away some redundancy and add some important things.
______________________________________________________________________ 
//d3d_draw_sprite

sprite = argument0; //sprite to use
img = argument1; //the image to show, in the animation strip
xx = argument2; //x position
yy = argument3; //y position
w = argument4; //width of the sprite
h = argument5; //height of the sprite
z = argument6; //the depth, don't confuse real depth(which is more important)

var tex;
tex = sprite_get_texture(sprite,img);
d3d_draw_wall(xx-w/2,yy,z+h,xx+w/2,yy,z,tex,1,1);
______________________________________________________________________ 
(the sprite, and img arguments could be left out for a more streamlined version,
now when I think about it, this is more a _ext, than a standard script)


I love the lo-fi look of a 480*270 game running at 30fps in a somewhat simple engine like Game Maker.


For the shrubs I made a system which does only handle them when they are close to the players - when a player stands on top of a shrub the shrub scales a bit up in X and scales all the way down in Y to make it appear as if the shrub is stepped upon. It works pretty well. Right now I can't handle a large number of shrubs, but I am sure I can up the amount if a bit of optimization is performed.

-o-

A random story/gameplay idea:

You run around in the backyard inside the city. There are fun things to do while playing the game in co-op, possibly with your son or daughter. When the game is being played between 8am and 6pm the game is a co-op experience of just messing about, and the off hours in is a single-player experience. After a couple of days of play, one evening the other, younger character is gone. Only a clue to where he/she has gone is left.
The older player will have to find the younger character again.

Another random idea:

You play with a younger individual, a little brother or a son or a daughter. The game will demand quite different things of you, as the younger player is likely not as skilled as the older player. This could be flipped if necessary. It is a matter of playing this with a less skilled player, it doesn't matter if the younger is the skilled one or vice versa.
So the skilled player will be helping the younger one, and the younger one will be communicating and discussing the situations with the older player. Both characters will have a certain skill-set or properties that are very different to each other. For example the experienced player will be doing some jumping, shooting. The less experienced player will be doing navigation, halping out, like pushing buttons, solving puzzles, collecting things, maybe even matching things (sounds a bit condescending, but it isn't, at least here it'll be for a cause, not just killing time. :D)
It is empirical to incorporate puzzles that demands the two to communicate, maybe even give the non-skilled player some opportunity to show his/her wit and knowledge of things that the skilled player might now have the slightest clue about.
One way to do this could be to concentrate more subjective opinion-oriented tasks to the non-skilled player and direct more hands-on performance based tasks towards the skilled player.

Main objective would be for this game to be super asynchronous, which is something not many games possess, even today, 2016.

-o-

Dialogue excerpts:

"It'll all collapse. Hon' we need to go find mom! She is in danger!"
"K"

...

"All of them! All of them is here! See!!!"
"They're coming closer..."
"They'll help us, they'll help us get up there"
"Ohoy all!!!" - "Help us get up there!!! Mom is there" - "We need her back"

...

"We lost it all, the world is broken now. And for what!?"
"I want to go back! I want the garden!"
"The garden was never anything."
"YES! IT WAS!"
"It wasn't" *pause* "It was... wasn't it?" *pause* "... it's all gone now."
"..."
"We had fun though. right... along the way we had fun."
"..." - "we did." - "remember that time when the scribble-thief got the rubies?"
"HA!" - "yeah I do." Pretty weird one, that scribble-thief"
"YAH! SO weird."
"Was he also in your mind then?"
"I guess... don't know if he was a boy or a girl"
"Nah you're right."
"..."
"Do you think this is it?"
"..."
"might be"
"I'm sure we figure something out."
"We will! Right?"
"..."

-o-

søndag den 3. april 2016

C64-ish gfx for Reside

Commadore 64 - ish graphics are super fun to make.



Normally, I think, it is 3 colors per "tile" as long as one of them is the "background" color. In this particular image that color would be black. However for the most of these graphics I only use two colors in total per tile. If you look closely though the wire and the thingy-plates in the lower middle of the screen has three colors. This is simply because I have a hard time deciding on the limitations I am forcing onto this project. 
As always I've almost already abandoned this, so I will not be working too much on this in future, if any at all. 
One of the cool things I made for this is the smoothness that the little motor-cycle-helmet dude moves with. he moves in 8x8 pixel increments, which normally works fine on left to right movement because the tiles are 8x16, but it doesn't work (normally) for up and down movement. So I made it so, that when you move up or down, a black block is occluding the background behind, then the character moves 8 pixels up, a moment later, he moves the last 8 pixels up and the background is visible again. 
Smooth Y movement. Smooth-ish.

Furthermore I made an airsupply feature, where air is emitted from certain objects, such as vents. The air is a particle that then tries its best to find the player. When it finds the player it adds air to his lungs, and the player can then breath. If the player does not have a constant airsupply the lungs will be emptied of air, and the there will only be oxygen in the players system to make him last for about 30 seconds. 
Air-supply system.

Here is a little gui representation of the air-supply.
Air-supply gui
There are three stages. The white one blinking is the last oxygen in the system, The red one (in the beginning of the gif) is the lungs with no air in them. Later the lungs are filled with air, and the white "last air" gauge is shot down.

Additionally, to be clear on the C64 ish-esque-like gfx, I use that as a buzz. The "C64". It is a matter of setting up C64-like limitations, the limitations mind you, that I like. So my limits are: 8*16 "chunks. 3 colors max on one chunk, 1 color being the background color, in my case black. Nothing is allowed to move smoothly, unless measures are taken to secure the integrity of the chunks. Color pallette is limited as well, however not to the original C64 color pallette. The pallette I adhere to is the original Game Maker pallette - the reason for this is that I cannot be certain that Game Maker will remember a custom pallette from session to session, and there is something nice to actually just make the "out of the box" pallette work.

fredag den 29. maj 2015

Dashboard design closeup - upper right

This is the JANITR interface/dashboard design in the upper left corner of the screen. It boasts the inventory button ~ visualized by a yellow button with a chest on it, and the attached "xspand-box" which actually contains the inventory. The yellow color is a visual cue to the yellow Y button on the X-Box controller.
The red button corresponds to the red B button on the X-Box controller. Right now it expands a sort of written diagnostics/help/notes dialog xspand-box when pressed. It expands the same way the inventory box does. Inside it is a bunch of text that conforms to the size of the box by increasing,decreasing the number of letters contained in the large chunk of text.
At the top is a build in unit pin also called a dog-tag, or a bot-tag. The dog-tag contains JANITR reg. code "j.u." and the version number, "v1.01", of the model. Note that it does not state the version of the system inside, nor does it state possible add-ons or extensions that could've been implemented. However the colors to the far right of the dog-tag will tell you something about some basic and quite superficial add-ons.
The little round widget under the inventory button is just for fancyness.


The inventory has a small icon on, that is the famous bent "i" of the company providing the j.u. v1.00 to j.u.oo v1.25 with the inventory xspand-box gadget. The bend "i" stands for inventory but together with the circle surrounding the "i" it is also the initials of the company: Ormorand Intension.

tirsdag den 19. maj 2015

Made some headway with JANITR today

I've been extremely frustrated with the way the physics was being handled in my JANITR project for a time now. What I was aiming for was easy implementation of physical trades, without having to actually have physics in the game. In GameMaker I was switching physics on and off for a couple of weeks - I knew how easy it would be to get JANITR to do what I wanted with add_force and such under the physics structure, but to avoid the setup that comes with the physics based levels and objects would be super beneficial for me.

So now, a couple of days ago and today I scripted my way out of it... Yes it's crude, it's rough and it's super hacky. Corner-cases are just being taken care of as I scripted the shit, and that is just how it is going to be. I kind of like that things are being "hard-coded" like the games of olden days, such as Mario Bros. Where physics was non existent and therefore things like gravity and forces being applied to the objects and characters were written into the game the hard way.

I'm happy with the result, given the time it took to implement it.

Here have some gifs!

Jump boost thingy -                               - picking up items.

PROXEMIT $0.00


I added PROXEMIT to itch.io, so it is easier to distribute and avoid the "DANGEROUS FILE" thing in browsers. Also it's $0.00 so it is kind of affordable at the moment.


fredag den 15. maj 2015

Janitr full screen grab

Slow frame rate, but nice colors and no compression. 

Also check this recharge station, it'll mainly do what it sounds like it should do!

tirsdag den 24. marts 2015

EM game

Technology has advanced. M scale operations are now available, expensive. Therefore only heavily funded scientific M scale labs have the ability to operate within those realms.
Time almost stops, so therefore to build an "outpost" at a p a consecutive and steady stream of Mnauts has to be specced and despecced due to the harsh and unforgiving environment.
With current technology it is only possible to be scaled for 2 hours (real) which gives the Mnaut about 180 hours (interpreted time) at M scale.
The despeccification has to be scheduled, so be ready after the 2\180/ hours. To make sure the work of the Mnaut was not in vain a replacement will have to be ready and continue the work immediately to avoid degeneration of construction, overgrowth or infestation of bears, bacs, zymes.

Tools and arms have a completely different way of working at those scales. So new and quite exotic gadgets have been invented. Most of them are actually still in n scale, where the wielder is required to operate it from M realm.

For the lab workers at the facility it is often very fun to watch the operation log feed which has many posts per minute, sometimes per second even. Since time scale factor is 1/9 at M scale the stationed crew can make decisions and execute tasks way faster than the lab workers at n scale.

Many years later, M scale computers and technology will be produced and used.

Further in the future M terrorism developes. Bears can now be despecced - to cause havoc in our own realm.

fredag den 27. februar 2015

FPS jam idea

Dead man switch, slow boot up time, possible enter long string such as: "jango culture python" then ctrl+alt+enter, then 5 seconds to press/hold dead man switch.

If dead man switch is released and no other button is pressed, suit will power down, for safety reasons, and protocol will have to be repeated.

Teleport torrent to avoid.

Crammed and claustrophobic visor. Large weapon takes up most of mid/lower/right side of screen.

Demons, demans, corpse tanks, fiend cubes, torture pyramids, massive hell cells, blood hadron, spike mind, kidney hail,  etc. etc.

tirsdag den 13. januar 2015

Monstrosity test alpha alpha gameplay video

Try it here:


(Requires XBOX controller)
LeftTrigger slow time
RightTrigger thrust forward
LeftStick control)

mandag den 12. januar 2015

Tiny test on something cookin'

Literally threw this together yesterday, made with playmaker... which I know can't be used for actually making a game ~ well not entirely that is.

Check it out:





torsdag den 8. januar 2015

Gotta remember this

I just gotta remember this:

HothStarfoxWanda-esque.

Last monstrosity contains a landing runway. If you land you meet a family currently mourning the recent killing of their children. You realize "oh shit".

lørdag den 6. december 2014

Hyrule speculations

Hyrule speculations


*UPDATE* TP map fits remarkably well. Look at Hylia which is almost a direct copy of the Hylia from TP. Also the rivers is somewhat similar, but of course more "natural" in the wiiu rendition.

Observations:
  • Thats pretty vast
  • Super simple "terrain generation" terrain - very 2008 unity kind-of tech. Sadly
  • Not as lush as the E3 teaser
  • The horses has superb animation
  • Epona looks nice
  • Link has pretty cool movement animation compared to previous Zeldas
  • When he runs uphill he looks very nice and heavy
  • Terrain seems a bit untidy... unlike previous Zelda titles
  • I see hylia,death mountain,something that could look like the plateau-y Zora domain from oot, desert,hyrul field.

onsdag den 12. november 2014

Gui design for JU inv/stat/prox

Here is the gui design for the inventory/stat sheet/prox

The prox at the top left makes sure that you have a view of the surroundings while fiddling with the inventory.

Tools and weapons are printed on site, and recycled when discarded. This is a very clever way of circumventing the limited space issue of a JU. 


A low fi crap shooter

Cølørs!


tirsdag den 23. september 2014

A little test thing - with lively JANITR Unit

Basically the JANITR Unit will have fun. Generally. 


In the end you might think the Unit is annoying, but Sovne, the astronaut/on surface crew member thinks its ok, when the Unit is cheering him up.