Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[delphonso]

First project is done! Capumon!

Second project is done! Sewer Kings!

Gamejam project is done! Sleeper!

Come here to see whatever I'm working on now!
-=-=-=-=-=-

Nearly...three years ago, I posted in life advice talking about wanting to make games and where to "start" and how to make progress. I got some good advice and some useless advice, and I ignored all of it and did things my own way. Namely, wasted time  B)

Now, things are a bit better. In a cloud of depression, I worked through Harvard's CS50 course which did a lot to better lay out convention and how to think programmatically. It had the benefit of being 'easy' because I was familiar with all the actual code work, and instead focused on how to be a good programmer.

Oh hoh - by no means am I a good programmer now, but I'm on the path, maybe? Anyway, games.

I wanna make a game.

I have, technically. Several times, even more technically. There's the progress of the last year or so. But I want to make a game I'm proud of. Well, more proud of - and proud to show people and maybe people will enjoy that game and that's pretty nice.

So, how to make a game? Well, I've been working with Godot for a while and I really like it. It is also conveniently ported to Linux and runs well (except GLES3, but that's my own fault for having old and weak computers). So I'll be working in Godot to make the following two projects. For those who don't know, Godot has its own scripting language which is basically just Python. I haven't started on either project, beyond the pre-planning stages. Join me, friends, in making a game.

Project A:
2D, Pokemon-battler, proof of concept
I read about the original concept for Pokemon - it was called Kapusu-mon (Capsule Monsters) and was more about gachapon machines and getting lucky to find a "good" pokemon. I like this less dressed-up Skinner box. I also think about Pokemon combat and how it is...well, boring.

So the concept is the following:
'mon are gathered by putting money into a gachipon machine.
'mon have 3 attacks: Pure damage, damage w/ status effect, pure status effect.
'mon have an ability that effects the whole team, even when not in play (this is a card game thing)

Project goal:
Make a single room where the player can walk around and battle at least two enemy trainers.
Include 6 'mon with unique attacks and abilities.
Design this to be extensible. If it works for 6, it should work for 600.


Project B:
3D, magic system, stepping stone
Morrowind is my favorite game. Among the many things to love about it, the magic is what sticks with me. I want to make a game where you are some sort of battle mage in an arena, and participate in fights. Before the fight, you craft your spells by effectively slotting in qualities. I'm thinking something like the classic lightning bolt would be "line, shock" or fireball being "ballistic, fire, explosion". This one is much less thought out, but is something I really want to work on. I also think it is necessary to be in 3D, which is totally new to me.

Project goal:
Make a fixed-camera tavern and include a dialogue system.
Make a 3rd (or first? or both?) person arena battle scene.
Design 1 enemy fight, at least.
Have a menu with spellcrafting.
Design the magic system to be extensible.

[King Zultan]

I like the sound of both of them, but from the sound of it project A sounds like it'll be easier to do especially for your first time making a game.

[delphonso]

Yeah, both are intented projects. I'll work on both, probably in parallel, but the 2D thing should be easy to put together and shuffle off. Art is the slowest part, if the code is simple enough.

[King Zultan]

Are you intending to sell this once finished or will it be free?

[delphonso]

I think everything I make will be free. I have lofty dreams of a full game, and even then, probably free. Toady is a great example - I would just want people to play it and if it is good, they'll play it a lot and that's great.

[King Zultan]

I'm sure it'll be fun no matter how it turns out, also is it gonna be a PC or App game?

[delphonso]

PC presumably, Godot has some options for porting, but I've never touched android development.

I had set up a raspberry pi to run Godot and work on these projects, knowing that it would be a bit slow due to the weak CPU, but instead I'm getting some graphical trouble while running the "game". Might be an issue with XFCE, so I'm installing a different flavor of Manjaro now, we'll see what happens. Worst case scenario I'll switch back to my laptop.

That said, I worked a bit on Capumon tonight, I'll post a screenshot later - nothing visually interesting, just buttons linked to code. I'm working on the battle structure first, as I think that will be the most complex as far as code goes.

Edit:

Works on KDE Plasma, it seems.
So here's the basics of what I got done (really not much time to work on this so far.)


It's beautiful.

So, what are you looking at? Obviously, not a finished product. In previous projects, I found myself spending hours making assets for stuff I didn't even really know how to get working, so this time, I'm trying to get it working before any art makes it in. It'd be boring to show you guys just buttons and code, so I added in a little spice.

Spoiler: Tall boy, code example (click to show/hide)

