Switching from osx to ubuntu …

Also readable as :

A small step for mankind, a giant leap for a man

Yesterday evening i was attempting my first map/background generation.

My idea was something like:

  1. i create a noise generator from a seed
  2. in a 2d Array i select random values for each tile
  3. i draw the “greyscaled” color of the random value.

Yeeaah! fantastic.

The problem was that the step 1 , on osx doesn’t work: the seed passed to is ALWAYS a wrong type.

Therefore today, strenghtened by 12 hours of sleep, i downloaded virtualbox , i downloaded an ubuntu iso , and started configuring my new environment.

At the moment, after some screen resolution problems ( solved by this  and this ) , i have a full working environment: i copied all the sources and once again ,thanks to magikmw (always found on the chat , here ) i had everything working.

With this change , i should have avoided all the problems related to libtcod under osx.
I’m not totally happy about this: it’s the first time i’m not achieving something with my cracked screen (yeah, literally) mac, but after all …who cares.

Next steps for me will be absolutely code-related:

first i have to understand if the way i’m writing stuff on screen is correct, and after that (probably in inverted order) i’ll have some more “map testing” .


I’d like to post a screenshot of the first noise (i think that calling it “map” is outrageous) i generated…. but to add absurd problems to my development experience… i can’t take screenshot of the terminal in virtualbox :|

Well, solved: magically it was because the 3d acceleration must be disabled to take screenshots ( … ) here’s the first test:

Noise generated with seed

Engine or not engine

In these days i’m investigating on the engine vs non engine opinions around the web.

My first resource was this episode of Roguelike Radio, ( link ).

Which just for a coincidence had as one of the topics “The motivation for a roguelike library/toolkit, the limitations of curses, and the failure of attempts at bigger generic engines”.

After a bit of research and comments,  the user Trefall posted a very useful link ( link here ),which i think it’s an older post on the topic.

The “non engine” group of users have as main points observed that

  • a game engine without a game over it is useless
  • the risk of making a “too much generic” engine causes big heavy engines ,which hasn’t an optimal way to solve requirements that a game developer could have.
  • If you have no experience on writing a game, it’s not a good idea to create an engine

While all these opinions make perfectly sense,my theory is a bit different:
based on my previous experience as a developer , i do not agree with almost everything said:

To do my job i use a php framework (Symfony ) that allows me to create sites and web applications in a matter of hours.
If i had to make all that i do with a single symfony task, i’d use days of work.

In just a bunch of lines of configuration i can build a whole database and the admin generator “modules” which allows me to handle CRUD interactions with the database.
It’s a matter of 5 minutes.

I think that  every branch of software development has its standards and its way to create a common set of instruments that can make the job easier.
That’s why i think that the first assumption is wrong: a monkey wrench isn’t useless just because it’s sold without bolts.

I agree with the second assumption,though: a too “wide” engine, does not solve any specific task good enough, and therefore is not an advantage,therefore to have success, i think that an ideal engine must be very small and mustn’t try to solve “everything” ,but just a limited list of tasks.

I totally disagree with the last aspect : i think that writing a game and writing an engine are two totally different jobs.
It’s like saying you can’t be a mechanic if you haven’t got the driving licence.
This is obviously a wrong assumption: to be a mechanic you need certain skills and knowledge, to be a driver, you need others.
The objectives of building a game, and the objectives of building an engine (or set of instruments, if you prefer) are totally different, and i think that the only point of contact of the two environments is the game logic: that’s what a game developer should put his/her head!
I think it’s useless to waste time in common tasks like splitting the “layout” in zones, building menus, and so on: a layout is always a layout ,and the fact it’s split in several areas shouldn’t occupy more than 10 seconds of the developer time: it’s not a part of the game logic.

Every minute put in the development of not “game-related” features is taken from a game-related feature: a game developer should use his/her (usually short ) time to think about the game, and not to think about the things you need to make the game.

