Wednesday, August 10, 2016

The quandary that is room design

In game design everything is interconnected. Like a meal, you can't have as satisfying an experience if each of the elements on the plate don't compliment each other.

The game's use of Health or end states alter the way players move through the levels and how they approach situations.

And of course what are the objectives? That will determine how the player operates within the space, is there much backtracking? Do they break every crate and check every nicknack before they go? Does the layout give them a clear path, or branching paths? Is the map interesting to navigate, is it memorable, does it present a varied amount of situations, or is it the same stuff different room? There are alot of nuances to consider when designing a level. 



My inspiration for this current project, and a notebook that's now full of scribbled connecting squares, comes from a mental combination of the old choose your own adventure books, the zaniness of Dargon's Lair, the idea of these multi-faceted rooms, and of course a concept for a rpg influenced GUI I want to experiment with before I start coding the big project that will consume my life whole, garnishing olive on a toothpick and all. 

So the general plan is to build a handful of rooms that change over the course of the game, with multiple ways of moving about to reach the trigger for each, optional inventory items and character interaction. I like the idea of the player being able to completely ignore a quest or two because they don't like the character and want to give them the cold shoulder. I'm not going to give to much away, not because I'm worried of spoilers, but because there's not much to give away; but the general plan is to have a cast of misfit magical characters who guard a dungeon. The main character being a -captured and not always good at his job- thief who must now escape the levels of the dungeon. The immortal guards of which have become quite bored and disillusioned with the whole immortal guard gig, made a sort of game of their job in the hopes of keeping it from getting too incredibly dull. Hope to put up some sketches soon. Until then goodnight everyone ^^

Sunday, August 7, 2016

Life update summer of 2016

I try to do these every so often whenever I've been off development or just having posted anything for a while. Just to give a bit of a heads up, show anyone I'm still alive, and haven't abandoned game development.

Last I posted I was working two jobs and trying to make some money on the side with projects, that's not changed at all. But I'm farther along with those projects and future proofing production. Some are definitely starting to show promise.

On the more "life" side of things in the life update. I'm still in school... seriously considering changing one of my majors.. which.. would help me in literally everything I want to do outside of academics, this game development/my side projects/ writing, ect. as well as make my academics something I might want to pursue as far as a career, but we'll see what that means with my timeline for graduation. But whatever, I work enough to cover school and don't exactly have much in the way of bills, which is good because after school and car and gas I never have much in the way of funds. I bought a more powerful pc.. but quickly broke it, and it'll need repairs.. but I can't afford that right now considering car repairs sucking up that chunk of change. But my laptop is still kicking, and I have projects that don't require anything fancy that I'm working on, it's all just up to me to learn code and room/puzzle design. I have a goal of one game this year. We'll see how that goes. 

Tuesday, January 19, 2016

Maximize Your Learning: Code

One of the most important things a student or teacher could come to understand, is that learning cannot take place in a vacuum. Knowledge simply isn't retained without application. This is why homework exists kids, this is why most jobs will have you learn the trade onsite rather then just put you in-front of a screen with an instructional video, or rather, this is why you don't remember everything from that video or whatever they tell you on your first day, but rather you "get the hang" of it after a few days of being in the thick of it. Trial by fire.

That being said almost any video online discussing learning code will say, you can't just learn code, you have to learn code while making something. Which is.. obvious after the fact. But during it's a difficult and weird idea to wrap your head around.. like.. How can I make something when I can only attain the knowledge to first make it after I've made it. This sounds worse then the chicken and egg problem. If don't have the tools to make something how can it be that the only way to gain the tools is to make the thing?

TUTORIALS
And
The Stages of Learning that Accompany them.
Followed by
The Best Way to Learn From Them

Learning code stage one: No idea where to start

Now, the beginners answer to that is, look up a tutorial. But because often newcomers don't know how to do anything yet, they also don't know what they cannot do, or how difficult specific things are over other things. Or what the advice that guy on the forum post even meant; what are these Array, Global int. and if loop things they speak of?