The code itself is pretty simple - these are all place-holders that I will work to replace. Anything in "quotations" needs to be a variable or taking from a singleton (basically a part of the game that has all the important bits like names, attacks, health, etc.) Anyway, the player chooses an attack by pressing a button, the button is process by an Attack function, which will also switch the turn to the other player (computer). Later, this will also need to handle animations. I would like to use this function for both the computer and the player - but as you see right now, it is hard coded to Agumon Charmander.




Godot has a little terminal at the bottom, so I can see that there's no mistakes in this code so far - or at least, not terrible ones where the buttons are doing the wrong things. The text on the buttons can be modified by code - so the terminal text will match the button text when it starts pulling from whereever I put all that data.



It seems these screenshots are...tiny. Sorry about that - I have no idea why - maybe something with postimg? They look fine on the site, but when I put image tags around them, they get super small?

[delphonso]

Cleaning up the code to be more efficient and future-proofed.



I've begun commenting my code, which is something I need to remind myself to do - and also makes it clearer for the reader, hopefully.
Along with the 'mon's names, I also grab their sprites from the game's files. This is stored in a variable so that I can use it in the code and in the future, can just change it up here when I make new sprites and probably don't want them named "pika" and "char".

I then create a dictionary which is basically an array right now - but in the future, it'll contain damage types and amounts, presumably. I want to move this off to a singleton in the future, but for now, it's good.

After that, I put the sprites (not the images themselves, but the sprite object on the screen) in variables so I can modify them when you choose a new mon. I also get the buttons so that their descriptions can match the attack dictionary. Which you see happen in the ready() function.

I also set the sprites to have the images they should (and already) have. This is putting the same image on the same space, so not really doing anything of note. This will be useful when mons are changing.



The main body of the code gets narrowed down, thanks to the dictionary. The attack now grabs the active mon and finds the matching attack in the dictionary and prints it in a simple sentence - you can see that here:



And just for fun, you can see that Fire Blast also has the code playerActiveSprite,texture = foeActPic to show how these can easily be swapped out. Notice that the left pikachu maintains the other stuff that I did to the sprite - such as flip horizontally.




I moved to imgpile for image hosting, which seems to work better. This wasn't much work, again - just sort of doing what I already know and am confident in. Soon I'll start doing harder stuff like working with singletons.

[King Zultan]

Dang man your way further along than I thought you'd be, I figured you were still in the planning stages, so do you do this kind of thing for a job or something?

[delphonso]

I'm currently a kindergarten teacher, so the whole monster battling part is part of my day-to-day. But no, I only "finished" one game as part of a gamejam. I'd be interested in a career in coding, but for now it is a hobby and I hope to keep it that way for a while, as I'm enjoying this. Decided to spend a bit more time fleshing it out so here's a bit more:



Let's give Pikachu some attacks. A quick and dirty dictionary should do the trick. Again, these are just words associated with numbers - Ideally I could set up some sort of XML file (or the bare code equivalent) so that it'd be easy to manually adjust or add these critters. Might work on that next.



I now pass who is attacking into the attack() function, under the name "aggressor". The attack function doesn't look good because I would also need to pass the attack dictionary, and I want to find a better way of sending both down there.

When the turn switches, the enemy chooses a number between 0 and 3(inclusive of 0 but exclusive of 3, don't ask me why because I don't know) and chooses an attack based on that. Extremely basic AI in a go!



With some very simple code, I detach the battle scene from the main scene - this means I can trigger the battle scene however I want - probably through dialogue. The battle scene is preloaded, and then called as an instance whenever I want it to. I just need to hide the rest of the scene with queue_free or the button is right in the middle of the fight still. Eventually, the "main" scene will have nothing visible, and just sort of be a theatre for the rest of the game to pass through. Right now, it has a button and the battle scene is connected to that button:




Pressing this button opens up the fight we've seen. And looking at the terminal, we can see the basics of a combat game coming together!

[delphonso]

The long weekend is about to end, so I decided to get some progress done before probably taking a few days break.
I contacted a friend (who I worked on the gamejam game with) and asked them about singletons. A brief discussion later, and I had a good enough grasp to implement one.

First, I get a new empty script and call it "global", then tell Godot this is a singleton. A singleton, as my friend describes it, is a bit of code that is outside the rest of the game, but all parts of the game can contact. So, let's test it out by putting in a string and calling that somewhere else. Right now the singleton only has this: var exclaim = "oh baby!"


I change the turnswitch function to no longer say "Now it's the other guy's turn." instead it just calls exclaim from global (or, "oh baby!")



And it works!




