I’m working on cutscenes for Hardboot right now, on top of other life stuff. I’ll probably post a few screenshots of those, but not the whole cutscenes because spoilers. I built a system for making cutscenes in my engine using a simple interpreted language(I seem to use those for a lot of things), and I’ll just have to see how well it works for what I want to do. I’m not sure I’ll be able to make complex shots using it, but I don’t know enough about cinematography to make complex stuff anyways. I’ll be keeping it simple and hopefully it’ll turn out alright!
Not related to Hardboot development, but a friend of mine drew a sword the other day and I thought it was really cool, so I decided to make a 3D model of it.
Whoops, looks like I neglected my devblog for a few months!
Yeah, that’s not a good thing, and I know. I’m still trying to finish the game of course, but a lot of real life has been getting in my way lately. Finding time and spare motivation to work on the game has been difficult, and not a whole lot has gotten done. Don’t worry though, that doesn’t mean the game isn’t going to get done, or that I’m going to abandon it to work on something else. I may have been busy, but I’m still as determined as ever to see this through to the end, no matter how long it takes.
That end isn’t far away at all, in fact it’s laughable how much I’ve been dreading doing so little. Sure, the last 10% of a game is 90% of the work, but I don’t have much longer until I’m at that last 10%. Once I get there I can polish it as much as I see fit, and call it done anytime. I have a lot of other game ideas but I’m suppressing them until this one is done.
Look out for more updates soon. I’ve found some more time to work on this game and although I’ve all but given up on having a time frame the game should be done by, it’s always hanging over my head and I’m not gonna get over that until this is done.
Coding can be easy, and with a little practice, anyone can do it. If you've ever been interested in writing any kind of computer programs, I'd like to be able to show you how to start. This is a continuation in my series of coding tutorials, so if you haven't read part 1, you can go here to read it.
In the last tutorial, we set up the basic environment we'd need to make programs easily. As a word processor is to creating a text document, the IDE we set up is to creating programs. With this environment fresh and ready for creating, we can make anything we set our minds to.
If you haven't already, start up your eclipse. It should look a little something like this, from last time:
Ah yes, our old Hello world program. If you need a refresher on what it does, or how it works, you can go back to the last tutorial and check it out, or just run it yourself! Today we'll be creating a new "Java Project", as covered in the last tutorial. If you need help with that, refer back.
We'll be calling this new projects "Fields". Once again, you can call it whatever you want, but this is the name I'll be using. Once you've created it, open the folder for it in the package explorer.
Then, just like last time, create a new class inside the src folder. We'll be calling it "Fields". It should be noted your class name doesn't have to match your project name, but for tiny projects like this, it's just more orderly. Create the class, open it up, and your window should now look like this:
The first thing you notice might be that the new class file opened in a new tab. Tabs can be handy for working on multiple files that relate to each other at the same time, or referencing another file for what you're doing. You can close out "Hello World" if you'd like, but I would keep it open, so I could check my code against it if I was having any problems.
Either way, we'll be starting with a similar setup to the last program:
As you can see, we added in "public static void main" just like the last tutorial. You can look back to part 1 if you have any questions on that. Now, from here is where we do some new things!
First thing, I want to explain what these "Fields" we'll be learning about are. In programming, we need to make the computer remember things. Fields are how we tell the program "I need you to remember this thing for later". It should be noted that fields only remember things as long as your program is running. When it stops, it forgets all your fields.
A good way to visualize a field is by imagining a literal field. Imagine a large, open, grassy space, big enough to keep just about anything in. An elephant, a building, a single brick, whatever you need to keep there. Fields in programming are a lot like this, you just have the tell the program what you want to store in this space. Let's take a look at how exactly a "field" is created now:
Now let's break that down a little and take a look at what we just did.
"int fieldName;"
First, int. int is what we want the field to contain. int is short for Integer, or a whole number.
Second, fieldName. fieldName is the name of the field. We could change it to almost anything else and it would still work.
So we've just created a field that remembers a whole number. What can we do with this? Well first, lets give it a value.
now fieldName = 7. How can we be sure? Let's make the program output the contents of fieldName for you to see!
We used the same line of code from "Hello World", but instead of outputting a phrase, we output our field! Go ahead and run the program, and check out the output. Try changing around the value of fieldName, and seeing how it changes the output.
So, we can declare a field, and then send an output. Next, we're going to manipulate the value of our field, to change the output it gives us!
Go ahead and give that a run. You can see, it outputs first 7, then 11, which is obviously 7+4. What exactly did we do here? Let me break it down.
We couldn't just say "fieldName + 4" because the program wouldn't know what we were trying to do with that new number we created. We had to specifically state to the program we wanted the result to be the new value of fieldName. After fieldName got it's new value, we just output it again. Note, however, that we did NOT put another "int" before fieldName again. We only need to declare it once. Once the program knows what type of field it is, we don't need to declare it again.
But where things get interesting is when we start mixing our fields together! Lets create a second field now, and add it to our first field.
As you can see, we created a new field named "otherField", gave it a value of 5, and added it to fieldName. After that, we output it again to take a look at the results. The output should say 7, 11, and then 16.
I'm going to give you a few small notes here, now that you understand how fields work, a little bit. You have to declare a field before you can use it, always. If we had just put "fieldName = 7" first thing, the program would have no idea what "fieldName" was, even with the glaringly obviously "= 7" after it. You have to create the field before you can put anything in it.
Next, you don't have to give the field a value when you're declaring it. You can wait until later to give it a value, but if you try to use it before you give it a value, you'll be telling your program to use something that doesn't exist! That hardly ever goes well.
There are more types of fields, in fact, when you get to more advanced coding, you can create your own types of fields! For now, here's a few that form the backbone of the fields you'll be using:
int: I've already covered Integers
float: a "float" value is a Floating point value, which is a formal way of saying it's a field that can have decimal values. You'll notice the value assigned to it is "1.0f", that f means that number is a float.
double: a lot like a float, but uses "double precision". If you need a really precise decimal values, you'll use a double. There is no "f" and not even a "d" after its declaration because any number with a decimal after it, and no f, is assumed to be a double by the program.
String(Case sensitive!): A field that holds a collections of characters, meaning it holds words. Try creating a String field, and outputting it like the other fields!
There are many more fields than this, even more basic ones, like boolean, byte, short, long, and char. I'll cover those in later parts, though, as this tutorial is only focusing on the basic use of fields.
Fields are also VERY picky when it comes to being assigned to other field types. Converting from a float to an int, for example, can be tricky business. This is called "Casting", and I'll cover it in a later tutorial as well.
Be sure to let me know what kinds of material you want me to cover in these tutorials, and the more support for them I get, the faster I'll be motivated to turn them out. If you see any flaws, or have any questions, don't hesitate to ask me!
Happy coding!
Ok, it's time for a "devlog". I missed last week, and I have nothing to show this week. Some important family issues came up, and I haven't had the time or the motivation to work on my game. I managed to get a little enemy AI coding done, but that's about it. This week I'm going to try to get things back to normal, and have something to show you all. Thanks for bearing with me.
Tooltips, button indicators, and maps(in progress)!
This week I decided to start making the inventory a little more user friendly, by 2 means I've always intended to add. First, I added tooltips, so now you can hover over an item's icon and see what it is. I might add more to tooltips later, like adding descriptions, and icons, etc. Second, I added indicators to tell you where a button in the inventory will send an item. With the buttons all being "+" and "-", it's a little obscure what it's supposed to do. "- drops the item? unless you have a building window open, but only if the building takes that item?" - Imagine trying to figure that out without any help. I'm thinking of also adding a little tooltip to give a short description of what will happen to the item, not just a little red or blue indicator. "Dropped" or "Send to refinery" come to mind, which might make things JUST clear enough to work.
On top of that, I also started working on maps. I'm trying from scratch this time, as I now have a different approach, one which is far more promising. The simple way to put it, is maps are going to be as easy to place as a button, just say "I want a map of ____ size at ____ location, and I want it to focus on _____ room location, at _____ zoom level....". This way, I can set up maps, minimaps, and functional maps(You've died select a respawn point) in one swoop. I might also add a bitmap for which things to show, like you, your companions, any buildings or bases you have, regions and region names, if I get bored enough, I may even do GPS navigation in game.
Other than that, just various bugfixes, did some more multiplayer testing, just development stuff. This week, I'm really excited to work on those maps, so expect something prettier by next week!
Light bulb models, and movement to the next floors!
This week wasn't that exciting either, and I'm still trying to get back into the groove. I'm putting in less hours than I expect of myself and I'm trying to kick myself into shape.
Regardless, some cool things got done, the first being that there is now a model for the light bulbs, rather than flat textures that look like posters. I still have a little work to do on them, to make them look better and decrease the poly count, but I'll get to that later. I also created teleporters to other levels. One such teleporter can be seen in one of the above screenshots, although it still doesn't look good, I still have a lot of cosmetic work to do on it. So the big accomplishment this week is that the other levels now exist. They still look exactly like the first level, and the overall world generation needs a couple tweeks(Interestingly, when you enter the above levels, it generates the world without you in mind, so you're on a little island with no doors. no fun.)
Every week I move more and more from functionality work to content work, and I think it might be that shift that's really hitting me. One of my biggest flaws while working is everytime I finish something, I feel the need to take a break. While doing functionality work, that's fine, that takes hours to finish something, but on content work... everytime I churn out a piece of content I get the urge to take a break. I just need to break myself of that habit and push through. I'm excited for what this game is and is becoming, and I want to see it through to the end.
So this week I'm going to work on content a bit, more enemies, more items, more floors. Hopefully soon there will be more than 10 minutes of things to do!
The past two weeks have been filled with sickness, being out of town, and generally being too sick and busy to really do much work. There was no devlog last week due to the fact that I was out of town.
So what did get done? A little bit, small things I've been meaning to do for a while. I finally added the 4 player server cap(which I may make alterable, I might not). I also reduced the number of threads used for client server communication.
Gameplay wise, nothing got done. I have no screenshots to show, and nothing exciting to talk about. Not much work got done, and that's ok. Making sure to take care of yourself is key in maintaining motivation on a project, and I've gotten some good rest. I have 4 days off from work this week(including today), and I plan on using them to rest from my everday life and get a little game development done.
Next week I'll have something more exciting lined up, hopefully. I'm not sure what I'll work on, really it'll be whatever I decide to jump into at the time.
