Merrak's Isometric Adventures -- Artificial Intelligence!

merrak

  • *
  • Posts: 1962
More progress made in the past couple of days  8)

I now have full text box support. Here is center justification


Left justify (right is also supported)


And, after some debugging, full justification


I don't want to get caught up in feature creep, but I realized this toolset can solve a wide variety of problems. For instance, getting the little damage and HP numbers to show over characters will be much easier using the UI tools.


A ridiculous amount of code goes into the inventory card system. That entire system can be replaced with much cleaner code using UI tools.

The next thing I need to tackle is integrating actors and images in the toolset. This will allow me to solve one of the original problems--making a tile selection menu so that tiles can be selected from a palette. I also need drop-down menus, since I need to be able to select from multiple tilesets. Plus, having the usual file, view, etc. menus would be helpful... as well as scrollbars so I can move around larger maps.

SadiQ

  • Posts: 1769
Is the text in that textbox intentionally missing words or are they hidden for some reason?
Can't wait to see how you manage to create  dropdown menus.
Proud member of the League of Idiotic Stencylers! Doing things in Stencyl that probably shouldn't be done.

Bombini

  • *
  • Posts: 945
Very cool progress!

merrak

  • *
  • Posts: 1962
Is the text in that textbox intentionally missing words or are they hidden for some reason?
Can't wait to see how you manage to create  dropdown menus.

I should've picked better screenshots for the first two :)

There was a bug that was causing the last word in each line to be dropped. I caught it while debugging full justify, but it was related to a different part of the code. I may not have noticed it if I didn't use part of the Stencyl FAQ as a test passage. The first two used a paragraph from one of the earlier posts, but if you use your own writing then sometimes you see what you think it says and not what is really written.

Very cool progress!

Thanks!

merrak

  • *
  • Posts: 1962
I got menus up and running. Menus were fairly simple to implement. What took longer was getting interactivity (mouse-over detection, click detection, etc.) Since each UI element is a bitmap, I had to set up code to re-draw the image when something like the highlight color changed.

Here are some (large) screenshots showing some code and the result. A lot of this could be streamlined. For instance, I can set up a custom block to handle most of the configuration. In fact, I'm realizing configuring a large number of UI elements could be a pain. Next idea up--allowing for parameters to be read in by an XML file. This would give a CSS-like definitions system where a default template can be read in via XML and blocks can be used to configure individual parameters.

Code that sets up the menu bar:

Code that sets up the sector menu:

Result:

Not shown in the code: a mistake. Looking over the images, I realized I forgot to make the menu items children of the menu bar. It'll work, but one feature of the parent/child system is that if the parent is removed, the children are removed, too. Also the children will follow the parent if the parent is moved.

Also not shown, I did confirm tweens work. I provided a block that returns the bitmap itself and was able to get a nice fade-out effect. While the map editor is utilitarian,  I'd like to use the UI code to support the in-game interface as well. When I'm done I'll roll up these blocks into a proper extension.

« Last Edit: December 17, 2017, 11:35:24 pm by merrak »

merrak

  • *
  • Posts: 1962
2018! I spent most of the holiday period visiting family, so I did not get much done. Still, I did take a few significant steps. My GUI system is coming along. Menus were particularly challenging, but mainly because I had to write the core-level routines that will support the other GUI elements I need.

Here is the completed block set. It's now easy to set up a menu and its corresponding action. Notably, the routines now support managing child GUI elements. In earlier versions of the blocks I showed, every individual element had to be constructed manually. This wasn't too bad for the close confirmation dialog (three elements: background and two buttons). For menus, though, each option is its own element. Now I can just create the menu and add options with one block.


Result:


I also made most of the tiles for the revised "classic" Temple of Idosra, using the 8-color palette. I drew most of these during downtime visiting my in-laws. I showed my nephews how to create a room (still using Tiled). Some rooms we came up with:



I also showed them how to play the original game from 2016. I never watched anyone play through it before, so it was interesting to see how they did. I think the platforming at the beginning may be too challenging. My oldest nephew (age 9) managed to get the ivory key after several dozen attempts at jumping over the lava. For those unfamiliar with the game, this challenge is one of the first encounters. After he managed to clear them, his younger brother took the controls and promptly died.


I also wrote up the exp points, HP, damage, etc. table on the plane ride back home. Originally I was going to dump exp points entirely, but I've turned around on that. I wouldn't expect anyone to be familiar with ACK!MUD, but it had an unusual leveling system. Rather than gain levels by gaining experience points, players had a choice of different classes to level up by spending experience points. The MUD server I wrote, derived from ACK!MUD, took that a step further, allowing for leveling up individual skills, primarily by spending experience points, but also by finding books.

The system I wrote up for Idosra is similar. The player gains experience points and can find books in the temple. Reading a book provides a skill and costs experience. Furthermore, most experience points are gained by completing objectives or finding treasures and secret areas, not killing mobiles. Idosra isn't meant to be a long game, so I'm trying to stay away from killing mobiles to grind experience. The player must find the books and earn enough experience points to learn from them. I also get to think of clever titles for the books  :P

mdotedot

  • *
  • Posts: 1420
Great read as always.

Nice progress on the menu system.
In the past I've made some attempts to do GUI stuff but it never actually works 'native-intuitive' across the different platforms.
Technically it works, but the GUI implementation does not behave like the user of the platform is used to. Navigating both with keyboard + mouse for instance.  I kind of am waiting for some poor fool to do a platform wide GUI system implementation :D

Playtesting (with kids and elders) is really nerve wrecking. Especially when you are in the view of the user who will look at you for help/hints.
In general we tend to know the game so well that we forget that children and elderly people (yours truly included) have a problem dealing with the controls.


Hanging out in the Chat:  http://www.stencyl.com/chat/

Proud member of the League of Idiotic Stencylers! Doing things in Stencyl that probably shouldn't be done.

merrak

  • *
  • Posts: 1962
Technically it works, but the GUI implementation does not behave like the user of the platform is used to. Navigating both with keyboard + mouse for instance.  I kind of am waiting for some poor fool to do a platform wide GUI system implementation :D

I realized I can't design a GUI that appeals to everyone. But I can at least write one that appeals to me :D