Learning code stage two: You speak Latin, but your magic seems to work.

The ambitious amateur will often after a time of this learn to look up the very specific features they're being told about and watch multiple videos, and copy what they see onscreen into the program, often mistyping little bits and, not knowing what's wrong, getting frustrated to the point of starting over or quit.



Learning code the Intermission: It's-Not-Working-And-I-Don't-Understand-And-My-Career-Is-Over-Before-It-Started!

This last stage is unfortunately where most aspiring game devs get stuck and then.. well either quit or just stick with the excuse of "coding isn't for me, just can't do it." and then they focus their aspirations to working exclusively with art, writing, sound, design, or whatever small corner of production that looks as far away from coding. And there's nothing generally wrong with that path leading you to what you really love about video games, if you find you love being a producer or concept art, or sound, or animations guy more then you like anything else, that's fantastic. I'm just going to say don't let it stop you from making games. I spent years stuck in these last two stages of learning coding and years of unfinished projects and lost potential lessons because I let this pressure of never getting it to work or never finishing or not being smart enough, or ready to learn something, prevent me from making game. The important thing to learn from this temporary road bump in learning code is that it's one of those things that happens to everyone, and it by no way is a sign from above punishing you for trying something outside of your destiny, it's just a part of learning. You can overcome it. Honestly.

Learning code stage three: Learning in Application 

The best thing about stage three is you can jump to it at any point in your learning process; which does in fact mean, you are not guaranteed to go through stages one or two, you might just have the luck that you find the right tutorial and started with the right project and having everything fall together or apart in just the right way that you learned how to find your mistakes among the code, and the values of different functions and techniques of organizing data, and learned the math to make cool little features that do neat stuff. For some lucky people they stumble onto this stage in development earlier rather then later, but other struggle finding it. I think I've finally figured it out, it's not really a trick but i want to share it with you all because had I been told this years ago I probably would have some games under my belt.

1. JOIN A GAME JAM. Give yourself something external to pressure yourself into keeping at whatever tutorial series you're following and something that'll limit the scope of that project to something complete-able within a few weeks. 

2. INSTEAD OF GIVING-UP, FIND WORK AROUNDS. There's more then one way to skin a cat and coding is no different. Learning what bits are interchangeable gives you insight to the logic behind the specific function bits and syntax in your specific code. This learning feature by feature goal mindset helps you visualize and cement in your mind what the specifics you see in the tutorial are doing and mean within the program, having something constant to apply the short youtube videos to helps you understand the building blocks outside of the specific use displayed. It's like how learning to use a foreign word in a sentence is more useful then just learning a phrase that uses that word. 

3.OR JUST EDIT YOUR DESIGN. Good design is decision making that incorporates all elements of the work, it's not possible to see all the elements of the work before they're formed, so don't feel bad about throwing out the original blueprint you had while you're working. If the project you have doesn't look like it'll be as strong as this thing you thought before you started, go with the newer path you see it going. Especially if this new path interests you.

4. MAKE IT SIMPLE AND INTERESTING, TO YOU. If you're not excited or interested in working on it. Drop it. Nothing great has ever come out of someone who was only half paying attention, and no one has ever learned or remembers the lessons they learned from the school project that didn't interest them, also you'll make yourself miserable; don't let your hobby be something that makes you miserable. There were plenty of times I tried to make mini-games where the idea bored me but they were the only thing I thought I could make using the "beginners" level tutorials I found. And that's deeply frustrating because you want to make something interesting, but it seems like you can't learn how to make those things without making these boring games you don't yet want to make.

5. STOP BEING BORING AND MAKE GOOD SMALL GAMES. There is no reason for small or simple to equal dull. There are hundreds of small games out there that have limited coding and minimal design, that end up being interesting. These are the kinds of games you need to study. Try to think about all these simple features, and think of them in terms of what they could also do. This is where your design and creative skills pay off. You could do something interesting story wise, you could do something interesting art wise. You could just do something that's a kinda neat little mechanic. Just find something neat and small that excites you and make it, once you get that little neat thing, and you understand how you got it and what all your code is doing, then you've made it. Congrats kidos, you're a game dev.

