LoginLogin

Nomadic demo

Root / Submissions / [.]

MZ952Created:
Download:X33N338S
Version:0.2Size:33.9KB
Welcome to a project I've planned on fleshing out for several years but couldn't due to my lack of time; Nomadic. Now, before you tell me I'm ripping off Terraria, Let me assure you that I indeed am. Terraria is my main inspiration for this game, however I am pursuing a totally different art style and game mechanic than Terraria in several ways I do not care to detail. Now that that's out of the way, this is a demo of Nomadic, specifically a demonstration of the main game engine. The game engine includes the following: collision interactions between player & tiles and player & entities; a dynamic physics and AI engine for tiles and entities (player & entities follow ballistic trajectories and ricochet, custom entity AI, friction, sand can fall, water can flow, etc); a dynamic lighting engine allowing for entities and tiles to create illumination on surrounding tiles in real game time (I have many ideas on how to utilize this, such as blocks near lava can "glow" red hot, lightning flashes, etc); and dynamic tile & entity animations. There are a number of things I mentioned here which you will not find present in the demo I present here (unless you dig through the code), but don't be discouraged, everything I said will make the cut for the first version of the game, as they are already implemented into the actual engines themselves. Also, I am demonstrating my terrain generation algorithm. I have actually never created a terrain generator, and so I am very strictly new to the idea, but I feel I've pulled it off quite well so far. The terrain generator can generate four biomes so far: flatland, hillock, desert, and mountain biomes. I have plans for more, the obvious candidate being cave systems (which I'm rather torn on how to go about creating). My plans for this game are rather simple, as they stand now. The classic spin-off of mine for resources to build better tools to mine for resources— However, I'd very much like to hear your ideas for how you'd like this game to work and function. In the early stages that I'm in, implementing game-changing functionality shouldn't be out of the ball park. I've already got a few, one of which I spent a little bit putting into the demo before uploading it (you can climb trees and scale walls). But if you don't have any ideas to share, that's alright too. Let me know what you think of the engine so far, eh? I'm aware of a few quirks and downright bugs in it, most of which are directly related to my poor understanding of how to implement a collision engine (there's a small chance that you can end up inside a block, although you really have to try sometimes).

Instructions:

