Envision, Create, Share

Welcome to HBGames, a leading amateur game development forum and Discord server. All are welcome, and amongst our ranks you will find experts in their field from all aspects of video game design and development.

What are you working on? (Game Making Thread)

My mind has been on level design. Or maybe I should call it level presentation. I'm trying to figure out what elements make a game replayable. Or is it rememberable? Some games are a pain in the ass to start a new game. Others, I could play just the first level 100 times. Remember PlayStation demo disks? I still like to play through some of those. Spyro. Tomb raider. Ff8`s Dollet mission, which is a little different than the real game. They really knew how to sell a game.
 
I don't have my computer so all I can do is think about what I want to do for a Halloween project.
I thought about doing something with a gravedigger and a necromancer. But I just spent is morning helping dig a grave. And as I'm typing this I'm downwind of something dead in a ditch. So its had to fantasize about any thing to do with death at the moment.
I
 
2015-09-26_19-18-46.png

2015-09-26_20-18-45.png

2015-09-27_11-04-17.png
 
CQgDhtOWIAAs9Lb.png
CQgDhtTW8AAv9SW.png

More minigame updates for Riot Grrrl. Pretty much done with all the revamping now! All the minigames now had a consistent look and overlay system that I think makes them a lot more intuitive; it also means that I don't need text-based tutorials the first time you play a minigame any more, which makes things run a lot smoother!
 
Created a nice login system using cookies and sessions, then realised it's completely unnecessary, because the game client can hold the data a cookie would have stored anyway.
 
I released a new updated for Engalia that squashes some bugs and makes the dungeons a bit more fun to explore, and I've been taking graphics ripped from Crystalis and adding them to RM2K/3 templates so that I can use them in a future project.

I've not been doing as much work on SL: Riot Grrrl as I probably should be, but I've been getting some stuff done. I'm currently working on improving the look and dialogue contained in the "convobattles", which are basically a rock-paper-scissors minigame that allow you to avoid standard battles against certain NPCs (and gain more EXP for doing so). I've accidentally made a lot of work for myself in how I've decided to spruce up how these sequences look, but they'll look a lot better when I'm done.
 
Thinking of simplifying visual equipment / character customisation by having one of each graphic and several palettes which a script will swap on the fly.
 
Princess Amy":1xvawplu said:
JavaScript is too complicated.
It's not complicated, it's just far too simplistic.

There's no one-way to do classes because there are no classes.

It's also a pile of shit. One of the worst scripting languages I've ever seen.
 
I've got my character creation scene working now. And it's using text and ui that matches the graphics in the game.

In game menus and chat though will HAVE to use different text. It takes up too much space to have any meaningful conversations otherwise.
 
Spent nearly all day yesterday (Veterans' Day, a federal holiday in the US) trying to figure out why this:

GoblinsFixed.jpg


Kept coming out looking like this:

GoblinsEyesWhiteMessedUp.jpg


Eventually figured out it was a compression problem. UDK cuts all your textures into 4x4 squares and assigns each one a local palette. The black/white parts of the eyes next to the green skin were providing just too wide a range for the engine to come up with an appropriate palette. (The green doesn't bleed into the brown of the loincloth because that's a separate texture layered over the goblin base.) I found a workaround though: I just have to make all of my textures 16 times as large, and then each 4x4 square will be only one color. For the top picture, I only had to increase the resolution to 4x. The color isn't perfect, but it's a lot better than it was before, and probably as good as it needs to be for the intended camera distance.
 
Planning expansion packs for my game. I want to rush in and implement the whole of Old Afar in the new game, but that would be silly and overwhelming and I'd never get it done. So I'm breaking it up into smaller chunks that I can release frequently.
 
After months of research, two proof-of-concept tests and 2 weeks of solid banging my head against code I finally got the first half of an incredibly awesome texture streaming system working at a very basic level.

Had to redesign this system more than 20 times!

The psuedo code for loading an image into GPU memory is;
C++:
<span style="color: #ff0000; font-style: italic;">/* Renderer initialisation */

xiSharedLibrary * const sharedLibrary = fileSystem.CreateSharedLibrary( <span style="color: #666666;">"ren_vulkan10" );

api_renderer_t rendererAPI;

sharedLibrary->GetAPI( <span style="color: #666666;">"api_renderer", &rendererAPI );

xiRenderer * const renderer = rendererAPI.Create_f();

 

<span style="color: #ff0000; font-style: italic;">/* Pixel buffer initialisation */

xiBuffer * const buffer = renderer->CreateBuffer( 0x100000 ); // Create GPU memory

xiAsyncBuffer * const asyncBuffer = <span style="color: #0000dd;">new xiAsyncBuffer( buffer ); // Create asynchronous stream manager for GPU memory

 

<span style="color: #ff0000; font-style: italic;">/* Image loader initialisation */

xiImageLoader * const imageLoader = renderer->CreateImageLoader( asyncBuffer ); // Create image loader, targeting the GPU asynchronous buffer

imageLoader->AddImageFormat( xiTGAImageFormat::SINGLETON ); // Add TGA support for this loader

 

<span style="color: #ff0000; font-style: italic;">/* Load image */

xiReadStream * const readStream = fileSystem.CreateReadStream( <span style="color: #666666;">"texture.tga" ); // Create file read stream

 

xiImageSource * const imageSource = imageLoader->CreateImageSourceFromStream( readStream ); // Create image source

if ( imageSource->LoadAsync2D( imageSource->GetWidth(), imageSource->GetHeight() ) ) {

    // readStream is now loading asynchronously on a second thread into buffer

}

That is a lot of code for simply decoding a texture, but what will happen is the ::LoadAsync2D() will be called automagically when a texture is needed at a certain resolution and the buffer/asyncbuffer is shared across image loaders, of which there are only a handful, so in practise it will be;
C++:
xiImageSource * const imageSource = imageLoader->CreateImageSourceFromStream( readStream );

xiTexture * const texture = renderer->CreateTexture( imageSource );

// The pixel coverage of the texture is passed to ::LoadAsync2D() by the material management system
So now I'm going to be working on getting the texture data to display again which is the 2nd half of this system.

After that, I'll need to sort out how other mipmaps are handled. Some formats will contain the mipmaps in them (the texture binary format I am developing will certainly do this) and some formats, like TGA, have mipmap 0 and will need the other mipmaps generated after 0 is loaded. No clue what I'm going to do for that.
 

Thank you for viewing

HBGames is a leading amateur video game development forum and Discord server open to all ability levels. Feel free to have a nosey around!

Discord

Join our growing and active Discord server to discuss all aspects of game making in a relaxed environment. Join Us

Content

  • Our Games
  • Games in Development
  • Emoji by Twemoji.
    Top