THE BEST WAY TO "STUDY" A TUTORIAL

I'm a massive fan of the, follow with me step by step, line by line, regularly save and test to see if the code is working, kind of learning from tutorials. But at the end of the day, when you're new to a program and you know you're going to be referencing this tutorial more then once or trying to put your own twist on the feature you're learning to code. Backups and notes are a great thing. Now you can make a physical copy of the notes, which is brilliant, easy to access and good for following along. But what I've been doing that I've found most helpful when going through tutorials and organizing my notes/code. Is using something like google documents. I have a file for my code, a file distinguishing between each game program in that, and then i have files organizing between each tutorial, and documents for each tidbit of code with hyperlinks to that time in the video. 

This has been very useful for the long winded videos that near the hour mark, you can break it up into bits, with notes next to the label like, //establishing array in room, //global variables for array, // algorithm for bullet time, ect. This lets you start breaking down the large chunks of code in your head via their function piecemeal rather then trying to remember each step in the recipe as one massive meal you can visualize it as all the small bits of prep-work that go together creating the whole, which will make it easier to dismantle and use bits later to make other features.

Secondly you can copy the code down verbatim into your document so it can be copy/past utilized later for other projects, and you'll always know where it is, and be able to access it anytime you've got a computer. Having this with the hyperlinks to the section of tutorial explaining each bit eliminates the need to search through your youtube history or sit through the majority of the video when only a few minutes pertain to what you need. It saves large amounts of time and also gives you a space to store that new code function you just figured out even though you don't have use for it in your current project. Honestly I'd rather have a dozen small word document files with lines of code in them then a dozen or so versions of the same game because I don't know if I'll want to go back to an old build, especially when most of the code is exactly the same except for a few long coded functions. That might just be me, but I'd rather my builds be stored on the cloud where I can always access and edit them rather then on a single computer, or hard drive. I have lost so.. so many jump drives, and there's nothing worse then the computer bursting into flames and loosing everything you've been working on. 

And those are my tips to learning code the fastest, I went from almost never getting anything working after years of being stuck in the first two stages, to having a working understanding and building a game with my own unique twists that I coded on my own in the span of two weeks. All because of two things, I had a small project with a similarly small (achievable)scope and time-frame to make it in, and I was excited to make it.

That being said, I didn't have any art/animations, and there was virtually no story, or levels, so those are things I'm going to need to learn to do as well. Next time I'll probably have something up on one of those. 





Monday, January 11, 2016

Jam Log No.5

video
Wish you could hear the ricochet sound effects.

Using http://www.bfxr.net/ for all the sounds.


Camera implemented and basic bullet collision. What you don't notice is the character can actually walk through the walls at this point, just threw this in for visual markers of movement so i could tweak the camera code/player speed/ and view specifics until I was happy with it. Right now I'm attempting to code the enemies attacks/A.i. 

Realized I need to do this before I start working on the graphics. I do have a basic image for the aliens... but I remembered how I'll fall into this trap of making a hundred or so sprites before even having the code working, and I refuse to fall into that trap again. I'm by no means a professional artist and by no means have that conviction to let go of that "perfectionist" drive and complete the work. I had the problem back when I was studying graphic design, and I still have it turning in papers. Some day I'll learn it.. But the code is what the people experience in the end, and as a Game Jam much isn't expected of me in the way of either. I know given the time I can decent work with sprites, but I don't know I can complete coding the game as designed. That's my main milestone.. I don't have to implement all the levels, if it ends up just being a big courtyard with spawning blocks I'll still be happy, as long as they spawn and move the way they're suppose to. This post will go up in multiple parts, I'll add onto this post as progress/issues crop up, this is just an update to show despite my loss of progress to scheduling, I'm still in this. Five days to go guys.