So let's do more with this.
First, I fill out the singleton with a dictionary. A dictionary operates with "keys". Previously the keys were just 0,1,2 - but now they're more specific. This allows me to get names from every mon without needing to write them more than once (just in the singleton). Also notice that every type of mon now has a unique descriptor "monDic001", for example. I'll end up tweaking these later, but I filled in some generic (maybe useful) features for later.





I'm not very happy with how the effects, statuses, and teameffects look/work. This will definitely need to be changed in the future. For now, it's just a placeholder. With the dictionaries done, I can replace them on the main battlescene.

Since the dictionary also has the character's names, I can pull those from the singleton as well, instead of explicitly putting it in the battlescene code. This still needs to be improved so that it reads the player's team and the enemy's team, rather than just choosing these two mons only. I also grab the attack names from the dictionaries. I realize now, I can also put their sprite art in the dictionaries, to make that easier in the future as well.

Now that attacks aren't keyed by a number, my random integer between 0 and 3 is useless. I add the attack keys to an array, then send that to the enemy's attack in turnswitch(). This array will be useful for confusion effects too, as long as all the dictionaries use the same keys.

Spoiler: battlescene code (click to show/hide)

The end result looks the same but is much better, programmatically.

[King Zultan]

This thing is already pretty cool looking, do you plan of having mod support or are you gonna keep everything hard coded?

[Quaksna]

Can delphonso make a game? He sure can, this looks very promising!

[delphonso]

This thing is already pretty cool looking, do you plan of having mod support or are you gonna keep everything hard coded?

This is an interesting question. I think this capumon thing is going to be just a proof of concept and I'll release the raw godot files with it, in case anyone is interested to snoop around. Mod-ability is tough, as it would take me learning more about how to export games with Godot (specifically exporting a game with a few "raw" files that can be edited [off the top of my head, a xml table where people can add their own 'mons]). I might actually look into this for this proof of concept - as it is something I really want to learn.

Making it modable to like...make areas/buildings....I have no clue how that would work - honestly. Probably a huge undertaking.

Can delphonso make a game? He sure can, this looks very promising!

Thanks, Quaksna - I'll be sure to add an axe-wielding frog into the types of mons, when I get to it.

[delphonso]

Here's a post-week recap, basically.

I look at my hands, covered in monster blood and chunks of code...
What have I done?

Work began on Capumon (working title, I guess). I opted to focus on code and mechanical structure instead of art and design. This seems to be paying off, as I can feel improvements in the game already, and it is helping me better conceptualize how the game should look.

The game now has a very basic combat tracker (just repeating which move you use) and primitive AI (enemies randomly choose from their available moves). Mons are stored in dictionaries which contain their list of attributes. I could make this smaller with an array, but it would also make it less friendly for other people to mess around with, so I'll leave them in dictionaries. The game pretty efficiently stores that data and calls it when needed in the combat scene.

Code:
The code, so far, I am very happy with. It is tidy and decently complex. It is also completely and thoroughly understood by me, which is nice (normally there's at least one thing that works and I don't really know why). I want to clean it up more before moving onto the next part. That would include adding the art asset path to the dictionary and making my variable names more standard.
actMon and foeActMon drive me up the fucking wall. I could also do the thing more explicitly where variables_like_this are one type, and variablesLikeThis are another. Not to mention variableslikethis...

The next steps in coding will be:
Swapping active mons,
More robust AI,
Implementing the basics of attack/health/damage etc.
Begin implementing statuses

After the battle scene is done, we can start to have a main character, movement, an environment to explore, and the gachamachine.

Design:
I think I have a pretty good idea how to implement everything. The hardest part will be adding modifiers to attacks (such as statuses or accuracy damage). This will take some doing, and also balance needs to be considered. I don't think this game is making any great leaps in gamedev - no earth shattering new mechanics, but that's alright. It's just a little project, after all.

Art?
Maybe someday?
Kids around here are all about Ultraman - whose monster designs I'm a big fan of, and Ultraman was also a big gachapon thing. I might try to chibi-up some of the monsters from Ultraman/Gamera/old Godzilla and see what I can create. Otherwise, I can always go more Pokemon-ey and draw a cat with leaves for ears. Or Digimon-ey and draw a cat with jean shorts and a glock.

Actually the last one sounds pretty good. For now, expect more shitty google-searched jpegs.

UI design will be a challenge. It is slow, hard work and also requires some study on my part to get it to work well in Godot. Another challenge!

-=-=-=-=-=-=-

There's an upcoming holiday - which means an extra day of work on the weekend, but then a week off. I'll also start up Spookyfort, then, so time on this project is likely to diminish, especially as what I'll be doing will be getting more and more difficult. Might get some time to work on it after work, but that's strongly determined by whether my daughter falls asleep easily or not.