Use the circle pad to move around, (A) to jump and climb, (Y) to spawn a default entity (it will just chase you around the map and you can't despawn it, be warned), the directionals to move subtly, the touch screen to break blocks in your vicinity or select blocks in your inventory, and (L) + touch screen to place blocks in your vicinity.

Notes:

Just to clarify, the program was designed to run optimally on the N3DS, and in fact, I have had to slow down it's runtime because it runs too quickly (when there are less objects on-screen). It WILL work flickerlessly on the O3DS, however I do not know what the frame rate will look like. If you're running this on an O3DS and you'd like to help me with a little debugging, go to line 703 in the code and decrease the number 24 on that line until it runs to a playable degree (I just don't really know how bad it'll be, I know those old consoles are slow).
ProgramsGames
MochaProbably#1
I WAS I GONE FOR 2 HOURS AND I COME BACK TO SOMETHING GREAT! THIS IS BEAUTIFUL WORK! :3 :>
Eversky_HD#2
Good!
SpoilerGood!
SpoilerGood!
SpoilerGood!
SpoilerVERY GOOD!
raimondz#3
I like the minimalistic design. However, the game goes a bit slow on my O3DS. I even changed the number on line 703 but it didn't improve too much. Suggestions: - For color tile, you could use an sprite of 52x32 with zoom of 8 (SPSCALE X,8,8). That way the performance should improve since the game paint less pixels per frame. - Use GCLIP 1.0,0,400,240 before GCLS to refresh the pixels that are displayed on the screen. (It's not necessary to flush the entire page) - For the bottom screen, You could draw the screen once and use sprites to display the blocks near the player. If you don't want to use sprites, then the other alternative would be store the bottom screen on another page or variable and use GCOPY or GLOAD respectively. (Performance wise, GCOPY is better than GLOAD)
MZ952#4
Replying to:raimondz
I like the minimalistic design. However, the game goes a bit slow on my O3DS. I even changed the number on line 703 but it didn't improve too much. Suggestions: - For color tile, you could use an sprite of 52x32 with zoom of 8 (SPSCALE X,8,8). That way the performance should improve since the game paint less pixels per frame. - Use GCLIP 1.0,0,400,240 before GCLS to refresh the pixels that are displayed on the screen. (It's not necessary to flush the entire page) - For the bottom screen, You could draw the screen once and use sprites to display the blocks near the player. If you don't want to use sprites, then the other alternative would be store the bottom screen on another page or variable and use GCOPY or GLOAD respectively. (Performance wise, GCOPY is better than GLOAD)
I know that sprites would run things wayyyy smoother, but I've elected to completely ignore their existence for now. Partly because I don't understand how to efficiently use them, partly because I never cared for them anyway (which I actually find sad because I know how powerful they can be; I'll learn eventually). To display the "art style" that I want to use, I've decided to use only graphic manipulation functions. No sprites, no text. Your suggestion for GCLIP intrigues me because I knew the function exists, but I have just no idea what it actually does. The documentation on it is actually garbage. The FOR loops are what kills the O3DS's runtime, I know that much. After posting this demo, I've actually already knocked a few milliseconds per frame off the N3DS runtime (which probably amounts to squat on the other console) while fixing the code up (speaking of which, I had no idea how consuming bit shifting was; it's about the simplest operation on the ALU, yet it snowballs up to be one of my biggest issues). What exactly does GCLIP do anyway?
raimondz#5
Replying to:raimondz
I like the minimalistic design. However, the game goes a bit slow on my O3DS. I even changed the number on line 703 but it didn't improve too much. Suggestions: - For color tile, you could use an sprite of 52x32 with zoom of 8 (SPSCALE X,8,8). That way the performance should improve since the game paint less pixels per frame. - Use GCLIP 1.0,0,400,240 before GCLS to refresh the pixels that are displayed on the screen. (It's not necessary to flush the entire page) - For the bottom screen, You could draw the screen once and use sprites to display the blocks near the player. If you don't want to use sprites, then the other alternative would be store the bottom screen on another page or variable and use GCOPY or GLOAD respectively. (Performance wise, GCOPY is better than GLOAD)
GCLIP can limit the area that is displayed or edited on the screen/page. This is only useful for GCLS or GPAINT since they can write the pixel outside of the area displayed on the screen . Example: 
ACLS
GCLIP 0,0,100,300,240 ' Limits the area that is displayed on the screen
GCLIP 1,0,50,350,240   ' Limits the area that can be written on the page.
GCLS #RED  'This will not paint the entire screen.
WAIT 10
GCLIP 0  'Reset the first GCLIP (The area displayed is 500x240)
GCLIP 1  'Rest Second GCLIP (All the page is writtable)
IAmRalsei#6
you start the game in a desert TOTALLY DIFFERENT GAME THAN TERRARIA YOU START IN A DESERT INSTEAD OF A FOREST anyway, the player is kinda small. you should size it up.
chicken#7
Ahahaha. Another Terraria clone. But this one has very delicious lighting?!?! I suggest: fix the very very sticky collision poop pet shadows and collision amongst them unify the dpad and circle pad speeds
MZ952#8
Replying to:chicken
Ahahaha. Another Terraria clone. But this one has very delicious lighting?!?! I suggest: fix the very very sticky collision poop pet shadows and collision amongst them unify the dpad and circle pad speeds
Whewboy, let me assess this one in order: the collision I have plans to fix up in the future, and actually I'm looking for someone who wants to help me with that, but the thing is that the kind of collision I'm using, as it is now, is about as good as it'll get; collision with the entities you spawn isn't a big deal because those entities are merely debugging objects, I have more complex AI's waiting to be programmed; and the dpad and circle speeds are different for a reason, namely, I wanted the dpad to be used for sneaking and slower movement, which is difficult to attain with the circle pad (until I implement the nonlinear function on the STICK values). This IS a Terraria clone, but it is also not :D
MZ952#9
Replying to:IAmRalsei
you start the game in a desert TOTALLY DIFFERENT GAME THAN TERRARIA YOU START IN A DESERT INSTEAD OF A FOREST anyway, the player is kinda small. you should size it up.
I was thinking of this, actually.
SpoilerSomething along the lines of the Pubg/Fortnite entrance into the game where you skydive in, but you want to aim for a tree or something to soften your landing.
MZ952#10
Replying to:raimondz
I like the minimalistic design. However, the game goes a bit slow on my O3DS. I even changed the number on line 703 but it didn't improve too much. Suggestions: - For color tile, you could use an sprite of 52x32 with zoom of 8 (SPSCALE X,8,8). That way the performance should improve since the game paint less pixels per frame. - Use GCLIP 1.0,0,400,240 before GCLS to refresh the pixels that are displayed on the screen. (It's not necessary to flush the entire page) - For the bottom screen, You could draw the screen once and use sprites to display the blocks near the player. If you don't want to use sprites, then the other alternative would be store the bottom screen on another page or variable and use GCOPY or GLOAD respectively. (Performance wise, GCOPY is better than GLOAD)
Ah, okay, that is actually a really simple function. I've implemented it, and on the N3DS there was no discernable difference in milliseconds per frame, but its a good precaution to take anyway given that I indeed do not need to flush out a 512x512 graphic sheet when I'm not using it all. Honestly, I didn't actually realize that the rest of the graphic sheet even mattered. I thought that you couldn't draw outside the screen bounds. Eh, anyway, I'm not so surprised it runs so poorly on the O3DS. I'll be testing it out on that console here soon enough, and hopefully I can figure something out. Lately I've been considering a kind of graphic screen emulator sort of routine. It would function similarly to a GPU, I reckon. It would store graphic drawing data after having drawn frame 1, and upon drawing frame 2 it would compare the numerov data between both frames and drop everything similar between them, only shifting around elements of the first frame and drawing in the necessary tidbits, instead of clearing and redrawing a whole frame 2. It probably wouldn't work that smoothly though.
MZ952#11
[poll=p314][/poll] Just out of curiosity. I want to support all consoles, but I'd like to know how much procrastination room I have on the subject. It occurs to me that I may need to redesign a few key elements in the engine to accommodate older systems. This can actually be done now by lowering the render rate of the game. The engine would perform the physics routine at a nominal 24 fps while the frame rate would sit at some other, lower value. This would mean that the physics routine would be called multiple times in secession before the screen renders. Game objects and events would be consistent across platforms, and only the rate at which the render occurs would be different. I want to avoid frame drops altogether, so I'd have to take the middle-upper bound of the refresh rate.
Simeon#12
Oh sweet this is cool! I love the tiny bounce effect, and the shadow, and digging animation, makes it feel high quality You should give the player a faster walkspeed :o
MZ952#13
Replying to:Simeon
Oh sweet this is cool! I love the tiny bounce effect, and the shadow, and digging animation, makes it feel high quality You should give the player a faster walkspeed :o
I had this idea of some sort, that as you play the game, the player gets "stronger." He can jump higher, move faster, do things faster, etc. With the collision engine as it is, moving at high velocity (one or two blocks per physics routine call) degenerates its abilities. If I get my grubby digits on a better collision engine, high velocity movement may become a pivotal game element, though.
IAmRalsei#14
Replying to:MZ952
[poll=p314][/poll] Just out of curiosity. I want to support all consoles, but I'd like to know how much procrastination room I have on the subject. It occurs to me that I may need to redesign a few key elements in the engine to accommodate older systems. This can actually be done now by lowering the render rate of the game. The engine would perform the physics routine at a nominal 24 fps while the frame rate would sit at some other, lower value. This would mean that the physics routine would be called multiple times in secession before the screen renders. Game objects and events would be consistent across platforms, and only the rate at which the render occurs would be different. I want to avoid frame drops altogether, so I'd have to take the middle-upper bound of the refresh rate.
why isn't Wii U an option? SmileBASIC is on the Wii U in japan, you know
IAmRalsei#15
Replying to:IAmRalsei
you start the game in a desert TOTALLY DIFFERENT GAME THAN TERRARIA YOU START IN A DESERT INSTEAD OF A FOREST anyway, the player is kinda small. you should size it up.
but then you'd need to start in a forest
chicken#16
Replying to:IAmRalsei
you start the game in a desert TOTALLY DIFFERENT GAME THAN TERRARIA YOU START IN A DESERT INSTEAD OF A FOREST anyway, the player is kinda small. you should size it up.
deserts grow trees and shrubbery
chicken#17
Replying to:MZ952
[poll=p314][/poll] Just out of curiosity. I want to support all consoles, but I'd like to know how much procrastination room I have on the subject. It occurs to me that I may need to redesign a few key elements in the engine to accommodate older systems. This can actually be done now by lowering the render rate of the game. The engine would perform the physics routine at a nominal 24 fps while the frame rate would sit at some other, lower value. This would mean that the physics routine would be called multiple times in secession before the screen renders. Game objects and events would be consistent across platforms, and only the rate at which the render occurs would be different. I want to avoid frame drops altogether, so I'd have to take the middle-upper bound of the refresh rate.
Starting to feel bad about being the only person who voted o3DS EDIT: meesa fine now
IAmRalsei#18
Replying to:IAmRalsei
you start the game in a desert TOTALLY DIFFERENT GAME THAN TERRARIA YOU START IN A DESERT INSTEAD OF A FOREST anyway, the player is kinda small. you should size it up.
shut up turkey
MochaProbably#19
Replying to:IAmRalsei
you start the game in a desert TOTALLY DIFFERENT GAME THAN TERRARIA YOU START IN A DESERT INSTEAD OF A FOREST anyway, the player is kinda small. you should size it up.
*mushroom tells a chicken to shut up*
IAmRalsei#20
Replying to:IAmRalsei
you start the game in a desert TOTALLY DIFFERENT GAME THAN TERRARIA YOU START IN A DESERT INSTEAD OF A FOREST anyway, the player is kinda small. you should size it up.
i never thought about this situation that way
12