Update 2

video


For some reason, the big enemy is invisible..

video


video

started brainstorming the aliens, like the color scheme, especially around the head, but not happy about the body shape yet. will need to work out more silhouettes. 


Update
video
Welp... the big enemies are still invisible, somewhere in my order of events the mind of the invisible monster destroys itself. Before I thought it was just invisible like when originally spawned, but the small hive mind of monsters that come out of it don't return... which, thinking of it now might be because I don't have something to in there to turn off their focus on the player.. brb. Whatever, that's still not working. Point being, I won't know if these is happening just right until I can see it interacting. I have to admit thought, I like how the code ended up having these guys converge towards the player, their movements are awkward as they fumble around each other trying to get closer to the player. I'll be fun to detail everything with nice animations and sound effects when all of this is done.


update
Wowza, that was an easy fix.. apparently... I had the little "visible" button for the big-enemy object unclicked.. don't know how that happened. 

Anywho now I can see what the problem is, first, the little mobs that come out of the biggie don't seem to be triggering their return, second the biggie is able to send out multiple waves, which isn't suppose to happen... not a bad idea though. This all needs some serious ironing. But it's getting closer to something that looks like a game.




Saturday, January 9, 2016

Jam Log No.4

KNOW THY LIMIT
video

Welp. The things I know I cannot yet do has grown, and I have learned. 
Here is the most updated version, the array and weapon switch system was not working, try as I may I couldn't follow all of the tutorial and my computer couldn't let me access the download the source material so I couldn't even compare the code side by side to see where I went wrong. I also now have a bias against learning code from programmers. Nothing against programmers, but the curse of knowledge I've found in devs whose education/focus was in code, rather then art or design, was stronger. Of course I'm basing this off a very small sample size of tutorial videos I've seen on youtube, I know programmers whose education is in code that could probably teach me just fine, I'm just saying of the educational tutorials I've seen on youtube, coding taught from those who started elsewhere has been easier for me to learn from.

So.. again, I've cut back and improved a little on what I know works, I've lost a few days to work but I'm not too far behind. I'm going to stop trying to add in things until I get this working like a game rather then a mechanic test. Then I'll see what I can do.




video
The player can now explode and the pieces come to rest, now the difficult part. 
I've worked it into the code that the player simply changes to one of the pieces thrown, to avoiding having to label and follow each individual piece thrown from the character, the character is changed into one of these pieces separate from their specific generation. The tricky part is coding it so that, first; you are thrown from the site of contact as if you are suddenly controlling one of the smaller pieces of gore, second the players control of the piece is removed during flight, third any possible extra contact with the enemy will not trigger another explosion, and forth once landed the player bit will regain control to the player and be able to be destroyed again, where the second contact with the monster (after this explosion) will result in game end.... an awesome stretch goal would be that the explosion damages and knock-backs any enemies within a radius as well. 

video


ALRIGHT!

I got a good part of the tricky stuff that I was struggling with fixed, reason I was having such a hard time is because I had my variables set in the wrong place so they were constantly resetting instead of having them in coded where they'd remain static. Basic mistake, but satisfying pay out. So, what we have now is a person that shoots, can blow up, regain his pieces, and become whole again. While exploding there is a grace period where the player is invincible after that if hit before regaining their parts the player explodes and game over. For anyone confused how this ties in with the game premise as specified in an earlier post, don't be alarmed, that makes two of us. I thought of something cool I wanted to code, and ended up being able to code it, I'll be damned if I don't run with it. Probably somewhere in the same universe this game is the story about a newly formed zombie, fighting of those who accidentally resurrected him, the alien invaders. He's a gun toting mostly blooded patriot of his planet and he didn't much like his evening being disturbed. I'm going to do minimum colors with minimum style, because time constraints and animations are hard. I have placeholders for most of what I'll need but I'm going to bare bones it until I have the enemy A.I. up to speed and something like a level laid out and coded. Basics being, idle, shoot, run.. maybe a flashing idle for damage idk. I still have to make up this alternate enemy and then try my hand at this mini-boss idea. From what I have with the player code it shouldn't be that far a stretch. What concerns me is the specific instances.. The player, dependent on health, has different abilities. Some are so easy as changing the speed of movement or specific passageways being accessible, and that might be enough. But it'd be nice if each instance felt different to play, without one feeling better or worse then the other. What I might end up doing is simplifying the instances again, streamline the design. I was figuring a verbal count would have been nice instead of a number hanging in the top screen, but really... for what I have ammo is irrelevant. It's not about saving bullets, it's about getting to the end of the map in one piece... that is one whole piece.. all together. The hard part is going to be designing and coding each of those so they can stand up in play independently, and of course fixing some animation in time for that. I'll have an updated video later this week. Night fokes.  