Just to make another example, the same goes for a menu: you can change colors, and something else, but its purpose is always the same: giving you the opportunity to select an item of a list. Why waste time on that?

I know that frameworks exists in almost every development branch, from o.s. to web applications, they exist in almost every language: c++,  java, python,php ,etc.

So why in the roguelike world should be stupid ?

For the moment i don’t have enough data yet.

My research continues: my objective is to build a very unusual game, and to reach that goal i need instruments ,now they are small enough to be used almost anywhere.
If they get bigger, that would probably create some problem.

Scrollable text and Keyboard handlers

Tags

, ,

Today i’ve made a few progresses, and added some details.

I realized that the structure i created for the consoles and keyboard handlers didn’t work:

i can have in the same page different consoles, and different kind of inputs: for example in the main area the arrows could move the player, and in a side bar a menu could be used with the keys +/- .

Today i merged keyboard handlers from consoles. In this way more than one “receiver of input” can be active at the same time.

While working on it i made some changes to the scrollable gui as well: now there is a plain visual indicator that shows if there is the scrolling or not:

Scrolling arrows

For now, i didn’t put any style on them ,but as it can be seen, there are now arrows: a couple in the scrollable menu in the bottom left corner , and another one in the right side, where the textbox area is.

The nice thing about the text box is that it is initialized by a bunch of text, and depending on the position relative to the console, the text is fit on the area.
The result is that without any other configuration,or anything, the same element is wrapped automatically to the allowed area:

full text:

Full Text

text wrapping

Text Wrapping

more wrapping, and scrolling caused by the position

Wrapping and scrolling

I also started a map loading system.
But this is for another post.

GUI – Scrollable menus

Tags

, , ,

Some day ago i put myself to work on the gui.

What i started to think was “how does the user interact in a roguelike” ? the first things that came in my mind were “menus“.

The next step was to define “what is a menu?” and the answer was quite simple:

a menu is something that contains a list of selectable items.

from there i reached the conclusion that i could handle the interface with 2 different types of menu:

  • a hover menu
  • a character-selection menu

The first one allows one of the selectable items to be visibly different from the others, allowing the user to recognize which option he’s selecting . The difference might be in the background/foreground colors, a simple character before the label, or anything else.

The second one allows the gui to show a list of items and for each one ,a letter to press to do something.

A hover menu

Here on the left there is a simple hover menu.

The selected item is shown by a simple “>” character befor the element.

 

 

A character selection menu is quite the same thing,but instead of showing only the labels of the choices, it shows also what key to press to select the single choice.

And here comes the next step: there must be a keyboard handler that can recognize what’s happening. (this is a next post topic)

What’s nice about how i handled the menus is that if i put them close to the bottom side of the console , the scrolling is handled correctly, so the whole menu scrolls to show  the user the choices that don’t fit in the screen.

The syntax is quite simple, with a single line i can handle the menu printing

engine.writeScrollable(“consolename”,menuobject,x,y)

and with another couple i can handle the keyboard input:

handler = kh.HoverMenuKeyboardHandler(menu)
engine.setKeyboardHandler(handler)

3 lines and that’s all.

 

Pages and consoles

I thought that i somehow had to declare a flow for the engine: what handles the fact that from a splash page you go to a menu, to a main screen, to a help screen, etc ?

Pages.

I declared that a page is an entity which holds one or more consoles.
libtcod allows to create one or more “off-screen”consoles.
I don’t know if i’m using them in the correct way, but after some time of tests, this is one of the results:

consoles

What happens here on the left?

I created a page which holds 3 consoles, each one with its position and size.

In the page setup i define the background and foreground colors,and other attributes (like for example if the console has the frame or not)

In the end i have a structure which holds 3 different named consoles.

From the main engine i can now access them and “write” on screen with a command like: write(“consolename”,x,y,text)

And here i go: i have consoles ,pages related each one to another and a control flow!

And more to come has already been made, but that’s for another post.