For apps that are primarily "functional" (editors, etc. that rely on an efficient UI), I still think HaxeUI is the better route to take. But as of now, HaxeUI is in alpha, the OpenFL backend is in alpha, and Stencyl 3.5 is still in beta (and I'm still using 3.4 stable). For games, though, I think there's another, larger issue with HaxeUI--it's not Stencyl. From what I've read, HaxeUI primarily relies on CSS files to define the look of the interface. Stencyl uses images and actors. A better solution should integrate with the tools Stencyl already provides.

Playtesting (with kids and elders) is really nerve wrecking. Especially when you are in the view of the user who will look at you for help/hints.
In general we tend to know the game so well that we forget that children and elderly people (yours truly included) have a problem dealing with the controls.

I don't think they play a lot of computer games. They have tablets and a PS3 that I've seen them play, but keyboard controls were unfamiliar. What gave them the most trouble was using two arrow keys at once to move in a cardinal direction. This could have easily been solved by allowing for use of the numpad to move in eight directions. I don't know why I didn't think to do that. The directions are even referred to as "dir4", "dir8", "dir3", etc. in the code and animation files.

May 2015 image set... 1 2 3 4 6 7 8 9

Bombini

  • *
  • Posts: 945
+1 on this!
I play tested as well with regular age and older players (50+). Simulating a twin stick shooter on a keyboard (like in Space Pirate) feels very natural for me but no way an older person would understand it. That's why its very important to define first which audience you want to reach and not only pick the right theme, gameplay and mechanics but also the righ UI and UX.

Especially before getting into the project full force.
For me its ok. I dont expect older players to play the game.


merrak

  • *
  • Posts: 1962
...That's why its very important to define first which audience you want to reach and not only pick the right theme, gameplay and mechanics but also the righ UI and UX... For me its ok. I dont expect older players to play the game.

5-8 year-old's isn't my target audience, but any feedback can be useful, too. They wanted me to make a game with their favorite superheroes. I tried to explain why I couldn't do that and had to make up my own characters instead.

merrak

  • *
  • Posts: 1962
Art Direction. Lately I've been putting a little more thought into the direction I want to take the "full game". Although I'm still working on the re-release of the low-resolution, low-color Temple of Idosra, it doesn't hurt to think about where the rest of the series will go. For one thing, I don't want to write myself into a corner with the storyline (although it's pretty sparse in the original game).

Art is a bit more difficult to figure out. I've changed the character designs several times, often motivated by technical reasons. Such is the case with the latest revision.

I'm thinking that flat colored sprites would do better than fully shaded ones. Backgrounds, on the other hand, would be fully lit and shaded (of course, otherwise why put in all that effort into the shadow code? :P) A good example of the look I'd like to have would be the appearance of older, animated Disney movies. Below is an example from Disney's 1967 The Jungle Book


Notice the differences between how the foreground and background are rendered. I've always liked this style. I'm not a fan of the CGI style animation so prevalent these days.

Here's what I currently have for Marika (the heroine), old and new:


With no background the lack of shading on the right is more obvious. Despite the lower detail, there's a distinct advantage to the flat shading approach: Vallas Engine cannot render 3D sprites. I realized this while loading all the tiles I drew earlier into the engine.  I had to redo some of the maps I showed earlier because every surface in Vallas Engine must be a rectangle.


The error in the image above is in the stairs. For most practical purposes, I cannot render the triangle portion below the steps.

There are exceptions. The infamous "Goat Problem" from August, for one. While a non-rectangular object can cast a shadow, it can't have a shadow cast upon it without a few sacrifices. I can treat the goat statues as cylinders and draw the details in such a way that the shortcoming won't be noticed. Moving sprites would be too challenging to shade, though.

I realize I can move to a fully 3D engine and get around all these limitations, but for the same reasons I've written about before, I don't want to do that. When things to come together, it's neat to see it work and fully understand how it works*. I'm also still hoping that working within the limitations of my own design will give the full game a unique look that sets it apart from other 2.5D/3D games out there. (Although I'm also coming to the realization I may need to hire an artist to bring the full thing to life.)

* Admittedly, I sometimes have to remind myself and re-learn how my own code works. Tip of the day for larger projects: Document, document, document!

Bombini

  • *
  • Posts: 945
Hey,

some thoughts on the 2D,3D render topic.
I would always decide in context and in the size the player will see the sprites (do you even see the difference if they are small for example).
You example with both versions next to each other shows obviously a huge difference (and yes it a creative choice).
But, putting the sprites in front of you levels shows (again matter of coice) which version is visually better readable.

In the end i would pick you preferred choice combined with (do i recognize the details of the animations) which i think is the "flat" or "simpler" version.

Cheers!

merrak

  • *
  • Posts: 1962
I was just thinking that I should draw up a mock room (and the characters in isometric perspective) to get a proper comparison. I've tested the software renderer at 720p and it works at an acceptable framerate. I'm fairly confident I can get it to 1080p, meaning that the sprites would be roughly 1/2 height and 1/2 width of the size shown. So I think that's a good point. Definitely should put it on my to-do list!

Although talking about sizes brings up another point I've been thinking about. The standard room size I've been working with for a long time is 12 x 12 x 4 tiles (32x48 for web/Flash version, 64x96 for desktop). But are tiles even the way to go?

The single most complex part of the game's engine is the code that translates a tile based map into walls. I spent a long time on the rendering code--but the hard part there was the math. There's maybe a couple hundred lines of code that deals with rendering. Building walls out of tiles, on the other hand, is a mess.

I was reminded of this when trying to implement the new tiles I drew up. First (as mentioned before), I can't have triangles. That's okay. I'll just make a set of pillars of various heights instead. Well, not so simple, because now I have to add more cases to the wall optimization code. Okay, done. Now I have to add more cases to the light model code. Thankfully, my debug console is working and actually producing useful error messages. Without it I'd be totally lost as to what needs updating.

I'm going to stick with tiles for now, but I think the next generation of the engine (desktop generation) will move to a vertex-polygon-sector-based map (like Doom levels) and away from tiles.

merrak

  • *
  • Posts: 1962
Cel Shading was the word I was looking for... or so I thought. Turns out I might be wrong on that. In any case, I tried to find a name for the elaborate background/flat-shaded foreground 'technique' and "cel shading" was the best I came up with. I did find an interesting read on that subject and games (link!), but most of it is just about terminology and 3D engines. Much of it doesn't apply to me, since I'd be using 2D art.

I threw together a quick mock-up using some old screenshots and one of my flat-colored sprites. I can't say I'm all that enthusiastic about the result, but I also didn't spend much time on it. I spent quite a while trading glances between it and some screenshots of older animated movies, trying to figure out why it seems different. The 1939 Gulliver's Travels was a better study than older Disney animation. It's harder to search for screenshots of Disney movies without getting a bunch of fan art that is much more elaborately colored.


I think one the biggest issues is just that I'm overthinking it. The others issues are more obvious, but also have more to do with the time and effort spent on the image than the technique itself.

I have a lot of time to sort this out, so it's not an immediate issue or anything like that. The most important thing to work out is what updates, if any, need to be made to the renderer between generations of the code. If the smaller-scale versions of the game prove to be popular enough, maybe I can justify hiring someone to do the art. Funding that is a whole new issue I'm not ready to even think much about right now. First things first--small scale.

merrak

  • *
  • Posts: 1962
Map Editor! It's a rainy day in the Carolinas, but that means it's a good day to get some serious gamedev done 8) I'm rather happy with how my map editor is progressing after I got the core GUI code functioning.

I was beginning to worry I had gotten too far off on a tangent with the UI and menu code. I still have more to do on that as well. But after I sat down and started using it to produce something, the time spent working on UI code really paid off. Putting together menus and selection dialogs is a snap. I still have some more UI elements to implement: option boxes, input boxes for text and number entry, and scrollbars. But now I have some needed affirmation that I'm on the right track.

Here's a few screenshots showing the editor in action. Lots of large images!


Getting into the map editor using the debug console. One nice thing about building the map editor off the same engine as the game--if I want to, I can drop to the console with backquote+escape and enter the map editor to make live changes. Although the changes I could make to a game in progress are limited. There's more to a map than just tiles, since all the wall and wallfaces would have to be recomputed.


I now have several palettes of tiles to choose from. This selection dialog was put together using the GUI toolset.


Selecting a tile. The GUI toolset now supports background images and I can tween them a bit (not using the 'official' tweens, though).


I made a small room. Sector assignment isn't implemented yet, so I couldn't make this a playable map. Still, I'm looking forward to the new possibilities this editor will open up--towers, vertical maps, interactive tiles to name a few. Programming anything interactive, like doors, has always been a huge hassle. That was the case even all the way back to the original game.


There's no file saving :( Goodbye, 'Hello, World' room! You'll be missed.

One of the biggest benefits is the array of little things that make editing easier. For instance, Tiled uses (x,y,z) coordinates, and Vallas uses (row,col,level) for maps. Swapping the row and column coordinates is a huge hassle... particularly when debugging. If an error occurs at a particular (r,c,l) coordinate, I have to go to the Tiled map and convert to (x,y,z). It may not seem like that big of a deal by itself, but it is in conjunction with other little nuances.