Tuesday, January 5, 2016

Jam Log No.3

video
Where we left off.

Shrinking enemies and "vacuum" weapon


video

video

I would include more but what I have now is incomplete and doesn't work yet. I'm in process of phasing out the vacuum and all my other sucking and gun related code for this newer system that allows the weapon switch. Maybe when I complete this new thing I'll be able to work it back under the new framework, maybe not. It's to early to tell. 

Today wasn't as productive as I hoped, but I think I'm still on schedule. After tomorrow I should have the shooty situation figured out and then it's on to coding in the enemies and working out the animation code (combining this set with that action ect)

For now, I'm going to take a moment to grieve a loss.
Vacuum gun Mark1. You were fun while you were with us, gone but not forgotten. Lost along the trail so many ideas have ventured with their makers. While you might not make it with us to the end of this game jam, we will carry you with us in spirit. We'll see you in another life perhaps.

Until tomorrow, where maybe after work I can finish this and have something to show you all, I realized I haven't given much of the premise here. 

So here is  a link tomy DevLog on the Itchio page for this jam, check out the other indie's there while you're at it, they have neat stuff, and they actually update it.

Jam Log No.2

Alright, I think I'll do these once a night, show something recorded from the morning and then what I have before I go to bed.

I got the vacuum weapon working, mostly. It pulls the player forward and I've tweaked the enemy's shrinking so that looks right. I haven't figured.. or tried yet to have the "bullets" destroy themselves after a certain distance, but that will be after I work out this cycling problem.

I worked in the cycling system from this tutorial with minor alterations. The primary being that I put the code for the player object in a Step event instead of a Create event, the youtuber said this would mean whenever the player switched guns any amo on the field would change as well,  I didn't have this problem, the amo stayed the same. What did happen though was the weapon specifics were connected with the wrong weapon. And I'm stumped how this happened, it appeared to have been working when I had four weapons, but when I switched back to the planned 2 (remembering my habit of biting more I can chew) the specifics of knockback (or in the case of the vacuum suckforward) and the type of bullets that came out was switched.. without any discrepancy in the variable naming as far as I can see.. which is weird because I have it labeled so simply. Now this in itself isn't a problem I would just figure I have something in the Hud Object listed wrong so it pulls up the string differently or.. whatever. I could just rename them. But what's really the problem is if I switch to the other while there are still bullets onscreen it seems to massively tax the computer. The game freezes.. so... I'm going to have to delete a bunch tomorrow, back to the start where I just have the vacuum working.

There is more then one way to skin a cat, and if this way freezes up the game it's got to go. I've got other tutorials for the same feature opened in tabs and I'll give them a shot tomorrow, at the very least I'll get enough of an idea of how to deal with global variables and strings that I'll be able to figure it myself, and if not that, then I guess the game doesn't need multiple guns. Plan tomorrow is to strip the game back to it's working version and finish working on that boss character. I have two related monsters and I'd be tickled pink if I could get them to connect the way I want, a variation on your basic big guy explodes into small guys. And if that doesn't work it's onto plan B, or I guess it's C, with the monsters and focus on these weapons, with a new stretch of QTE finishers.